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:

• Une application Web authentifie un utilisateur sans invalider l'ID de session existante, continuant ainsi d'utiliser l'ID de session déjà associé à l'utilisateur.
• Un attaquant peut forcer un ID de session connue sur un utilisateur de sorte que, une fois l'utilisateur authentifié, l'attaquant ait accès à la session authentifiée. Dans l'exploit générique des vulnérabilités de fixation de session, un attaquant crée une nouvelle session sur une application web et enregistre l'identifiant de session associée. *L'attaquant incite alors la victime à s'authentifier sur le serveur en utilisant cet identifiant de session, lui donnant ainsi accès au compte de l'utilisateur dans la session active.

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.

• Session Fixation

  • ACROS Security: http://www.acrossecurity.com/papers/session_fixation.pdf
  • Chris Shiflett: http://shiflett.org/articles/session-fixation

• JHijack - un outil numérique de détournement de session - http://yehg.net/lab/pr0js/files.php/jhijackv0.2beta.zip

  • OWASP WebScarab: OWASPWebScarabProject