Heeft iemand tips om je inlog script veilig en netjes te schrijven?
Ik sla bijvoorbeeld het gebruiker id op in een sessie die ik later weer gebruik, is dit veilig?
3.341 views
Nee, wat sessies kan de gebruiker aanpassen. Dan kan iemand dus gewoon voordoen alsof hij de administrator is, door gewoon even zijn ID in te voeren.
Wat je het beste kan doen is een random hash maken (bijv. met [php]uniqid[/php]) en die dan opslaan in een sessie en in de database. Zodra de sessie en database overeenkomen is de gebruiker ingelogd, anders niet.
Wat je het beste kan doen is een random hash maken (bijv. met [php]uniqid[/php]) en die dan opslaan in een sessie en in de database. Zodra de sessie en database overeenkomen is de gebruiker ingelogd, anders niet.
Wouter J op 23/01/2015 13:48:57
Nee, wat sessies kan de gebruiker aanpassen.
Hoe dan?
Volgens mij is WouterJ in de war met cookies.
Overigens loont wel om bij het uitloggen de sessie opnieuw te genereren met session_regenerate(), om te voorkomen dat iemand de sessie kan kapen als iemand uitgelogd is, en iemand de cookies heeft gejat via XXS?
Of was dit nou niet zo?
Overigens loont wel om bij het uitloggen de sessie opnieuw te genereren met session_regenerate(), om te voorkomen dat iemand de sessie kan kapen als iemand uitgelogd is, en iemand de cookies heeft gejat via XXS?
Of was dit nou niet zo?
Dus je moet eigenlijk een random hash genereren en die in de tabel van de gebruiker stoppen en die zelfde in de sessie. En dan kan je de sessie vergelijken met de hash uit de database.
Is dat goed?
Is dat goed?
Als je met cookies werkt wel, zoals ik vroeger wel eens deed. Toen had ik een hash in de database staan, die overeenkwam met een cookie. Maar je zit wel direct met het probleem dan je met een XXS-lek een groot impact hebt. Dat valt tegen te houden met een controle op IP's, maar het blijft niet waterdicht binnen bedrijfs/scholen-netwerken.
Als je een userID in een sessie bewaart zit je erg veilig. Wel is het aan te raden om regelmatig session_regenerate_id() te draaien, zodat de sessie een ander ID zal krijgen. Dit kan bijv. bij een uitlog van een account.
Als je een userID in een sessie bewaart zit je erg veilig. Wel is het aan te raden om regelmatig session_regenerate_id() te draaien, zodat de sessie een ander ID zal krijgen. Dit kan bijv. bij een uitlog van een account.
Je kunt ook even $_SESSION = array() doen bij het uitloggen.
Dan heb je immers alleen nog een sessie-ID en verder niets.
Het probleem is hier dat sessiebestanden niet meteen verwijderd worden. Dit is afhankelijk van de instellingen van de garbage collector (GC). De kans dat de garbage collector aanslaat, is om precies te zijn session.gc_probability : session.gc_divisor (in php.ini). Zet je de sessie "hard" op een lege array, dan heb je nog wel een sessiebestand, maar is het gewoon leeg. Einde oefening.
Dan heb je immers alleen nog een sessie-ID en verder niets.
Het probleem is hier dat sessiebestanden niet meteen verwijderd worden. Dit is afhankelijk van de instellingen van de garbage collector (GC). De kans dat de garbage collector aanslaat, is om precies te zijn session.gc_probability : session.gc_divisor (in php.ini). Zet je de sessie "hard" op een lege array, dan heb je nog wel een sessiebestand, maar is het gewoon leeg. Einde oefening.
Mag je ook gewoon session_destroy(); doen?
Michael R op 23/01/2015 14:19:18
Mag je ook gewoon session_destroy(); doen?
Als je daarna session_start() doet heb je hem weer teug.
Ikzelf doe dit:
session_start();
....
Bij uitloggen:
session_destroy();
session_id(sha1(microtime()));
session_start();
Dan heb je een totaal nieuwe session.
Oke, bedankt.
Neem ook even het sessiecookie mee, voor de volledigheid.
<?php
if (ini_get('session.use_cookies')) {
$cookie_params = session_get_cookie_params();
setcookie(session_name(), '', time() - 42000, $cookie_params['path'], $cookie_params['domain'], $cookie_params['secure'], $cookie_params['httponly']);
}
?>