This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "4.7.3 Tester les fixations de session (OTG-SESS-003)"

From OWASP
Jump to: navigation, search
(Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == When an application does not renew its session cookie(s) after a successful user authentication, it could be possible to fi...")
 
 
Line 2: Line 2:
  
 
== Sommaire ==
 
== Sommaire ==
−
When an application does not renew its session cookie(s) after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie known by the attacker. In that case, an attacker could steal the user session (session hijacking).
+
Quand une application ne renouvelle pas son/ses cookie(s) de session après une authentification réussie, il est possible de trouve une vulnérabilité de fixation de session et de forcer un utilisateur à utiliser un cookie connu de l'attaquant. Dans ce cas, un attaquant peut détourner la session de l'utilisateur (session hijacking).
  
  
−
Session fixation vulnerabilities occur when:<br>
+
Les vulnérabilité de fixation de session apparaissent quand :<br>
−
* A web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user.
+
* Une application web authentifie un utilisateur sans d'abord invalider l'identifiant de session existant, continuant ainsi à utiliser l'identifiant de session déjà associé à l'utilisateur.
−
* An attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session.  
+
* Un attaquant peut forcer un utilisateur à utiliser un identifiant de session connu permettant à l'attaquant, une fois l'utilisateur authentifié, d'accéder à la session authentifiée.
  
  
−
In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user's account through the active session.
+
Dans le cas général d'exploitation de fixation de session, un attaquant crée une nouvelle session sur une application web et enregistre l'identifiant de session associé. Ensuite, l'attaquant pousse la victime à s'authentifier sur le serveur en utilisant le même identifiant de session, donnant ainsi à l'attaquant accès au compte de l'utilisateur via la session active.
  
  
−
Furthermore, the issue described above is problematic for sites that issue a session identifier over HTTP and then redirect the user to a HTTPS log in form. If the session identifier is not reissued upon authentication, the attacker can eavesdrop and steal the identifier and then use it to hijack the session.
+
De plus, le soucis décrit plus haut est problématique pour les sites qui envoient des identifiant de session via HTTP, puis redirigent les utilisateurs vers un formulaire d'authentification en HTTPS. Si l'identifiant de session n'est pas renouvelé lors de l'authentification, l'attaquand peut espionner et voler l'identifiant, puis l'utiliser pour détourner la session.
  
−
==How to Test==
+
==Comment tester==
−
=== Black Box Testing ===
+
=== Test en boite noire ===
−
'''Testing for Session Fixation vulnerabilities:''' <br>
+
'''Tester les vulnérabilités de fixation de session:''' <br>
−
The first step is to make a request to the site to be tested (example www.example.com). If the tester requests the following:
+
La première étape est de faire une requête vers le site à tester (par exemple www.example.com). Si le testeur envoit cette requête :
 
  GET www.example.com
 
  GET www.example.com
−
They will obtain the following answer:
+
Il va obtenir la réponse suivante :
 
<pre>
 
<pre>
 
HTTP/1.1 200 OK
 
HTTP/1.1 200 OK
Line 35: Line 35:
  
  
−
The application sets a new session identifier JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 for the client.  
+
L'application crée un nouvel identifiant de session JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 pour le client.
  
  
−
Next, if the tester successfully authenticates to the application with the following POST HTTPS:
+
Ensuite, si le testeur réussi à s'authentifier sur l'application au moyen du POST HTTPS suivant :
 
<pre>
 
<pre>
 
POST https://www.example.com/authentication.php HTTP/1.1
 
POST https://www.example.com/authentication.php HTTP/1.1
Line 58: Line 58:
  
  
−
The tester observes the following response from the server:
+
Le testeur observe la réponse suivante renvoyée par le serveur :
 
<pre>
 
<pre>
 
HTTP/1.1 200 OK
 
HTTP/1.1 200 OK
Line 76: Line 76:
  
  
−
As no new cookie has been issued upon a successful authentication the tester knows that it is possible to perform session hijacking.
+
Aucun nouveau cookie n'a été envoyé suite à l'authentification réussie. Le testeur sait qu'il est possible de procéder à un détournement de session.
  
  
  
−
'''Result Expected:'''
+
'''Résultat attendu :'''
−
The tester can send a valid session identifier to a user (possibly using a social engineering trick), wait for them to authenticate, and subsequently verify that privileges have been assigned to this cookie.
+
Le testeur peut envoyer un identifiant de session valide à un utilisateur (par ingénierie sociale, par exemple), attendre que ce dernier s'authentifie, et ensuite vérifier que les privilèges ont été assignés à ce cookie.
  
  
−
=== Gray Box Testing ===  
+
=== Test en boite grise ===  
−
Talk with developers and understand if they have implemented a session token renew after a user successful authentication.
+
Parlez avec les développeurs et comprenez s'il ont implémenté un renouvellement de jeton de session après une authentification réussie.
  
  
−
'''Result Expected:'''
+
'''Résultat attendu :'''
−
The application should always first invalidate the existing session ID before authenticating a user, and if the authentication is successful, provide another sessionID.
+
L'application devrait toujours invalider l'identifiant de session existant avant d'authentifier un utilisateur, et si l'authantification est réussie, fournir un autre identifiant de session.
  
  
−
==Tools==
+
==Outils==
−
* JHijack - a numeric session hijacking tool - http://yehg.net/lab/pr0js/files.php/jhijackv0.2beta.zip
+
* JHijack - un outil numérique de détournement de session - http://yehg.net/lab/pr0js/files.php/jhijackv0.2beta.zip
 
* OWASP WebScarab: [[OWASP_WebScarab_Project]]
 
* OWASP WebScarab: [[OWASP_WebScarab_Project]]
  

Latest revision as of 14:11, 21 November 2014

This article is part of the new OWASP Testing Guide v4.

Back to the OWASP Testing Guide v4 ToC:
   https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents
Back to the OWASP Testing Guide Project:
   https://www.owasp.org/index.php/OWASP_Testing_Project

Sommaire

Quand une application ne renouvelle pas son/ses cookie(s) de session après une authentification réussie, il est possible de trouve une vulnérabilité de fixation de session et de forcer un utilisateur à utiliser un cookie connu de l'attaquant. Dans ce cas, un attaquant peut détourner la session de l'utilisateur (session hijacking).


Les vulnérabilité de fixation de session apparaissent quand :

  • Une application web authentifie un utilisateur sans d'abord invalider l'identifiant de session existant, continuant ainsi à utiliser l'identifiant de session déjà associé à l'utilisateur.
  • Un attaquant peut forcer un utilisateur à utiliser un identifiant de session connu permettant à l'attaquant, une fois l'utilisateur authentifié, d'accéder à la session authentifiée.


Dans le cas général d'exploitation de fixation de session, un attaquant crée une nouvelle session sur une application web et enregistre l'identifiant de session associé. Ensuite, l'attaquant pousse la victime à s'authentifier sur le serveur en utilisant le même identifiant de session, donnant ainsi à l'attaquant accès au compte de l'utilisateur via la session active.


De plus, le soucis décrit plus haut est problématique pour les sites qui envoient des identifiant de session via HTTP, puis redirigent les utilisateurs vers un formulaire d'authentification en HTTPS. Si l'identifiant de session n'est pas renouvelé lors de l'authentification, l'attaquand peut espionner et voler l'identifiant, puis l'utiliser pour détourner la session.

Comment tester

Test en boite noire

Tester les vulnérabilités de fixation de session:
La première étape est de faire une requête vers le site à tester (par exemple www.example.com). Si le testeur envoit cette requête : 

GET www.example.com

Il va obtenir 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


L'application crée un nouvel identifiant de session JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 pour le client.


Ensuite, si le testeur réussi à s'authentifier sur l'application au moyen du POST HTTPS suivant : 

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


Le testeur observe la réponse suivante renvoyée par le 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
...


Aucun nouveau cookie n'a été envoyé suite à l'authentification réussie. Le testeur sait qu'il est possible de procéder à un détournement de session.


Résultat attendu : Le testeur peut envoyer un identifiant de session valide à un utilisateur (par ingénierie sociale, par exemple), attendre que ce dernier s'authentifie, et ensuite vérifier que les privilèges ont été assignés à ce cookie.


Test en boite grise

Parlez avec les développeurs et comprenez s'il ont implémenté un renouvellement de jeton de session après une authentification réussie.


Résultat attendu : L'application devrait toujours invalider l'identifiant de session existant avant d'authentifier un utilisateur, et si l'authantification est réussie, fournir un autre identifiant de session.


Outils


References

Whitepapers


Retrieved from "https://wiki.owasp.org/index.php?title=4.7.3_Tester_les_fixations_de_session_(OTG-SESS-003)&oldid=185714"