Lorsqu'une application ne renouvelle pas son cookie de session(s) après une authentification de l'utilisateur, il pourrait être possible de trouver une faille de fixation de session et forcer un utilisateur d'utiliser un cookie délivré par l'attaquant. Dans ce cas, un attaquant pourrait voler la session de l'utilisateur (session hijacking).
Une vulnérabilité en fixation de session se produit lorsque:
En outre, le problème décrit ci-dessus est critique pour les sites qui délivrent un identifiant de session sur HTTP, puis redirigent l'utilisateur vers un formulaire de connexion HTTPS. Si l'identifiant de session n'est pas réédité lors de l'authentification, l'identifiant peut être intercepté et peut être utilisé par un attaquant pour détourner la session.
La première étape consiste à faire une demande sur le site à tester (www.example.com par exemple). Si nous demandons ce qui suit:
GET www.example.com
Nous obtiendrons la réponse suivante:
HTTP/1.1 200 OK Date: Wed, 14 Aug 2008 08:45:11 GMT Server: IBM_HTTP_Server Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1; Path=/; secure Cache-Control: no-cache="set-cookie,set-cookie2" Expires: Thu, 01 Dec 1994 16:00:00 GMT Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html;charset=Cp1254 Content-Language: en-US
Nous observons que l'application définit un nouvel identifiant de session jsessionid = 0000d8eyYq3L0z2fgq10m4v-rt4:-1 pour le client. Ensuite, si nous avons réussi nous authentifier sur l'application avec le POST HTTPS suivants:
POST https://www.example.com/authentication.php HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://www.example.com Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 Content-Type: application/x-www-form-urlencoded Content-length: 57 ... Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in
Nous observons la réponse suivante du serveur:
HTTP/1.1 200 OK Date: Thu, 14 Aug 2008 14:52:58 GMT Server: Apache/2.2.2 (Fedora) X-Powered-By: PHP/5.1.6 Content-language: en Cache-Control: private, must-revalidate, max-age=0 X-Content-Encoding: gzip Content-length: 4090 Connection: close Content-Type: text/html; charset=UTF-8 ... HTML data ...
Comme aucun nouveau cookie n'a été délivré sur une authentification réussie, nous savons qu'il est possible d'effectuer le détournement de session.
Nous pouvons envoyer un identifiant de session valide pour un utilisateur (éventuellement en utilisant l'ingénierie sociale), et attendre qu'ils s'authentifient pour vérifier ultérieurement que les privilèges ont été affectés à ce cookie.
Les entretiens avec les développeurs doivent permettre de comprendre si ils ont mis en place un mécanisme de renouvellement du jeton de sessionaprès une authentification utilisateur réussie.
La demande doit toujours, en premier, invalider l'ID de session existant avant l'authentification d'un utilisateur, et si l'authentification est réussie, fournir un autre sessionID.