Beveiliging
Ik wil mijn site zeer streng beveiligen.
Welke technieken gebruik ik het best? Waar moet ik op letten?
Welke technieken gebruik ik het best? Waar moet ik op letten?
User input is evil
Elke variabele die op een of andere manier van een gebruiker kan komen, moet worden gechecked. Zelfs $_SERVER['PHP_SELF'] is niet veilig! Cookies zijn niet veilig!
Pas op voor Remote File Inclusion: pas heel erg op met variabelen in include.
Escape elke data die je in een database stopt, of gebruik een typecast naar integer: (int) voor id's. Dus mysql_real_escape_string of, mooier, prepared statements.
Escape alle user data in je output: htmlentities($str, ENT_QUOTES);
Valideer data. Zie ctype_*() of filter_var().
Valideer je sessies.
Zorg dat je sessie data niet in een gedeelde map staat.
Voorkom CSRF (google maar) en geef alle belangrijke forms een extra hidden veld met een random waarde die je opslaat in de sessie.
Dat was het nodige, nu voor de paranoia-lijers: gebruik een intrusion detection system (bijv. PHP-IDS), dit check alle input (en evt output) op mogelijke hacks, maar verandert deze niet. Zo heb je een extra beveiliging voor zowel SQL injection als XSS.
Iemand nog iets toe te voegen?
EDIT: En als je toch bezig bent: koop een SSL certificaat ;)
Elke variabele die op een of andere manier van een gebruiker kan komen, moet worden gechecked. Zelfs $_SERVER['PHP_SELF'] is niet veilig! Cookies zijn niet veilig!
Pas op voor Remote File Inclusion: pas heel erg op met variabelen in include.
Escape elke data die je in een database stopt, of gebruik een typecast naar integer: (int) voor id's. Dus mysql_real_escape_string of, mooier, prepared statements.
Escape alle user data in je output: htmlentities($str, ENT_QUOTES);
Valideer data. Zie ctype_*() of filter_var().
Valideer je sessies.
Zorg dat je sessie data niet in een gedeelde map staat.
Voorkom CSRF (google maar) en geef alle belangrijke forms een extra hidden veld met een random waarde die je opslaat in de sessie.
Dat was het nodige, nu voor de paranoia-lijers: gebruik een intrusion detection system (bijv. PHP-IDS), dit check alle input (en evt output) op mogelijke hacks, maar verandert deze niet. Zo heb je een extra beveiliging voor zowel SQL injection als XSS.
Iemand nog iets toe te voegen?
EDIT: En als je toch bezig bent: koop een SSL certificaat ;)
Gewijzigd op 02/07/2010 20:26:45 door Pim -
Wat bedoel je juist met:
"Elke variabele die op een of andere manier van een gebruiken kan komen, moet worden gechecked."
"Elke variabele die op een of andere manier van een gebruiken kan komen, moet worden gechecked."
Typefout ;)
Gebruiken moet gebruiker zijn
Gebruiken moet gebruiker zijn
Sessies aan IP koppelen en deze keer op keer controleren, zodat Session-Hijacking erg moeilijk word.
Ook nooit betrouwbare informatie (bijvoorbeeld wachtwoord) in een sessie/cookie zetten. Zelfs niet geëncrypt!
Wachtwoorden altijd ge-hashed in de database voeren.
Edit:
http://www.phphulp.nl/php/tutorial/beveiliging/online-php-spel-beveiligen/489/
Staan ook dingen bij die voor een gewone site goed zijn om te onthouden!
Ook nooit betrouwbare informatie (bijvoorbeeld wachtwoord) in een sessie/cookie zetten. Zelfs niet geëncrypt!
Wachtwoorden altijd ge-hashed in de database voeren.
Edit:
http://www.phphulp.nl/php/tutorial/beveiliging/online-php-spel-beveiligen/489/
Staan ook dingen bij die voor een gewone site goed zijn om te onthouden!
Gewijzigd op 02/07/2010 21:42:06 door Mark L
Dat eerste is niet per se een goed idee: ip's kunnen wisselen tijdens de sessie... Beter kan je het met $_SERVER['HTTP_USER_AGENT'], doen. Wel een goed idee is, als je echt goede beveiliging wil hebben, een beperkte sessieduur. Dus 15 min inactief = uitgelogd.
Ook kan je bij elke request het sessie id verversen.
http://stackoverflow.com/questions/328/php-session-security
Ook kan je bij elke request het sessie id verversen.
http://stackoverflow.com/questions/328/php-session-security
Ik lees dat md5 niet veilig is. Wat moet ik dan gebruiken?
Pim de Haan op 02/07/2010 21:57:06:
... Beter kan je het met $_SERVER['HTTP_USER_AGENT'], doen...
User agent kan de client aanpassen.
MD5 is waarschijnlijk niet veilig omdat er veel programma's zijn die dat d.m.v. brute-force kunnen achterhalen.
Gewijzigd op 04/07/2010 18:54:42 door Erwin Geen
http://www.phphulp.nl/php/tutorial/beveiliging/online-php-spel-beveiligen/489/
http://blog.maxiblue.nl/websites/veilig-een-wachtwoord-oversturen/
http://blog.maxiblue.nl/websites/veilig-een-wachtwoord-oversturen/
Och, met een salt is het wel oké. En anders sha1 + salt. Altijd een salt.
En zeker niet twee keer een functie over elkaar gooien (md5(md5() dat zorgt er juist voor dat er minder uitkomsten zijn, aangezien er voor meerdere dingen dezelfde hash kan komen.
En zeker niet twee keer een functie over elkaar gooien (md5(md5() dat zorgt er juist voor dat er minder uitkomsten zijn, aangezien er voor meerdere dingen dezelfde hash kan komen.
Ja of je vernieuwd gewoon de sessie id om de 15 minuten.
Wesley Overdijk op 04/07/2010 23:42:41:
Ja of je vernieuwd gewoon de sessie id om de 15 minuten.
En dat helpt tegen wat?
Binnen vijftien minuten kan er zo ingebroken zijn, das lang hoor.
NOOIT je sessie aan een IP adres koppelen,
IP addressen zijn makkelijk te faken, dus het beschermd een stuk minder goed als je zou denken.
Ook zijn hosting bedrijven die van IP-farms gebruik maken, wat betekend dat een gebruiker iedere request een ander IP heeft. als je sessie aan IP bind dan kan zo'n persoon dus nooit inloggen bv,
hoe je sessie-hijacking dan wel oplost? laat de gebruiker zijn wachtwoord invoeren elke keer dat er iets belangrijks gebeurd (gegevens wijzigen bijvoorbeeld) op die manier kan een aanvaller niks doen als hij een sessie gestolen heeft.
Wat sessie-hijacking betreft is het belangrijker dat je ervoor zorgt dat een aanvaller niks schadelijks kan doen als hij eenmaal binnen is,
Wil je een bankrekening nummer laten zien? laat dan alleen de laatste 4 cijfers zijn en de rest sterretjes, dat soort dingen,
md5 is met bruteforce te kraken ja, net zoals ieder andere hash, een regulatie op het aantal inlog-pogingen is daarom ook handig, maar gezien een bruteforce aanval vanaf meerdere ip's kan komen is het moeilijk om dit effectief tegen te gaan.
IP addressen zijn makkelijk te faken, dus het beschermd een stuk minder goed als je zou denken.
Ook zijn hosting bedrijven die van IP-farms gebruik maken, wat betekend dat een gebruiker iedere request een ander IP heeft. als je sessie aan IP bind dan kan zo'n persoon dus nooit inloggen bv,
hoe je sessie-hijacking dan wel oplost? laat de gebruiker zijn wachtwoord invoeren elke keer dat er iets belangrijks gebeurd (gegevens wijzigen bijvoorbeeld) op die manier kan een aanvaller niks doen als hij een sessie gestolen heeft.
Wat sessie-hijacking betreft is het belangrijker dat je ervoor zorgt dat een aanvaller niks schadelijks kan doen als hij eenmaal binnen is,
Wil je een bankrekening nummer laten zien? laat dan alleen de laatste 4 cijfers zijn en de rest sterretjes, dat soort dingen,
md5 is met bruteforce te kraken ja, net zoals ieder andere hash, een regulatie op het aantal inlog-pogingen is daarom ook handig, maar gezien een bruteforce aanval vanaf meerdere ip's kan komen is het moeilijk om dit effectief tegen te gaan.
error_reporting 30719 (= E_ALL)
display_errors Off
error_log /pad/naar/error_log
Het bestand error_log buiten de webroot plaatsen, en chmod 600, de owner root.
Let op: $_SERVER['HTTP_USER_AGENT'] hoeft niet te bestaan!
Alle HTTP_* headers zijn door de bezoeker aan te passen.
display_errors Off
error_log /pad/naar/error_log
Het bestand error_log buiten de webroot plaatsen, en chmod 600, de owner root.
Let op: $_SERVER['HTTP_USER_AGENT'] hoeft niet te bestaan!
Alle HTTP_* headers zijn door de bezoeker aan te passen.




