Beveiliging
Welke technieken gebruik ik het best? Waar moet ik op letten?
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 -
"Elke variabele die op een of andere manier van een gebruiken kan komen, moet worden gechecked."
Gebruiken moet gebruiker zijn
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
Ook kan je bij elke request het sessie id verversen.
http://stackoverflow.com/questions/328/php-session-security
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://blog.maxiblue.nl/websites/veilig-een-wachtwoord-oversturen/
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.
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.
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.
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.