[PHP] session_regenerate_id

[RSD]

Ik vroeg me af of het nut heeft om bij elke pagina aanroep waar een sessie gestart wordt ook meteen session_regenerate_id uit te voeren. Zelf heb ik het idee dat dit wel eens nut kan hebben, omdat zo het session_id erg variabel is en zo is de kans op een succesvolle XSS poging alweer iets kleiner. Het is niet geheel weg, maar wel voor een gedeelte. Klopt dit ook of niet?

Als iemand bijvoorbeeld een XSS attack probeert uit te voeren en hij heeft de cookie gegevens eenmaal van die pagina aanroep, maar degene bij wie hij het probeert is alweer op een andere pagina geweest en dus zijn zijn gegevens alweer verandert en dus is de inhoud van de gestolen cookie weer waardeloos.

[ Voor 28% gewijzigd door RSD op 19-06-2007 13:59 ]

[Janoz]

Het lijkt me makkelijker om een sessie aan een IP te koppelen. Op het moment dat jij je sessieId aanpast kan het best zijn dat je gebruiker een request met de oude sessieId stuurt. Hierdoor kunnen bepaalde delen van de pagina ineens uitgelogd zijn bijvoorbeeld.

Denk bijvoorbeeld aan een pagina waarop middels php gegenereerde plaatjes staan. Dat zijn toch al meerdere requests per pagina. Een ander voorbeeld zijn ajax requests.

[RSD]

Hoe koppel je zoiets aan een ip dan (middels een cookie?). Ik lees veel zaken over het moeilijk verkrijgen van een ip adres van iemand en dan ook nog als ze achter proxies zitten.

Met die session_regenerate_id is het dus niet zo dat als ik die meteen aanroep, na session start, dat dan alles aangepast is? En een eventueel later gegenereerd plaatje kijkt dan ook naar het oude nog. Dat is toch vreemd.

[Janoz]

Tja, zo moeilijk lijkt me dat niet. IP opslaan in sessie en bij elke pagina kijken of de ip wel overeenkomt. Ik zie verder niet in wat de relevantie is van "Ik lees veel zaken over het moeilijk verkrijgen van een ip adres van iemand". Je hoeft niet het exacte interne ip adres van de gebruiker te hebben, maar gewoon degene waarmee hij binnenkomt op je site. het volgende request zal met zeer grote zekerheid daar ook weg komen. Enkel een proxy is vervelend wanneer deze van IP wisselt (AOL gebruikers meen ik). Je zou in dit geval de gebruiker de optie kunnen geven om het IP niet aan de sessie te koppelen.

De sessieId is pas aangepast zodra de browser ook op de hoogte gebracht is van de nieuwe sessieId. Wanneer er twee requests zijn dan is het tweede request al begonnen op het moment dat het resultaat van de eerste nog terug moet komen. Zo raar is dat dus helemaal niet. Je hebt hier ten slotte niet met enkel 1 omgeving te maken.

[frickY]

Zoiets is al voldoende om te voorkomen dat een sessie vanaf een ander IP wordt gebruikt.

PHP:

<?php
if(!isset($_SESSION['IP'])) {
  $_SESSION['IP'] = $_SERVER['REMOTE_ADDR'];
} elseif($_SESSION['IP'] != $_SERVER['REMOTE_ADDR']) {
  exit("session hijacked");
}
?>

[ Voor 3% gewijzigd door frickY op 19-06-2007 15:30 ]

[Verwijderd]

Een andere mogelijkheid is dit in te bouwen in een custom save handler, zo kan je voorkomen dat de sessie nog maar voortgezet wordt als het IP-adres niet overeen komt. Dit kan in de open-callback gebeuren.

[Cartman!]

Op deze pagina is wel goede info te vinden over session fixation & session hijacking en hoe je dit kunt voorkomen.

Een sessie automatisch op ip locken vind ik niet een goede methode omdat mensen achter een load balancer (op t werk n tijdje gehad) of met veel wisselent ip dan nooit ergens een goede sessie kunnen houden. In plaats daarvan kun je dus ook op user agent checken. Je houdt de user agent bij en checkt voor je de pagina oproept of de huidige user agent gelijk is aan de pagina ervoor. Als die anders is weet je dat er geknoeid is met de sessie.
Of je soortgelijk iets wilt toepassen op ip is je eigen keuze dus.

[MisterData]

Wisselende session_id's zijn inderdaad niet zo handig vanwege de verschillende requests die met dezelfde session_id zullen worden gedaan. Form-submits daarentegen zijn eventueel wel te beveiligen door een verborgen veld toe te voegen, waarin een 'token' zit dat maar één keer voor een submit mag worden gebruikt:

PHP:

// formulier.php
<?php
$token = random_getal(....);
$_SESSION['tokens'][] = $token;
?>

<form action="submit.php">
<input type="hidden" name="token" value="<?php echo $token ?>" />

[..]
</form>

// Submit.php
<?php
$token = $_REQUEST['token'];
if(!in_array($_SESSION['tokens'], $token)) {
// sessie afkappen
}

// formulier hier verwerken

if($succesvol_verwerkt) {
  array_remove($_SESSION['tokens'], $token); // haal de token weer uit de lijst
}
?>

Dat is een redelijk simpele beveiliging en zou ook nog wel eens kunnen werken tegen bepaalde domme spambots die automatisch formulieren invullen (het voorkomt ook het meerdere keren opsturen en verwerken van hetzelfde formulier als de gebruiker twee keer drukt) Wat hierboven staat is trouwens redelijk pseudo-code, er moet natuurlijk nog error checking bij enzo, maar voor het idee... Dat helpt dus niet tegen hijacking (hoewel, je kunt ieder 'token' ook koppelen aan een user-agent en ip) maar is misschien wel zinvol.

[Verwijderd]

Een unieke code die alleen de server en de client kennen, is voldoende voor niet kritieke applicaties. Voor een forum, een extranet, wat dan ook, kun je meestal gewoon volstaan met... een session id. 128 willekeurige bits. Zie dat maar eens goed te gokken. Als je dan ook nog eens ip's bijhoudt vanwaar je de client "veilig" kan laten inloggen (keuze van de client), zit je redelijk safe.

Je moet deze "code" (gewoon de session id) dus zowel in de cookie zetten, als in het formulier. Zo weet je dat dat formulier door de server moet zijn gegenereerd.

[MisterData]

Verwijderd schreef op dinsdag 19 juni 2007 @ 21:23:
Een unieke code die alleen de server en de client kennen, is voldoende voor niet kritieke applicaties. Voor een forum, een extranet, wat dan ook, kun je meestal gewoon volstaan met... een session id. 128 willekeurige bits. Zie dat maar eens goed te gokken. Als je dan ook nog eens ip's bijhoudt vanwaar je de client "veilig" kan laten inloggen (keuze van de client), zit je redelijk safe.

Je moet deze "code" (gewoon de session id) dus zowel in de cookie zetten, als in het formulier. Zo weet je dat dat formulier door de server moet zijn gegenereerd.

Tsja, ik kan het heel makkelijk een session_id van iemand hier in huis jatten, hoef ik maar z'n PC op een hub (niet switch!) aan te sluiten en een sniffer te draaien... tadaa! Maarja, voor applicaties waar identificatie & authenticatie écht belangrijk is gebruik je natuurlijk sowieso SSL