[php] Sessies vs. Cookies

[Verwijderd]

Hey,

ik heb een kleine vraag over php.

Ik heb een profielensite gemaakt dmv sessies. Alles werkt met sessies. Nu vroeg een crewlid aan mij of ik ook een hokje 'ingelogd blijven' kan maken, zodat je niet vaker hoeft in te loggen.

Dat werkt met cookies, voor zover ik weet. Enige probleem is dat ik geen idee heb hoe cookies werken (ben nog vrij nieuw in php). Is het mogelijk om zoiets te maken, en toch mijn sessie-systeem te behouden, of moet ik alles gaan ombouwen tot cookies?

Ik had via iemand anders begrepen dat het, het één, of het ander is. Dus sessies OF cookies.

Graag zou ik een paar tips en extra informatie hierover willen horen

Alvast bedankt!

[Erkens]

Sessions werken met cookies om even mee te beginnen, dus zijn ze ook prima samen te gebruiken

Het eenvoudigste is om de session cookies (en je sessions) een exipre date te geven waardoor deze niet zo snel verloren gaat, uiteraard zit hier een groot nadeel aan vast: je server komt vol met ongebruikte sessions te staan.

Een combinatie is ook goed mogelijk door zelf een extra "session id" te maken en dat in een cookie zetten, door deze extra id kan je opzoeken in je database bij welke user hij hoort indien er nog geen php sessie was en er dan vanuit gaan dat deze user inlogt

[Verwijderd]

Wat betreffende de werking van cookies onder PHP: Google. Daar is genoeg over te vinden.

Het is in dit geval niet het 1 of het ander. Wat je doet is je maakt een cookie aan met login gegevens (nooit het wachtwoord in een cookie opslaan!), veilige oplossingen hiervoor kun je overal op internet vinden. Mocht de bezoeker terug komen naar de site dan kijk je of zijn cookie geldig is en zoja dan maak je de benodigde sessies aan en is de gebruiker ingelogd.

[hamsteg]

www.php.net/cookies ... er zijn hele makkelijke functies voor het creeren van cookies. 'ffn zoeken hoor ...

En je kunt ze door elkaar gebruiken met sessies ... wat jij wilt (alleen heeft elke sessie wel een soort van user space die een bepaalde time-out periode gereserveerd blijft staan dus je kunt in geheugenproblemen komen, misschien, ooit).

[Verwijderd]

Bedankt, hier heb ik wat aan

Ik dacht dat ik mijn hele systeem omver moest gooien, maar dat blijkt dus niet zo te zijn. Ik zal eens google'en naar de functie van cookies en kijken of het me lukt om dat te maken.

Nogmaals, bedankt.

[eamelink]

Sessies en cookies kunnen elkaar aanvullen. Een sessie is een manier om toch een soort van 'state' te hebben bij het stateless http protocol. In principe is namelijk elke request helemaal nieuw. Dat is niet handig, dus heeft PHP een sessiesysteem ingebakken zitten. Hiermee kan je variabelen opslaan in een stukje ruimte dat bij een bepaalde user hoort. Om die user de volgende keer weer te herkennen, wordt vaak gebruik gemaakt van een sessie-cookie, met daarin een uniek id. Als de browser een nieuw request doet voor een andere pagina dan wordt het sessie-id meegestuurd, en weet php dat er nog sessievariabelen bij die sessie hoorden. Zo heb je toch een vorm van persistentie van objecten door meerdere requests heen.

Omdat sommige mensen cookies uit hebben staan, kan PHP ook vrij transparant gebruik maken van het sessie-id in links. PHP kan elke uitgespuugde pagina post-parsen en achter elke link een variabele met het sessie-id plakken. Op die manier kunnen sessies ook werken als de gebruiker geen cookies aan heeft staan, terwijl je voor de ontwikkelaar helemaal transparant gebeurt.

Sessiecookies hebben een standaardlevensduur die gelijk is aan de tijd dat de browser geopend is. Als de browser afgesloten wordt, worden alle sessiecookies verwijderd. Daarom ben je dan dus niet meer ingelogd op je website.

Om dat op te lossen kan je enkele dingen doen. Veruit het gemakkelijkste is om session_set_cookie_params() te gebruiken, dan kan je de levensduur van je session cookies verlengen (tot bijvoorbeeld een jaar). Nadeel is dan wel dat je de sessies op de server zelf óók lang moet gaan bewaren.

Een veelgebruikte andere manier is om een cookie mee te geven. Dit kan geheel los van je sessie staan. Als je hiervoor een cookie met een langere levensduur maakt, en daar wat handige variabelen in (username en een controlehash), kan je een user later gemakkelijk openieuw inloggen

Je krijgt dan zoiets :

PHP:

// Bij het inloggen 
$_SESSION['logged_in'] = true;
if(isset($checkboxding)){
  setcookie('username', 'eamelink');
  setcookie('hash', md5('eamelink' . 'mijngeheimezoutje'));
}

// En dan bij elke paginarequest:
if(isset($_SESSION['logged_in'])){
  // Ingelogd
} elseif(isset($_COOKIE['username']) && md5($_COOKIE['username'] . 'mijngeheimezoutje') == $_COOKIE['hash']){
 // Ook ingelogd, maar nu met cookie
 // Hier bijvoorbeeld je sessie opnieuw vullen 
} else {
 // Niet ingelogd
}

[Erkens]

eamelink: dat voorbeeld is niet helemaal handig gekozen aangezien dit zeer onveilig is.

Wat ik zelf meestal doe is ergens een lijst bijhouden van random gekozen unieke id's (zie bijvoorbeeld uniqid()) samen met de username (en eventueel extra data zoals expiredate en ip). Dit ID stop ik in een koekje, en daarmee kan de user inloggen

[eamelink]

Erkens schreef op maandag 30 juli 2007 @ 18:17:
eamelink: dat voorbeeld is niet helemaal handig gekozen aangezien dit zeer onveilig is.

Waarom?

[Comgenie]

eamelink schreef op maandag 30 juli 2007 @ 18:20:
[...]

Waarom?

Wanneer iemand via een of andere manier aan iemands cookie kant komen, kan die altijd zo inloggen. Verder als je geheime zoutje perongelijk bekend zou worden kan iemand meteen alle gebruikers inkomen. Je kan er beter erachteraan oko nog de wachtwoord erachteraan gooien (bij wachtwoord change kan iemand met gejatte cookie niet meer inloggen). En ip als het aan de ip moet worden gebonden.

[eamelink]

Dat zijn inderdaad handige punten om het beter te maken, dat ben ik met je eens. Maar ik denk dat de kwalificatie 'zeer onveilig' niet juist is. Het probleem van gejatte cookies heb je sowieso ook bij de standaard php sessies, en dat je een salt geheim moet houden is ook niet onoverkomelijk Voor het voorbeeld lijkt het me veilig genoeg

[ATS]

Geef voor de veiligheid in elk geval even de HttpOnly flag mee aan je cookie, dat zou het risico op diefstal moeten verminderen omdat je er (als je browser het ondersteunt) niet meer bij kan met JavaScript. Ook een goed pad zetten kan helpen (dus niet voor je hele site), zeker als op dat pad alleen statische content staat (en er dus minder risico is voor code injection). Het is geen 100%, maar toch weer een extra barriere. Voor je eigen gebruik hoef je er niet met JavaScript bij, dus zelf heb je er geen last van.

[Muthas]

Comgenie schreef op maandag 30 juli 2007 @ 18:28:
[...]

Wanneer iemand via een of andere manier aan iemands cookie kant komen, kan die altijd zo inloggen. Verder als je geheime zoutje perongelijk bekend zou worden kan iemand meteen alle gebruikers inkomen. Je kan er beter erachteraan oko nog de wachtwoord erachteraan gooien (bij wachtwoord change kan iemand met gejatte cookie niet meer inloggen). En ip als het aan de ip moet worden gebonden.

Het lijkt me niet echt slim een wachtwoord in een cookie te zetten. Bij elke request gaat die cookie de lijn over.

Ikzelf set een cookie met een random hash en id, als iemand op de site komt en die is niet ingelogd dan check ik of het ip en een hash van de gebruikers $_SERVER vars overeenkomen met het ip en de $_SERVER hash die ik in de database heb staan gekoppeld aan die random hash en id van de cookie.

Niet 100% veilig, ip te spoofen en $_SERVER vars ook, maar dat lijkt me sowieso niet mogelijk met cookies.

[Verwijderd]

Muthas schreef op dinsdag 31 juli 2007 @ 11:15:
Niet 100% veilig, ip te spoofen en $_SERVER vars ook, maar dat lijkt me sowieso niet mogelijk met cookies.

Een IP spoofen is heel wat moeilijker dan het spoofen van een user agent.

Sla in elk geval nóóit wachtwoorden op in cookies. Houdt alle informatie op de server, en sla in het cookie alleen een sessie-ID op. Sessies kun je vastkoppelen aan IP's, en eventueel aan omgevingsvariabelen als de opgegeven user agent.

Houd het vooral simpel.

[Erkens]

eamelink schreef op maandag 30 juli 2007 @ 18:40:
Dat zijn inderdaad handige punten om het beter te maken, dat ben ik met je eens. Maar ik denk dat de kwalificatie 'zeer onveilig' niet juist is. Het probleem van gejatte cookies heb je sowieso ook bij de standaard php sessies, en dat je een salt geheim moet houden is ook niet onoverkomelijk Voor het voorbeeld lijkt het me veilig genoeg

Je hebt een static salt, en verder staat alleen de username erin, waarom dan nog uberhaupt de moeite doen voor een password? Voor een voorbeeld is het goed genoeg, zolang het maar niet gecopy/paste gaat worden natuurlijk

Verwijderd schreef op dinsdag 31 juli 2007 @ 14:02:
[...]

Een IP spoofen is heel wat moeilijker dan het spoofen van een user agent.

Sla in elk geval nóóit wachtwoorden op in cookies. Houdt alle informatie op de server, en sla in het cookie alleen een sessie-ID op. Sessies kun je vastkoppelen aan IP's, en eventueel aan omgevingsvariabelen als de opgegeven user agent.

Houd het vooral simpel.

Hou er wel rekening mee dat IP's niet altijd vast liggen, en tussen de requests door is het in theorie mogelijk dat er een ander IP gebruikt wordt (vooral bij grote bedrijven met proxy servers).
Even afgezien het feit dat als je een dynamisch IP bij je provider hebt (of inbelt, ja ze zijn er nog) dat je dan alsnog moet inloggen iets wat de TS juist wilde voorkomen

[ATS]

Ik zou het inderdaad simpel houden, maar wel zo veilig mogelijk:

1. Genereer een random code die je in een cookie stopt en in je database opslaat. Sla daarbij ook een hash op van een paar gegevens (user agent + andere data waarvan je verwacht dat ze stabiel blijven tussen logins en die je in een request kan vinden) en controleer die combinatie. Je hebt dan in elk geval geen password of username in je cookies (ook niet met een "onbekende" salt). Ik zou idd geen IP adres nemen als "stabiele" data, want die kan bijvoorbeeld voor een laptop heel makkelijk wijzigen.
2. Verder beveilig je je cookie zo goed als mogelijk (zie mijn eerdere post) en,
3. zorg je dat je de code wist uit je db cq. blokkeert als er een poging gedaan wordt om in te loggen met een verkeerde combinatie van code en statische data. Zo krijgen hackers geen 2e poging.
4. Vervolgens ververs je je random code bij elke geslaagde login, zodat de gegevens snel verouderen en waardeloos worden voor een hacker.
5. Tot slot zou ik het onmogelijk maken om echt belangrijke dingen te doen (wachtwoord wijzigen bijvoorbeeld) zonder een échte login.

Veel meer kan je niet doen denk ik. Hoe je het ook doet, de situatie blijft altijd dat je met (semi) openbare, of in elk geval relatief makkelijk verkrijgbare gegevens een login mogelijk maakt.

[Muthas]

Zonder het gebruik van ip-koppeling zijn cookies imo echt onveilig. Cookie sniffen (gaat bij elke request de lijn over zoals ik al zei, dus na een paar honderd pagina's hebben ze die echt wel) en user-agent achterhalen en klaar (oke, zo klinkt het iets te simpel, is het dus niet, maar toch ). Gok dat ik maar een hokje 'koppel sessie aan ip-adres' ga maken, zoals hier op tweakers. En dan bij het uitzetten daarvan een popup met waarschuwing dat het de veiligheid zwaar omlaag gaat hierdoor en alleen nodig is als je zeker weet dat het nodig is.

Dan maar even over sessionhijacking en vooral het tegengaan hiervan . Ik koppel dus aan ip en user-agent. Ik vroeg me af, kan ik hier nog wat aan toevoegen? Ik doe session_regenerate_id() aan het begin van een sessie zodat je niet via een url in session kan komen waarvan het session id bij andere bekend is.

[ Voor 9% gewijzigd door Muthas op 31-07-2007 15:20 ]

[Erkens]

ATS schreef op dinsdag 31 juli 2007 @ 14:56:
Genereer een random code die je in een cookie stopt en in je database opslaat. Sla daarbij ook een hash op van een paar gegevens (user agent + andere data waarvan je verwacht dat ze stabiel blijven tussen logins en die je in een request kan vinden) en controleer die combinatie. Je hebt dan in elk geval geen password of username in je cookies (ook niet met een "onbekende" salt). Ik zou idd geen IP adres nemen als "stabiele" data, want die kan bijvoorbeeld voor een laptop heel makkelijk wijzigen.

Let wel even op dat het niet handig is om de user agent string volledig te pakken, bij een simpele upgrade of addon kan deze veranderen en dan voldoe je niet meer aan de requirements zoals hier gesteld: niet steeds opnieuw inloggen.

Veiligheid is altijd relatief, je kan het zo veilig maken dat het bijna niet werkbaar meer is tot een wat flexibelere werking waarbij de veiligheid weer een stuk minder is (alleen een session id).
Het ligt daarom helemaal aan wat er beveiligt moet worden. Een simpel forum is minder interessant en kan met wat minder veiligheid af dan bijvoorbeeld de login van een of ander uren registratie systeem en een banklogin heeft weer andere eisen.

[Verwijderd]

Pff, het ziet er gelijk een stuk moeilijker uit.

Ik ga eerst eens googlen naar wat cookies precies zijn en hoe het werkt.

thx voor al die replys.

[Muthas]

Het valt opzich wel mee. Gewoon je hele sessie gebeuren behouden.

Hokje aan inlog-form toevoegen, nieuwe tabel in database voor cookies maken.

Dan in je loginprocedure als het hokje aangevinkt is een random code maken, cookie setten met die code daarin, en in je database een rij toevoegen met daarin die code, user id wat daarbij hoort, wanneer die cookie verloopt (kies zelf hoelang, 1 maand lijkt mij redelijk), ip en een validatie.

PHP:

<?php
$validatie = @md5(
    $_SERVER['HTTP_ACCEPT_CHARSET'] .
    $_SERVER['HTTP_ACCEPT_ENCODING'] .
    $_SERVER['HTTP_ACCEPT_LANGUAGE']);
?>

Vervolgens check je op elke pagina wanneer je bezoeker niet ingelogd is of deze een cookie heeft staan, check of bij zijn code ook zijn ip en validatie matcht, if so dan logt hij in met het opgeslagen user id.

Oh, en verder dus doen wat hierboven verteld is, cookie verwijderen als hij niet klopt etc.

[ Voor 5% gewijzigd door Muthas op 31-07-2007 16:18 ]

[hamsteg]

Cookies zijn niet moeilijk, echt niet ...

Het probleem is security, hoe garrandeer je dat iemand is wie die zegt te zijn als je automatisch wilt kunnen inloggen. Security is een pittig onderwerp waar gelukkig een aantal best practices voor bestaan die hier genoemd zijn.

Kijk inderdaad eerst of je het concept snapt. Sla rustig eerst het (tijdelijke) wachtwoord op in een cookie en kijk of je het snapt. Werkt alles? Niet vrijgeven maar dan dit topic nog eens doorlezen en dan de beveiliging toepassen en het wachtwoord even veranderen. Muthas geeft een paar eenvoudige tips: Muthas in "[php] Sessies vs. Cookies" en ATS gaat zelfs nog iets verder maar is voor een leek al een stap moeilijker om even te snappen ATS in "[php] Sessies vs. Cookies" maar het is wel de goede manier.

[ Voor 12% gewijzigd door hamsteg op 31-07-2007 16:20 ]

[Verwijderd]

Ok, ik zal dat even lezen. Ik ken php pas sinds 3 maanden, dus het is allemaal nog een beetje nieuw voor me. Ik heb al wel veel langer met php gewerkt (aangepast etc) dus ik leer sommige dingen best snel heb ik gemerkt.

Overigens vind ik cookies zelf niet fijn als ik surf, aangezien ik nooit wil dat mijn inlog bewaart blijft waar dan ook maar er zijn mensen die het wel fijn vinden..dus daar moet ik rekening mee houden.

[ATS]

Muthas schreef op dinsdag 31 juli 2007 @ 15:17:
Zonder het gebruik van ip-koppeling zijn cookies imo echt onveilig. Cookie sniffen (gaat bij elke request de lijn over zoals ik al zei, dus na een paar honderd pagina's hebben ze die echt wel) en user-agent achterhalen en klaar (oke, zo klinkt het iets te simpel, is het dus niet, maar toch ).

Maar mét werkt het niet op een apparaat met een variabel IP adres. De truc is dus om je code zo kort mogelijk geldig te houden en het aantal keer dat het over de lijn gaat te beperken. Dus:

• Beperken op welke pagina's je überhaupt met die code kan inloggen.
• Steeds opnieuw de code veranderen (liefst bij elke pageview dus).

De geldigheid beperken (maand lijkt me inderdaad redelijk) en je bent een heel eind. Overigens zou ik sniffen niet de meest voor de hand liggende aanval noemen. Ik ben eerder bang voor x-site scripting achtige aanvallen. Of vergis ik me nu en is sniffen van de lijn wel een werkbare vector voor een aanval?

Dan maar even over sessionhijacking en vooral het tegengaan hiervan . Ik koppel dus aan ip en user-agent. Ik vroeg me af, kan ik hier nog wat aan toevoegen? Ik doe session_regenerate_id() aan het begin van een sessie zodat je niet via een url in session kan komen waarvan het session id bij andere bekend is.

Lijkt mij voor een sessie prima wat je doet. Binnen een sessie verandert het IP adres toch niet. Wat je nog kan doen is het HttpOnly flaggetje zetten (als dat er niet al staat) voor je sessie-cookie.

[Sendy]

edit:

Geef de sessie-cookie gewoon een langere levensduur. Zorg dat het script dat de sessie gebruikt tegen het feit kan dat er geen sessie-data meer bestaat (dus bijvoorbeeld nieuwe tijdelijke data aanmaken).

Erkens schreef op maandag 30 juli 2007 @ 15:14:
Sessions werken met cookies om even mee te beginnen, dus zijn ze ook prima samen te gebruiken

Het eenvoudigste is om de session cookies (en je sessions) een exipre date te geven waardoor deze niet zo snel verloren gaat, uiteraard zit hier een groot nadeel aan vast: je server komt vol met ongebruikte sessions te staan.

Een combinatie is ook goed mogelijk door zelf een extra "session id" te maken en dat in een cookie zetten, door deze extra id kan je opzoeken in je database bij welke user hij hoort indien er nog geen php sessie was en er dan vanuit gaan dat deze user inlogt

Ik zie geen enkel voordeel in die extra cookie (en ook geen nadeel in "je server komt vol met ongebruikte sessions te staan").

Er lijkt consensus te zijn dat, om ingelogd te blijven, er data moet worden bewaard. Ergo, op je server komt allemaal tijdelijk niet gebruikte data te staan. Stel nu dat je sessie-data na een maand verwijderd wordt en je sessie-cookie een jaar heel blijft. Je systeem ziet dan in de database dat het sessie-cookie bestaat. Het systeem gaat op zoek naar de sessie-data maar kan deze niet vinden (want verwijderd). Het systeem maakt nu opnieuw sessie-data aan.

In dit systeem zijn er niet meerdere cookies nodig. Ook hoeft er niet meer data op de server te staan dan noodzakelijk is om mensen ingelogd te houden. Verder, die sessie-cookie kan je prima binden aan het ipnummer, je kan allemaal hashing algoritmes toepassen (die het allemaal niet veiliger maken, wel complexer) en nog veel meer.

Daarom is mijn vraag waarom zou je dan toch een extra cookie maken? Komt dat doordat het PHP systeem mijn algoritme niet makkelijk toestaat omdat veel automatisch gaat?

edit:
Zijn er beveiligingsmethoden die je niet op de sessie-cookie kan toepassen?

[ Voor 7% gewijzigd door Sendy op 01-08-2007 00:35 ]

[Verwijderd]

Wat is een HttpOnly flaggetje?

[Verwijderd]

Verwijderd schreef op dinsdag 31 juli 2007 @ 16:52:
Wat is een HttpOnly flaggetje?

Ik gok dat HttpOnly aangeeft dat de sessie-ID alleen via een cookie (dus via het HTTP-protocol) mag worden doorgegeven, en niet als GET-waarde aan URI's.

[Muthas]

Verwijderd schreef op dinsdag 31 juli 2007 @ 16:52:
Wat is een HttpOnly flaggetje?

Een setting voor de setcookie(); functie, en die doet volgens php.net het volgende

httponly

When TRUE the cookie will be made accessible only through the HTTP protocol. This means that the cookie won't be accessible by scripting languages, such as JavaScript. This setting can effectly help to reduce identity theft through XSS attacks (although it is not supported by all browsers). Added in PHP 5.2.0. TRUE or FALSE

ATS schreef op dinsdag 31 juli 2007 @ 16:44:
[...]

Maar mét werkt het niet op een apparaat met een variabel IP adres. De truc is dus om je code zo kort mogelijk geldig te houden en het aantal keer dat het over de lijn gaat te beperken.

Cookie gaat altijd over de lijn, en aangezien je niet weet wanneer je user voor het laatst een pagina gaat opvragen moet je de cookie dus sowieso gelijk setten. Wel of niet aan ip binden kan je ook als optie maken. Verder, een if ($_SESSION['login'] == FALSE) { cookie_check(); } neemt niet veel code in beslag.

Dus:
• Beperken op welke pagina's je überhaupt met die code kan inloggen.

Voegt niks toe qua veiligheid, dus waarom doen?

• Steeds opnieuw de code veranderen (liefst bij elke pageview dus).

Bij elke pageview een nieuwe cookie waarde setten? Lijkt mij niet handig.

De geldigheid beperken (maand lijkt me inderdaad redelijk) en je bent een heel eind. Overigens zou ik sniffen niet de meest voor de hand liggende aanval noemen. Ik ben eerder bang voor x-site scripting achtige aanvallen. Of vergis ik me nu en is sniffen van de lijn wel een werkbare vector voor een aanval?

Geen idee eigenlijk, maar als jij xss tegengaat en heel moeilijk maakt en iemand wil echt een andere account overnemen dan zal er iets anders geprobeerd worden, dus gewoon zoveel mogelijk proberen tegen te gaan

[...]

Lijkt mij voor een sessie prima wat je doet. Binnen een sessie verandert het IP adres toch niet. Wat je nog kan doen is het HttpOnly flaggetje zetten (als dat er niet al staat) voor je sessie-cookie.

Verwijderd schreef op dinsdag 31 juli 2007 @ 16:19:
Ok, ik zal dat even lezen. Ik ken php pas sinds 3 maanden, dus het is allemaal nog een beetje nieuw voor me. Ik heb al wel veel langer met php gewerkt (aangepast etc) dus ik leer sommige dingen best snel heb ik gemerkt.

Overigens vind ik cookies zelf niet fijn als ik surf, aangezien ik nooit wil dat mijn inlog bewaart blijft waar dan ook maar er zijn mensen die het wel fijn vinden..dus daar moet ik rekening mee houden.

Schakel cookies maar is uit en probeer dan in te loggen op een willekeurige website. Gaat op een php site in ieder geval niet werken. Je kan wel session id's via een url doorgeven, maar dat moet je in php.ini of .htaccess zijn ingesteld, en om dat standaard te doen ziet er ook niet uit (voor die ene 0,1% met cookies disabled)

[ Voor 16% gewijzigd door Muthas op 31-07-2007 17:29 ]

[Erkens]

Verwijderd schreef op dinsdag 31 juli 2007 @ 16:19:
Overigens vind ik cookies zelf niet fijn als ik surf, aangezien ik nooit wil dat mijn inlog bewaart blijft waar dan ook maar er zijn mensen die het wel fijn vinden..dus daar moet ik rekening mee houden.

Daar zijn session cookies voor uitgevonden, die worden verwijderd zodra je de browser afsluit. En in de meeste browsers kan je ook zo instellen dat deze alle cookies als zodanig beschouwen

[ATS]

Muthas schreef op dinsdag 31 juli 2007 @ 17:19:

ATS: Beperken op welke pagina's je überhaupt met die code kan inloggen.

Voegt niks toe qua veiligheid, dus waarom doen?

Dat doet het wel: je hoeft het cookie niet meer bij elke pageview te versturen, en je kan zorgen dat die pagina's zo static mogelijk zijn zodat er niet makkelijk foute javascript in geinjecteerd kan worden. Cookie pad goed zetten en klaar.

Bij elke pageview een nieuwe cookie waarde setten? Lijkt mij niet handig.

Waarom niet? Ik zie het bezwaar niet zo. Het ligt er natuurlijk aan hoe druk je site is, maar zo ingewikkeld is het updaten van een record in je db toch niet? Op die manier is de geldigheid van je key wel heel beperkt, en dat is precies wat je wil.

Geen idee eigenlijk, maar als jij xss tegengaat en heel moeilijk maakt en iemand wil echt een andere account overnemen dan zal er iets anders geprobeerd worden, dus gewoon zoveel mogelijk proberen tegen te gaan

Natuurlijk, maar het heeft weinig zin om eerst de kleine gaten te stoppen terwijl de grote nog open staan

[Muthas]

ATS schreef op dinsdag 31 juli 2007 @ 18:21:
[...]

Dat doet het wel: je hoeft het cookie niet meer bij elke pageview te versturen, en je kan zorgen dat die pagina's zo static mogelijk zijn zodat er niet makkelijk foute javascript in geinjecteerd kan worden. Cookie pad goed zetten en klaar.

Ah, wacht nu snap ik hem. Cookie setten voor alleen website.nl/frontpagemapofwhatever, dan wordt ie dan ook alleen verstuurd als je de frontpage index pagina bezoekt. Slim

[...]

Waarom niet? Ik zie het bezwaar niet zo. Het ligt er natuurlijk aan hoe druk je site is, maar zo ingewikkeld is het updaten van een record in je db toch niet? Op die manier is de geldigheid van je key wel heel beperkt, en dat is precies wat je wil.

Tja, dit is dan denk iets waarbij je moet gaan denken of hoe belangrijk de veiligheid is. Nu ik er zo over nadenk ga ik het zelf toch wel toevoegen, alleen dan om de 10 minuten (oid) een nieuwe cookie.

[...]

Natuurlijk, maar het heeft weinig zin om eerst de kleine gaten te stoppen terwijl de grote nog open staan

[Erkens]

ATS schreef op dinsdag 31 juli 2007 @ 18:21:
Dat doet het wel: je hoeft het cookie niet meer bij elke pageview te versturen, en je kan zorgen dat die pagina's zo static mogelijk zijn zodat er niet makkelijk foute javascript in geinjecteerd kan worden. Cookie pad goed zetten en klaar.

Maar vaak leiden dit soort dingen tot wazige bugs die enorm lastig te vinden zijn.

Waarom niet? Ik zie het bezwaar niet zo. Het ligt er natuurlijk aan hoe druk je site is, maar zo ingewikkeld is het updaten van een record in je db toch niet? Op die manier is de geldigheid van je key wel heel beperkt, en dat is precies wat je wil.

Je ontneemt alleen de gebruiker gebruiksgemak, omdat de kans groot is dat je cookie als ongeldig gezien wordt zodra je meerdere page request op hetzelfde moment gaat doen (denk bijvoorbeeld aan tabbed browsing.

[Muthas]

Erkens schreef op dinsdag 31 juli 2007 @ 18:44:
[...]

Maar vaak leiden dit soort dingen tot wazige bugs die enorm lastig te vinden zijn.


[...]

Je ontneemt alleen de gebruiker gebruiksgemak, omdat de kans groot is dat je cookie als ongeldig gezien wordt zodra je meerdere page request op hetzelfde moment gaat doen (denk bijvoorbeeld aan tabbed browsing.

Nee, de cookie is alleen voor het inloggen als de gebruiker niet is ingelogd. Het is niet om te checken of de ingelogde gebruiker nog steeds dezelfde gebruiker is.

Als hij zijn laatste pagina request doet voordat hij weggaat (browser afsluit waardoor sesiecookie verloopt) wordt zijn login cookie met de allerlaatste hashinfo geupdate, die ook in de database staat. Die cookie is maar 1 keer over de lijn geweest (host > client) en de kans dat ie dan gesnifft is is natuurlijk heel klein. Vervolgens gaat de user weer naar de website, cookie gaat 1 keer over de lijn, user wordt ingelogd en krijgt alweer een nieuwe cookie.

[Chesta]

Sessions zijn zowizo onveilig omdat het alleen maar met een ID werkt, of heb ik iets gemist?

[ATS]

Klopt, maar een sessie kan je nog aan een IP binden. Dat biedt nog enige beveiliging. Veel meer opties heb je niet de stateless omgeving die HTTP nu eenmaal is.

@Muthas: je hebt hem door. Ik was niet heel duidelijk denk ik. Beetje afhankelijk van de opzet van je pagina wordt je cookie natuurlijk niet heel vaak geupdate op de manier die ik voorstelde: je hebt namelijk alleen je frontpage waar je je cookie nodig hebt. Tenzij je de verlooptijd weer opslaat in je sessie, heb je nog altijd een query, en zelfs nog een voor je update als dat nodig is... Nu is een SELECT natuurlijk goedkoper dan een UPDATE, maar toch...

[Chesta]

ATS schreef op dinsdag 31 juli 2007 @ 20:57:
Klopt, maar een sessie kan je nog aan een IP binden. Dat biedt nog enige beveiliging. Veel meer opties heb je niet de stateless omgeving die HTTP nu eenmaal is.

Dat kan dus ook niet omdat grote bedrijven met proxy's werken met verschillende WAN IP's

[Erkens]

Chesta schreef op dinsdag 31 juli 2007 @ 19:19:
Sessions zijn zowizo onveilig omdat het alleen maar met een ID werkt, of heb ik iets gemist?

Als je veiligheid wilt moet je niet op internet wezen (ja ik weet het, dat is een dooddoener). Daarnaast als je echt om veiligheid geeft dan begin je als eerste met het encrypten van de dataverbinding (SSL).

Overigens zijn sessions niet per definitie onveilig, alleen wat je er mee doet kan die onveiligheid creeren, als je dus bijvoorbeeld login informatie in je session stopt dan kan dat onveilig zijn (zie jouw opmerking). Maar aan de andere kant is het ook niet veilig om voor iedere connectie die je maakt opnieuw je username+password mee te sturen (ook al is de verbinding encrypted, users houden er gewoon niet van om telkens opnieuw dezelfde gegevens in te geven).

[Muthas]

Chesta schreef op dinsdag 31 juli 2007 @ 21:54:
[...]


Dat kan dus ook niet omdat grote bedrijven met proxy's werken met verschillende WAN IP's

Je kan wel meerdere sessie's met hetzelfde ip hebben. Enigste is dat als iemand van jou netwerk jou sessie-id achterhaald je de sjaak bent

[Verwijderd]

Praat gerust verder in dit topic, als ik een beetje verder ben met die cookies laat ik het weten!

EDIT: Dit is allemaal boven mijn niveau wat hier gepost wordt ;P

[ Voor 25% gewijzigd door Verwijderd op 01-08-2007 14:18 ]

[Verwijderd]

Beste mensen,

Ik kom er niet echt uit, hebben jullie misschien een site waarop meer informatie staat hierover, of is iemand bereid mij te helpen hiermee? Of kunnen jullie mij opweg helpen met een (standaard) stuk code?

Alvast bedankt.

[Cartman!]

Verwijderd schreef op maandag 13 augustus 2007 @ 00:19:
Beste mensen,

Ik kom er niet echt uit, hebben jullie misschien een site waarop meer informatie staat hierover, of is iemand bereid mij te helpen hiermee? Of kunnen jullie mij opweg helpen met een (standaard) stuk code?

Alvast bedankt.

Wat heb je inmiddels allemaal uitgezocht en geprobeerd dan?

[Verwijderd]

Nou, het probleem zit hem er meer in dat ik niet weet hoe ik moet beginnen en waar. Alles werkt nu via sessies, en ik weet niet of dat problemen opbrengt.

[Verwijderd]

Hallo,

Ik ben er weer

Ik heb meer gelezen over cookies en heb nog een paar vragen.

1. Stel ik maak een cookie aan, moet ik dan een pad aangeven waar hij het saved? Want hoe kan ik kijken of een cookie bestaat? Zoals dit:

PHP:

if(isset($_COOKIE['username']) && ($_COOKIE['wachtwoord']) {

// blaat

}

Nu checkt hij of jij op de pc cookie van de username hebt staan en cookie met je md5-wachtwoord (het wachtwoord van een user is een md5 hash).

Kijkt nu naar 2 cookies (username cookie + wachtwoord cookie) of is het 1 cookie waar hij 2 dingen uit afleest?

2. Hoe moet je cookies plaatsen? Ik heb gelezen dat je dat met setcookie() doet, maar ik heb ook ergens anders gelezen dat het een textfile is. Wordt die cookie dan een .txt bestand, zo ja is het dan nog veilig?

3. Is het veilig om een wachtwoord te plaatsen in een cookie (wat ik dus daarboven liet zien) als het is het beveiligd met md5. De wachtwoorden zitten in de database sowieso als een md5 hash, is het dan nogsteeds veilig om die informatie ook in de cookie te stoppen? Ik zelf denk dat het veilig is aangezien het md5 is en als je erachter wilt komen, moet je het brute forcen. Dus stel dat iemand de cookie hackt/steelt (hoe je dat ook noemt) dan kan hij nog niks met het wachtwoord.

4. Het principe is dus eigenlijk, als iemand inlogt met user + ww dan stop je beide dingen gewoon in een cookie (hij heeft aangevinkt "hij wilt ingelogd blijven"). Nu zit die informatie in een cookie, en hij verlaat de pagina. Is het dan zo dat als hij die pagina weer opgaat, de site checkt of de cookie bestaat (hoe weet de site welk pad dat is?!) en als hij ziet dat de user + ww overeenkomen, is hij ingelogd.

5. Is het genoeg om alleen de username + ww in een cookie te zetten? eamelink had in zijn post meerdere dingen gezet (geheime zoutje enz) zie hier: eamelink in "[php] Sessies vs. Cookies"

Wat is noodzakelijk om in een cookie te plaatsen?

6. Stel dat iemand niet uitlogt, en heeft gekozen om ingelogd te blijven, en de pagina gewoon verlaat. Nu staat hij onderaan vb bij "Wie is ingelogd: Pietje". Nu is de cookie er nogsteeds, dus blijft hij nu een jaar lang daar staan? (als de cookie 1 jaar duurt)

7. Stel dat een cookie word aangemaakt, en iemand zegt dat hij ingelogd wilt blijven. Cookie lengte staat op 1 jaar. Maar de persoon komt niet terug naar de site, zelfde dus als vraag 6, word hij nu nogsteeds altijd als ingelogd bekeken ookal zit hij niet op de site?

8. Mijn laatste vraag

Stel iemand zegt 'inlogd blijven', en na vb 15 minuten surfen logt hij uit. Moet de cookie dan verwijderd worden, of moet de cookie er blijven bestaan voor als hij later terug komt?

Ik hoop dat iemand deze vragen kan beantwoorden..het zijn er een hoop maar zou toch graag antwoord verwachten.

PS. Ik doe mijn beste mede-tweakers alleen heb ik niet overal verstand van, daarom duurde het lang voor ik antwoorde.

[Verwijderd]

Verwijderd schreef op woensdag 15 augustus 2007 @ 19:49:

Ik heb meer gelezen over cookies en heb nog een paar vragen.

1. Stel ik maak een cookie aan, moet ik dan een pad aangeven waar hij het saved? Want hoe kan ik kijken of een cookie bestaat? Zoals dit:

PHP:

if(isset($_COOKIE['username']) && ($_COOKIE['wachtwoord']) {

// blaat

}

Nu checkt hij of jij op de pc cookie van de username hebt staan en cookie met je md5-wachtwoord (het wachtwoord van een user is een md5 hash).

Kijkt nu naar 2 cookies (username cookie + wachtwoord cookie) of is het 1 cookie waar hij 2 dingen uit afleest?

Je hebt een verkeerd beeld van PHP als het gaat om cookies. Er wordt niet "op de PC gekeken". Er wordt een HTTP request gedaan. Daarbij "kijkt" je browser/user agent of de request wordt gedaan naar een path waarvoor bepaalde cookies bekend zijn. Als dat het geval is, worden die bij de request meegestuurd met de HTTP headers.

Het loont de moeite om eens te gaan kijken naar wat je browser precies krijgt of verstuurt. Installeer eens Firefox met een extension om HTTP headers te kunnen bekijken in de request en in de response. En dan uiteraard met name naar de Cookie headers kijken. Kennis van HTTP headers is sowieso een must als je dit soort dingen wilt doen.

2. Hoe moet je cookies plaatsen? Ik heb gelezen dat je dat met setcookie() doet, maar ik heb ook ergens anders gelezen dat het een textfile is. Wordt die cookie dan een .txt bestand, zo ja is het dan nog veilig?

Je kunt setcookie() gebruiken om makkelijk een cookie in de HTTP headers van de response mee te sturen. Bij de client wordt vaak een simpel tekstbestandje aangemaakt ja. Wat er ook gebeurt, de client houdt die data bij. Dat zou net zo goed in een sqlite database of een registersleutel kunnen zijn. Wat er bij de client gebeurt is ook niet echt belangrijk. Je moet er maar op vertrouwen dat die client weleens een cookie mee zou kunnen sturen in bepaalde situaties. En je kunt met de cookie path min of meer aangeven wanneer je wilt dat welke cookies worden meegestuurd door de client.

3. Is het veilig om een wachtwoord te plaatsen in een cookie (wat ik dus daarboven liet zien) als het is het beveiligd met md5. De wachtwoorden zitten in de database sowieso als een md5 hash, is het dan nogsteeds veilig om die informatie ook in de cookie te stoppen? Ik zelf denk dat het veilig is aangezien het md5 is en als je erachter wilt komen, moet je het brute forcen. Dus stel dat iemand de cookie hackt/steelt (hoe je dat ook noemt) dan kan hij nog niks met het wachtwoord.

Je kunt dat beter niet doen. Je kunt dan beter het wachtwoord server-side controleren, en een "token" (je session cookie is meestal goed genoeg) geven aan de client, waarmee je verklaart dat de client zich geauthenticifeerd heeft. Als de client dan die token meestuurt, kun je aan de hand daarvan opzoeken om welke user het gaat. Het is onverstandig om een wachtwoord (versleuteld of onversleuteld of ongehashed) op te slaan op een plek waarvan je niet weet of het veilig is (de client-PC).

4. Het principe is dus eigenlijk, als iemand inlogt met user + ww dan stop je beide dingen gewoon in een cookie (hij heeft aangevinkt "hij wilt ingelogd blijven"). Nu zit die informatie in een cookie, en hij verlaat de pagina. Is het dan zo dat als hij die pagina weer opgaat, de site checkt of de cookie bestaat (hoe weet de site welk pad dat is?!) en als hij ziet dat de user + ww overeenkomen, is hij ingelogd.

Ik zou een session token en eventueel een user ID in de cookie stoppen. De user ID alleen als daar een goede reden voor is. Zoals gezegd weet een site niets over waar een client de cookies bewaart.

5. Is het genoeg om alleen de username + ww in een cookie te zetten? eamelink had in zijn post meerdere dingen gezet (geheime zoutje enz) zie hier: eamelink in "[php] Sessies vs. Cookies"

Wat is noodzakelijk om in een cookie te plaatsen?

In principe is een standaard session ID die PHP voor je genereert veilig genoeg. Alleen als je echt héél erg safe wilt zijn kun je meer "veiligheid" toevoegen door allerlei extra controledingen in een session / session cookie te zetten, en te gaan controleren op bijvoorbeeld IP adres. Eigenlijk is het helemaal niet noodzakelijk om een cookie te gebruiken, maar dat is wel het handigst. Anders zou je in de URL's dat soort gegevens moeten meesturen. Dat is veel minder veilig. Denk er maar eens aan wat er gebeurt als mensen elkaar links gaan sturen met die session ID's erin. Dan zou je sowieso bijvoorbeeld ook op IP moeten checken. Maar dat wil je eigenlijk ook niet als het niet hoeft, in verband met proxies en dergelijke.

6. Stel dat iemand niet uitlogt, en heeft gekozen om ingelogd te blijven, en de pagina gewoon verlaat. Nu staat hij onderaan vb bij "Wie is ingelogd: Pietje". Nu is de cookie er nogsteeds, dus blijft hij nu een jaar lang daar staan? (als de cookie 1 jaar duurt)

Dat ligt eraan. Als zijn client die cookie een jaar blijft meesturen, zou het kunnen. Als je sessions gebruikt, zou de server die session gegevens ook zolang moeten bewaren. Als je die sessies in files in de /tmp directory laat opslaan (de standaard instelling) blijven de sessies geldig zolang die /tmp directory niet wordt opgeruimd. Als je de sessies zelf bijhoudt in een database heb je er betere controle over.

7. Stel dat een cookie word aangemaakt, en iemand zegt dat hij ingelogd wilt blijven. Cookie lengte staat op 1 jaar. Maar de persoon komt niet terug naar de site, zelfde dus als vraag 6, word hij nu nogsteeds altijd als ingelogd bekeken ookal zit hij niet op de site?

Dat ligt eraan wat je wilt dat er gebeurt. Als je sessies bijhoudt in files, zou je kunnen kijken of de last modified tijd niet teveel afwijkt van de huidige tijd. Als je sessies bijhoudt in een database, kun je met een query de oude sessies opruimen. Het is de vraag wat je met die "login informatie" wilt kunnen. Als je wilt dat andere mensen kunnen zien hoeveel mensen er online zijn, moet je dat inderdaad bij gaan houden.

8. Mijn laatste vraag

Stel iemand zegt 'inlogd blijven', en na vb 15 minuten surfen logt hij uit. Moet de cookie dan verwijderd worden, of moet de cookie er blijven bestaan voor als hij later terug komt?

Als iemand ingelogd wilt blijven en de browser sluit, moet hij ingelogd zijn als hij de browser weer opent en een pagina opvraagt. Als iemand op een knop "uitloggen" drukt moet je de sessie en de cookie opruimen.

[Verwijderd]

Heel erg bedankt voor het beantwoorden van mijn vragen!

Ik ga nog iets meer lezen over cookies, voor ik begin met scripten aangezien het me toch wel lastig lijkt.

Ik snap het principe van die token niet helemaal, naam komt me totaal niet bekend voor en ik snap het verhaaltje eromheen ook niet. Zou je dat misschien nog eens kunnen uitleggen?

[Verwijderd]

Ik heb zojuist een cookie-systeem gemaakt, en het werkt, daar ben ik in de 1e plaats al blij mee.

Ik heb het zo gedaan:

er worden 2 cookies geplaatst als je correct inlogt. Een cookie met je username en een cookie met je IP.

Nu worden bij het aanmaken van die cookies, tegelijk ook de beide waarden in een tabel geschreven.

Als je de browser afsluit, en daarna erin komt, checkt hij of jouw IP overeenkomt met de IP die in de cookie zit opgeslagen. Ook checkt hij of je IP en Username matcht zoals het in de tabel staat (dus dat IP en username bij elkaar horen). Zo ja, dan ben je ingelogd, zo niet, dan niet

Is dit een goede methode? Nu heb je natuurlijk wel het probleem met proxys (bijvoorbeeld) maar ik wist niet wat ik, naast een username, nog meer in een cookie kon plaatsen..

[Janoz]

Waarom uitgaan van een bestaande waarde? Je kunt ook een random waarde nemen (wat ook met token bedoeld wordt). Het IP is veranderlijk. Als het niet via een proxy is kan het ook nog zijn dat een gebruiker uberhaupt een ander IP krijgt. Als je overal waar nu het IP wordt gebruikt gewoon een random code gebruikt dan heb je daar ook geen last meer van.

[Cartman!]

Een ip lock moet dan ook optioneel zijn imo. Username zou je ook niet eens hoeven opslaan in een cookie, als je in de database gewoon het id van de user opslaat tijdens het opslaan van de token dan kun je adhv. de token alle userinfo ophalen en je weet altijd dat die data klopt. Bestaat de token niet in de dbase dan is de user niet ingelogd.

[Verwijderd]

Oke, ik zal dat zodadelijk even proberen te maken.

[imp4ct]

Chesta schreef op dinsdag 31 juli 2007 @ 19:19:
Sessions zijn zowizo onveilig omdat het alleen maar met een ID werkt, of heb ik iets gemist?

Weet toch niet of sessions zo onveilig zijn. Ze worden helemaal niet lokaal opgeslagen, maar op de server, dus jah je moet al access hebben tot de server om ze te bemachtigen, dit is met cookies helemaal anders vermits die dan weer lokaal worden opgeslagen.

Persoonlijk verkies ik sessions boven cookies, maar ik heb met hetzelfde probleem gezeten als de topic-starter. 'k Heb dit dan maar opgelost door een cookie aan te maken met wat info in die bv. na 2 uur verliep, maar als de sessie dus verlopen was, werd de cookie uitgelezen en werd de info in de session geplaatst.

Weet niet of dit superveilig is natuurlijk, maar jah... ik vraag me eigenlijk af hoe ze het hier bij Tweakers doen, misschien kan een devver daar eens antwoord op geven, 'k denk dat ze bij Tweakers wel op veilig spelen, niet ?

[Cartman!]

Hier wordt gewerkt met n eigen session systeem. Je hebt een cookie met daarin een id (bijv. ReactId). In de database wordt die session waarde opgehaald en gekeken of er voldaan wordt aan de eisen (bijv. ip of tijd) en dan worden je gegevens opgehaald. Elke user kan meerdere sessions hebben zodat je op meerdere plekken tegelijk ingelogd kunt zijn. Heb dit systeem zelf ook zo gebouwd en ik moet zeggen dat t fantastisch werkt.

[Verwijderd]

Iedereen heel erg bedankt, ben een stuk wijzer wat betreft cookies!

Ik heb in dit topic geen vragen meer