Beveiliging van inlogsysteem
Ik sla bijvoorbeeld het gebruiker id op in een sessie die ik later weer gebruik, is dit veilig?
- Aar -:
Titel aangepast naar: Beveiliging van inlogsysteem.
Gewijzigd op 23/01/2015 13:58:14 door - Ariën -
Wat je het beste kan doen is een random hash maken (bijv. met uniqid) 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?
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?
Is dat goed?
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.
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.
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.
Gewijzigd op 23/01/2015 14:31:03 door - SanThe -
Code (php)
1
2
3
4
5
6
2
3
4
5
6
<?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']);
}
?>
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']);
}
?>
- session_regenerate() aanroepen na een succesvolle login.
- prepared statements (correct) gebruiken.
- password_verify() gebruiken.
- rate limiting
- de applicatie met de database laten verbinden met een account dat zo weinig mogelijk rechten heeft. Als je applictie SQL-injection toe laat maar het account niets kan droppen of alteren maar alleen kan lezen en beperkte tabellen kan updaten blijft de schade alsnog beperkt.
Maar het liefst heb je een applicatie die geen SQL-injection toe laat EN verbind met de database als een account met beperkte rechten. Ook wel bepend als Defence in Depth en Least Privilege Principle.
Als je code hebt geschreven, plaats het dan op dit forum en vraag op feedback.
PS. Als je op een shared server zit dan is het mogelijk dat andere op de zelfde server de sessies van jou gebruikers kunnen uitlezen en wijzigen. Hoort niet te kunnen als de server goed opgezet is... dus een hash zoals Wouter zegt is dan een stuk moeilijker om te vervalsen dan een user id, aangezien veel applicaties de user id info lekken.
Verder bedoel je denk ik session_regenerate_id?
Quote:
Wait, what?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.
Quote:
Of je zorgt er gewoon voor dat jouw sessie-bestanden naar jouw webruimte worden weggeschreven via session_save_path(). Wel zorgen dat dit een folder buiten je document root is uiteraard...PS. Als je op een shared server zit dan is het mogelijk dat andere op de zelfde server de sessies van jou gebruikers kunnen uitlezen en wijzigen. Hoort niet te kunnen als de server goed opgezet is... dus een hash zoals Wouter zegt is dan een stuk moeilijker om te vervalsen dan een user id, aangezien veel applicaties de user id info lekken.
@Michael R: het is niet zozeer dat je loginscript veilig is, maar meer dat je je code op een zodanige manier opgezet is, zodat deze veilig is in het gebruik. Dit zal voor een deel staan of vallen met hoe je omgaat met INPUT en OUTPUT. Denk bij INPUT aan formulieren ($_POST), querystring-parameters ($_GET) et cetera. Ook OUTPUT kan gevaarlijk zijn, iemand kan bijvoorbeeld in staat zijn om JavaScript af te drukken en hiermee uit te voeren, tenzij je deze "onklaar" maakt.
"Veiligheid" is niet in één groot enkel onderwerp te vangen, het is een samenspel van verschillende dingen. Ik zou zeggen ga op onderzoek uit, bijvoorbeeld: hoe werken sessies, kijk hoe je veilig queries kunt uitvoeren, kijk hoe je veilig kunt omgaan met user input, kijk hoe je veilig kunt omgaan met user output. Zoek uit hoe escaping in verschillende contexten werkt, zorg voor, bij voorkeur, een enkele character encoding in alles wat je doet.
Als je de volgende stelregel in alles wat je doet toepast, of in ieder geval in je achterhoofd houdt, kom je al een heel eind:
filter input, escape output.
Moet je natuurlijk wel snappen wat dit inhoudt :-).