Gisteren kwam ik een presentatie tegen van Ilia Alshanetsky over beveiliging in PHP. Daar kwamen een aantal punten in voor die ik graag met jullie wil delen en benieuwd ben naar jullie mening/aanpak.

Punt 1: Session Fixation
Session fixation is een manier om een sessie te stelen waarbij de aanvaller vooraf weet welk session id het slachtoffer krijgt. (Dus niet zoals bij session hijacking waarbij het session id achteraf gestolen wordt.) Dit is toe te passen met bijvoorbeeld een link als:
jouw.bank.com/?PHPSESSID=foobar
Als het slachtoffer nu op de link klikt denkt de website dat het sessie id foobar is en gaat hier alle gegevens aan koppelen, de aanvaller kan nu simpelweg dat sessie id ook gebruiken.
De oplossing die hierbij gegeven wordt is door simpelweg na het inloggen een nieuw sessie id toe te wijzen waardoor de aanvaller geen kans meer heeft:

<?php
session_start();
// some login code
if ($login_ok) { // user logging in
session_regenerate_id(); // make new session id
?>


Punt 2: Session Hijacking
Een veel toegepaste techniek om [google]session hijacking[/google] (en ook helpt om session fixation) te voorkomen is een sessie koppelen aan een gebruiker. Maar hoe kan je nu een sessie aan een gebruiker koppelen? Een veelgebruikte manier daarvoor is om de sessie aan het IP adres van de gebruiker te koppelen, maar dit heeft een paar nadelen waaronder:
- Er kunnen meerdere mensen met het zelfde ip adres zijn (denk aan thuis- of sommige bedrijfsnetwerken).
- Een IP adres kan vaak wisselen.
- Een IP adres is te spoofen.
In de presentatie wordt ook een voorbeeld met een alternatief gegeven voor het koppelen van een sessie aan een ip adres, namelijk het koppelen aan de browser signature:

<?php
session_start();
$chk = @md5(
$_SERVER['HTTP_ACCEPT_CHARSET'] .
$_SERVER['HTTP_ACCEPT_ENCODING'] .
$_SERVER['HTTP_ACCEPT_LANGUAGE'] .
$_SERVER['HTTP_USER_AGENT']);
if (empty($_SESSION))
$_SESSION['key'] = $chk;
else if ($_SESSION['key'] != $chk)
session_destroy();
?>

Ook dit is niet helemaal water dicht omdat het vaker voor kan komen en door de gebruiker aan te passen is. Maar misschien is het een idee om ook nog het IP adres in de md5-hash mee te nemen?

Ik hoop dat iemand hier wat aan heeft of misschien zelfs wel andere manieren heeft om deze problemen te voorkomen/beveiligen.
Interessant.
Bedankt voor deze info.
Er zijn maar een paar $_SERVER vars die je kan vertrouwen.
Alle andere zijn gevoelig voor injecties.
Bijvoorbeeld:
$_SERVER['PHP_SELF'], $SERVER['HTTP_HOST'] en nog veel meer...

vermijd deze dan ook!
Dit geldt ook voor bijvoorbeeld de functie getimagesize();
eveneens een verleden van problemen en parst eigenlijk gehele images en is dus gevoelig voor eventuele code daarin...

Mijn tip:
Wat betreft vaste paden e.d. 'hard' code ze in constanten c.q const
$_SERVER['PHP_SELF'] vervangen door basename(__FILE__);

Wat je wel kan vertrouwen is $_SERVER['REMOTE_ADDR'].
Maar goed dat deed ik na alle elllende eigenlijk toch al niet meer...
En bovendien wil ik weten of het om een IPv4 of IPv6 gaat.

Mocht je dergelijke $_SERVER vars gebruiken valideer de inhoud en wees consequent!

Cross-Site-Request-Forgery
Cross-Site-Scripting
Header-Forgery

Maken allemaal gebruik van dergelijke ingangen als het kan...
Dus zoals ik al vaker heb gezegd vertouw NIKS, zelfs geen $_SERVER vars!
wat je kan moet hard coden en de rest op z'n mist valideren...

Wat betreft Session-Fixation
En dat geldt voor zoveel dingen. Commen-Pratice is gevoeligheid.
php functie setcookie(); werkt met http 1.0 headers.
Omdat miljoenen mensen IE, sessions, md5, sha1 gebruiken zijn dit ook de grootste hack doelwitten...

Dus ik heb daar al lang afstand van gedaan persoonlijk...

Tuurlijk is alles te hacken en/of matchen, maar als je het anders doet, kan je mensen wel op een heel ander 'onverwacht' spoor zetten....
<?php
$_SERVER['HTTP_ACCEPT_CHARSET']
$_SERVER['HTTP_ACCEPT_ENCODING']
$_SERVER['HTTP_ACCEPT_LANGUAGE']
$_SERVER['HTTP_USER_AGENT']
?>

Als je daar een Hash van maakt heb je inderdaad een goede 'fingerprint' van een gebruiker...

Dan heb je nog dingen als proxies.
welke eventueel gebruik kunnen maken van:

<?php
$_SERVER['HTTP_X_FORWARDED_FOR']
$_SERVER['HTTP_X_FORWARDED']
$_SERVER['HTTP_VIA']
$_SERVER['HTTP_PROXY']
$_SERVER['HTTP_PRAGMA']
$_SERVER['HTTP_FROM']
$_SERVER['HTTP_FORWARDED_FOR']
$_SERVER['HTTP_FORWARDED']
?>
Niet altijd het geval, maar voorkomen is beter als genezen..

En zo is er nog een hele waslijst met mogelijke $_SERVER vars voor proxies. En een aantal vaste poorten welke vaak/standaard gebruikt worden.
Dit soort bezoekers hebben bij mij iig geen rechten op 'ingelogt' blijven e.d.

Daarnaast heb je een aantal database welke te koop zijn met proxy ip's...

Er zijn genoeg lekken in Apache/php/mySql/pgSql... En ik ken er een hoop gelukkig maar zullen er altijd blijven....
nog een stap verder.... (wordt een tutorial ^^)

hashes:

http://www.php.net/hash bied alternatieven voor de eerder genoemde 'standaard' md5 / sha1 encrypties.

Daarnaast kan je gebruik maken van zogenaamde salt en pepper's...
appending / prepending opvullingen...

<?php
$salt = rand(100, 999);
$pepper = rand(100, 999);
/*
dit zijn dus altijd random getallen van iig 3 cijfers!
*/

$hash = hash('whirlpool', 'random_hash'); //whirlpool is echt te zwaar!!!
$hash = substr($hash, strlen($salt), strlen($hash) - strlen($pepper));
$hash = $salt.$hash.$pepper;
?>

En zo kan je nog veel verder gaan...

Dit is iig een voorbeeld van goede hash zonder md5 / sha1 en dus ook heel anders is...

EDIT:

omdat jij de lengte van de salt / pepper weet kan je de hash matchen als je die er weer afgehaald hebt...
Anders is het gokken tot en met....
Niet Bumpen.
Bumpen:
Twee of meer keer achter elkaar in een topic posten heet bumpen. Bumpen is pas na 24 uur toegestaan en kan een reden zijn voor de admins en moderators om een topic te sluiten. Gebruik indien nodig de knop om je tekst aan te passen.

SanThe.
Ik probeer (eindelijk) een beetje serieus te converseren over php... Ben een chaoot, dus sorry van mijn kant...
"Bumpen" klinkt nogal TMF, maar was iig niet de bedoeling...
Laten we het ook een klein beetje bij de eerder door mij genoemde punten blijven, anders kan ik ook nog wel een aantal andere voorbeelden uit de presentatie gaan geven waar veel mensen vast nog nooit over na gedacht hebben... (tenzij daar vraag naar is natuurlijk)
Oke...

Session-Fixation en de 'finger-printing' methode die je noemt zijn inderdaad erg nuttig!

Maar het gaat nog veel verder... Sorry dat ik daarop doordraai....
Ook bedankt voor de informatie, ik zal dit proberen te verwerken in mijn laatste script. Voor die fingerprint gebruikte ik alleen het ip-adres en de browser-agent, maar dit kan ik nu aanpassen.
Lode schreef op 21.02.2008 14:59
Oke...

Session-Fixation en de 'finger-printing' methode die je noemt zijn inderdaad erg nuttig!

Maar het gaat nog veel verder... Sorry dat ik daarop doordraai....


Nou, niet echt :P Ik vind het wel interessant om wat meer diepgang te lezen over beveiliging in php, dus van mij mag je nog wel doordraaien ;)

Reageren