Beveiliging van inlogsysteem

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Michael R

Michael R

23/01/2015 13:45:58
Quote Anchor link
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?
- Aar -:
Titel aangepast naar: Beveiliging van inlogsysteem.
Gewijzigd op 23/01/2015 13:58:14 door - Ariën -
 
PHP hulp

PHP hulp

11/04/2021 23:24:56
 
Wouter J

Wouter J

23/01/2015 13:48:57
Quote Anchor link
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 uniqid) en die dan opslaan in een sessie en in de database. Zodra de sessie en database overeenkomen is de gebruiker ingelogd, anders niet.
 
- SanThe -

- SanThe -

23/01/2015 13:51:34
Quote Anchor link
Wouter J op 23/01/2015 13:48:57:
Nee, wat sessies kan de gebruiker aanpassen.


Hoe dan?
 
- Ariën -
Beheerder

- Ariën -

23/01/2015 13:57:26
Quote Anchor link
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?
 
Michael R

Michael R

23/01/2015 14:01:58
Quote Anchor link
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?
 
- Ariën -
Beheerder

- Ariën -

23/01/2015 14:07:05
Quote Anchor link
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.
 
Ward van der Put
Moderator

Ward van der Put

23/01/2015 14:12:41
Quote Anchor link
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.
 
Michael R

Michael R

23/01/2015 14:19:18
Quote Anchor link
Mag je ook gewoon session_destroy(); doen?
 
- SanThe -

- SanThe -

23/01/2015 14:26:02
Quote Anchor link
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 -
 
Michael R

Michael R

23/01/2015 14:30:09
Quote Anchor link
Oke, bedankt.
 
Ward van der Put
Moderator

Ward van der Put

23/01/2015 14:54:56
Quote Anchor link
Neem ook even het sessiecookie mee, voor de volledigheid.

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
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']);
}

?>
 
Dos Moonen

Dos Moonen

23/01/2015 22:09:02
Quote Anchor link
- Inloggen via HTTPS als het even kan.
- 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.
 
Frank Nietbelangrijk

Frank Nietbelangrijk

24/01/2015 00:54:37
Quote Anchor link
@Dos: Is rate limiting het aantal login-pogingen beperken? Hoe zou je dit aanpakken?

Verder bedoel je denk ik session_regenerate_id?
 
Thomas van den Heuvel

Thomas van den Heuvel

24/01/2015 16:07:02
Quote Anchor link
Quote:
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.
Wait, what?

Quote:
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.
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...

@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 :-).
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.