[php] sessie/login systeem

[Saven]

Hey Tweakers!
Ik ben van plan om een nieuw sessie/login systeem ofzo te maken voor mijn (nieuwe) website . Zoiets als hier op Tweakers.net is.

Nu vroeg ik mij af hoe ik dat nou het beste kon doen. Ik heb zelf natuurlijk al na zitten denken, maar ik snap iets niet helemaal.
Op sommige sites zie je in de url ?PHPSESSID=xxxxxxxxxxx waarom is dit? en waarom zou je dat uberhaupt via de URL doen? je hebt toch $_SESSION of session_id()

Maargoed, dat even terzijde want ik wil zo denk ik niet werken met sessies omdat je dan niet ingelogd kan blijven.

Ik heb dus een users tabel, en wil dus ook een sessions tabel in mijn database zetten.
Mijn idee was als volgt:

Cookies zetten als iemand inlogt: sess_id = random_string();
dus de cookie sess_id bevat een 50 tekens lange string die "random" is gemaakt.

Deze string komt ook in de sessions tabel met daarbij het user_id.
Op elke pagina de sess_id cookie vernieuwen en ook in de database het sess_id updaten dan naar de nieuwe string.

Dan via een SELECT de user id opvragen uit de sessions tabel via de cookie, en met die opgevraagde user id weer de rest van de user info opvragen uit de users tabel

Kost dus 2 queries in plaats van 1 die ik nu gebruik. Nu select ik gewoon een user uit de tabel dmv een username en password cookie.

Maargoed Sorry voor het lange bericht, maar ik hoop dat jullie het een beetje snappen en mij tips kunnen geven en/of voorbeelden

Alvast bedankt

[Caddy]

Ik doe het ook zo met een random key die in de database wordt opgeslagen.
Je kan misschien ook met een inner join query ervoor zorgen dat je maar 1 query gebruikt.
Of je zet die key gewoon in de user table

[Saven]

Caddy schreef op vrijdag 18 april 2008 @ 23:38:
Ik doe het ook zo met een random key die in de database wordt opgeslagen.
Je kan misschien ook met een inner join query ervoor zorgen dat je maar 1 query gebruikt.
Of je zet die key gewoon in de user table

Dat is inderdaad ook een ideetje Maar ik was wel van plan dat users meerdere sessies open hebben kunnen staan, dus bijv. op het werk en thuis, en vanaf thuis uit kunnen loggen als het ware op het werk

Dat gaat dan weer een beetje moeilijk als dat alleen via de user tabel moet gebeuren

[ChessSpider]

dat van ?PHPSESSID=, de GET variabele dus, is volgens mij voor mensen die cookies uitgeschakeld hebben. Dan blijf je ingelogd via de URL ipv via een tijdelijke cookie.
Natuurlijk moet die phpsessid wel bij elke link op je website staan.

[!null]

Ik laat eigenlijk PHP gewoon de sessie id opnieuw genereren. Dit kun je eventueel doen op het moment dat iemand op je site komt (bijv op het login scherm), maar iig zeker nadat de persoon is ingelogd. Maar bij iedere pagina de sessie id opnieuw genereren lijkt me overdreven toch.

Over die 2 SELECT query's, dat lijkt me makkelijk te combineren tot 1 query, met een JOIN.

[Saven]

Oké een JOIN dat is duidelijk idd.
Maar waarom zou je session_id() gebruiken? en niet zelf een "sess_id" maken aan de hand van een random string? Lijkt mij eigenlijk niet dat dat veel uitmaakt

Maar dus ik zet de cookie met de sess_id. Maar wat als die cookie dan wordt gestolen? Dan kan iemand anders zo inloggen op die andere sessie, met alle gevolgen van dien.

[djiwie]

Dan moet je controleren op bijvoorbeeld het ip-adres van degene die de sessie geïnitieerd heeft. En SSL gebruiken, dan voorkom je in ieder geval MITM-aanvallen.

[Saven]

djiwie schreef op zaterdag 19 april 2008 @ 12:46:
Dan moet je controleren op bijvoorbeeld het ip-adres van degene die de sessie geïnitieerd heeft. En SSL gebruiken, dan voorkom je in ieder geval MITM-aanvallen.

hm dat is inderdaad logisch met die ip check.

Maar hier op Tweakers valt me net op dat het sessie id steeds hetzelfde blijft? Is dat niet enigzins onveiliger of wat? en hoe genereert Tweakers het id dan? gewoon met session_id() ofzo als je inlogt?

En SSL heb ik geen ervaring mee, net een beetje op zitten google voor een tutorial oid, maar kan niks vinden


edit::
En hoe zit dat dan eigenlijk met belgen? aangezien die (bijna) altijd een dynamisch ip hebben. Dat zou betekenen dat die elke dag opnieuw in moeten loggen als ik check op sessie id en ip

[ Voor 13% gewijzigd door Saven op 19-04-2008 13:39 ]

[djiwie]

Dan moet je de keuze om eens sessie te koppelen aan een IP-adres variabel maken, net zoals Tweakers nu ook doet.
En SSL is een extra layer op je verbinding, programmeer-technisch hoef je hier niet zo veel voor te doen. Qua serverconfiguratie wel Hier kun je er wat meer over lezen.

[!null]

Je kunt met PHP ook de sessie id laten hergenereren, lijkt me voldoende toch. En SSL is natuurlijk het veiligst, maar je moet een afweging maken in de kosten en het doel van de site. (al hoeft SSL helemaal niet veel te kosten)

[ Voor 10% gewijzigd door !null op 19-04-2008 13:46 ]

[ChessSpider]

GreenSky schreef op zaterdag 19 april 2008 @ 13:46:
Je kunt met PHP ook de sessie id laten hergenereren, lijkt me voldoende toch. En SSL is natuurlijk het veiligst, maar je moet een afweging maken in de kosten en het doel van de site. (al hoeft SSL helemaal niet veel te kosten)

Sterker nog, SSL is gratis.
Mocht je voor een applicatie SSL willen gebruiken die niet voor het grote publiek bedoelt is,kan je prima een eigen sleutel aanmaken. Je krijgt een "lelijke" waarschuwing, maar zolang jij het ziet maakt het niet uit. Ik gebruik het ook voor mijn thuisserver.

http://www.wampserver.com/phorum/read.php?2,32986
Is volgens mij wel een goede tutorial voor Windows/Apache.

[Saven]

djiwie schreef op zaterdag 19 april 2008 @ 13:44:
Dan moet je de keuze om eens sessie te koppelen aan een IP-adres variabel maken, net zoals Tweakers nu ook doet.
En SSL is een extra layer op je verbinding, programmeer-technisch hoef je hier niet zo veel voor te doen. Qua serverconfiguratie wel Hier kun je er wat meer over lezen.

hehe thnx ssl zal ik dan zeker eens overwegen
Maar om die keuze van sessie aan ip koppelen, hoe kun je dat het beste doen? Gewoon een cookie erbij met "geen_koppeling" => 1 en dat hij dan niet meer checkt op ip? Of is dat onveilig.

GreenSky schreef op zaterdag 19 april 2008 @ 13:46:
Je kunt met PHP ook de sessie id laten hergenereren, lijkt me voldoende toch. En SSL is natuurlijk het veiligst, maar je moet een afweging maken in de kosten en het doel van de site. (al hoeft SSL helemaal niet veel te kosten)

Laten hergenereren is dat dan echt veilig? Want Tweakers.net doet dat ook niet voor zover ik kan zien dus als je dat niet doet lijkt het me ook veilig toch?

iig thnx allemaal al voor jullie replys

[djiwie]

ChessSpider schreef op zaterdag 19 april 2008 @ 14:13:
Je krijgt een "lelijke" waarschuwing, maar zolang jij het ziet maakt het niet uit. Ik gebruik het ook voor mijn thuisserver.

Dat is niet bepaald het idee van SSL. Je moet je eigen certificaat eenmalig accepteren en als je dan op een gegeven moment toch een waarschuwing krijgt weet je dat je met de verkeerde server verbinding maakt (MITM, bijvoorbeeld).

Overigens zie ik niet in waarom het zoveel veiliger is om een sessie ID opnieuw te genereren, dat is slechts een schijnveiligheid. Er bestaat altijd het risico dat iemand de ID van het cookie overneemt, maar zolang je SSL gebruikt beperk je die mogelijkheid tot de computer van de eindgebruiker.

[Saven]

Mja het is niet alleen de MITM die die cookie kan stelen. Bijvoorbeeld via een ubb-code bug waardoor mensen javascript kunnen doen en cookies kunnen jatten

[djiwie]

Mja, true Maar je ging toch controleren op IP?

[ Voor 4% gewijzigd door djiwie op 19-04-2008 17:23 ]

[Voutloos]

Sessie id opnieuw genereren is om session fixation tegen te gaan, maar dat hoef je enkel op de kritieke punten te doen.

Een quote uit eenzelfde topic:

Voutloos schreef op donderdag 03 april 2008 @ 13:20:
Om session fixation tegen te gaan hoef je enkel deze functie te gebruiken tijdens kritieke acties, zoals bijvoorbeeld inloggen. Bijv: een sessie id is reeds bekend voor de anonieme gebruiker en zodra deze inlogt wordt er een andere sessie aangehangen. Op die wijze kan een aanvaller geen constructie maken waar hij jou een sessie id geeft/aansmeert, waar jij vervolgens mee inlogt en welke de aanvaller vervolgens kan gebruiken om zelf ingelogd te zijn.

[Saven]

djiwie schreef op zaterdag 19 april 2008 @ 17:23:
Mja, true Maar je ging toch controleren op IP?

Klopt maar dus ook een optie maken dat dat niet hoeft voor die belgen bijvoorbeeld dus.

Voutloos schreef op zaterdag 19 april 2008 @ 17:45:
Sessie id opnieuw genereren is om session fixation tegen te gaan, maar dat hoef je enkel op de kritieke punten te doen.

Een quote uit eenzelfde topic:

[...]

Ben niet helemaal thuis in die session wereld enzo. Dus kun je misschien uitleggen wat je bedoeld? Session fixation is als ik het goed begrijp dat een ander persoon jouw sessie kan setten. Maar ik werk met niks in de URL dus zou dat toch niet kunnen?
Sessie id wordt random gemaakt bij het inloggen dus valt niks aan te editen

[soczol]

Saven schreef op zaterdag 19 april 2008 @ 18:34:
Sessie id wordt random gemaakt bij het inloggen dus valt niks aan te editen

Maar je sessie ID wordt wel degelijk meegegeven; via een (session) cookie, ook deze cookie is natuurlijk gewoon aan te passen.

Een mooi voorbeeld van session fixation is trouwens te vinden bij Wikipedia: Wikipedia: Session fixation, het wordt inderdaad moeilijker als je geen session ID's in een URL toestaat.

Een voorbeeld waarbij het niet nodig is om URL's te misbruiken is XSS / cross site scripting:

Attacks using cross-site cooking

Another session fixation attack, cross-site cooking, exploits browser vulnerabilities. This allows a site http://evil/ to store cookies on browser in the cookie domain of another server http://good/, that is trusted. In order for this attack to succeed there is no need for any vulnerability within http://good/, as http://good/ may assume browser cookie management is secure.

Scenario:

1. Mallory sends Alice an e-mail: "Hey, check out this cool site, http://evil/".
2. Alice visits http://evil/, which will cookie SID with value I_WILL_KNOW_THE_SID into the domain of http://good/.
3. Alice then receives an e-mail from Mallory, "Hey, check out your bank account at http://good/".
4. When Alice logs on Mallory may use her account using the fixated session identifier.

[ Voor 82% gewijzigd door soczol op 19-04-2008 19:17 ]

[Saven]

soczol schreef op zaterdag 19 april 2008 @ 18:39:
[...]


Maar je sessie ID wordt wel degelijk meegegeven; via een (session) cookie, ook deze cookie is natuurlijk gewoon aan te passen.

iknow, maar je kan niet zelf een sessie-id maken

[!null]

Saven schreef op zaterdag 19 april 2008 @ 15:18:
[...]

Laten hergenereren is dat dan echt veilig? Want Tweakers.net doet dat ook niet voor zover ik kan zien dus als je dat niet doet lijkt het me ook veilig toch?

Ja dit om te zorgen dat de sessie id zo af en toe veranderd, waardoor er niets kwaads met de sessie id te doen valt.

[!null]

ChessSpider schreef op zaterdag 19 april 2008 @ 14:13:
[...]

Sterker nog, SSL is gratis.
Mocht je voor een applicatie SSL willen gebruiken die niet voor het grote publiek bedoelt is,kan je prima een eigen sleutel aanmaken. Je krijgt een "lelijke" waarschuwing, maar zolang jij het ziet maakt het niet uit. Ik gebruik het ook voor mijn thuisserver.

http://www.wampserver.com/phorum/read.php?2,32986
Is volgens mij wel een goede tutorial voor Windows/Apache.

Ok ik zat meer proffesioneel te denken. Waar je dus niet zo'n waarschuwing wil. Maar dan nog ben je volgens mij voor 20 euro per jaar al klaar.

[ChessSpider]

GreenSky schreef op zondag 20 april 2008 @ 13:11:
[...]


Ok ik zat meer proffesioneel te denken. Waar je dus niet zo'n waarschuwing wil. Maar dan nog ben je volgens mij voor 20 euro per jaar al klaar.

Hmm.. Linkje? Degene die ik heb gevonden kon er gemakkelijk nog een 0 achter geplaatst worden namelijk, en meestal nog een keer * 2 ook.

[!null]

Ja dan heb je er een van Verisign, dan zit je helemaal goed. Maar dat is niet altijd nodig.
http://www.google.nl/sear...&btnG=Google+zoeken&meta=