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.4 Tester les variables de session exposées (OTG-SESS-004)"

From OWASP
Jump to: navigation, search
(Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim...")
 
 
Line 3: Line 3:
 
== Sommaire ==
 
== Sommaire ==
  
−
The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim and access the application illegitimately. It is important that they are protected from eavesdropping at all times, particularly whilst in transit between the client browser and the application servers.  
+
S'ils sont exposé, les jetons de session (Cookie, identifiant de session, champs caché) vont permettre à un attaquant d'usurper l'identité d'une victime et d'accèder frauduleusement à l'application. Il est important que ces jetons soit protégés contre l'espionnage, particulièrement pendant leur transit entre navigateur client et serveurs d'application.
 
<br>
 
<br>
  
 
   
 
   
−
The information here relates to how transport security applies to the transfer of sensitive Session ID data rather than data in general, and may be stricter than the caching and transport policies applied to the data served by the site.
+
Ici, nous nous concentrons sur la sécurité du transport appliquée au transfert d'identifiant de session sensible, plutôt que de données en général, ce qui peut être plus strict que les données en cache et les politiques de transport des données servies par le site.
  
  
−
Using a personal proxy, it is possible to ascertain the following about each request and response:
+
En utilisant un proxy personnel, il est possible de vérifier pour chaque requête et réponse :
−
* Protocol used (e.g., HTTP vs. HTTPS)
+
* Le protocole utilisé (HTTP ou HTTPS)
−
* HTTP Headers
+
* Les entêtes HTTP
−
* Message Body (e.g., POST or page content)
+
* Le corps du message (POST, contenu de page)
  
  
−
Each time Session ID data is passed between the client and the server, the protocol, cache, and privacy directives and body should be examined. Transport security here refers to Session IDs passed in GET or POST requests, message bodies, or other means over valid HTTP requests.
+
Chaque fois que les données d'identifiant de session sont transmises entre le client et le serveur, le protocole, le cache, et les directives de confidentialité doivent être examinées. La securité de transport se réfère ici aux identifiants de session transmis en requêtes GET ou POST, au corps des messages, ou autres moyens dans des requêtes HTTP valides.
  
  
−
==How to Test==
+
==Comment tester==
  
−
'''Testing for Encryption & Reuse of Session Tokens vulnerabilities:''' <br>
+
'''Tester les vulnérabilités sur le chiffrement et la réutilisation des jetons de session :''' <br>
−
Protection from eavesdropping is often provided by SSL encryption, but may incorporate other tunneling or encryption. It should be noted that encryption or cryptographic hashing of the Session ID should be considered separately from transport encryption, as it is the Session ID itself being protected, not the data that may be represented by it.
+
La protection contre l'espionnage est souvent assurée par un chiffrement SSL, mais cela peut aussi inclure d'autres canaux ou moyens de chiffrement. Il faut noter que le chiffrement ou le hashage cryptographique de l'identifiant de session doit être considéré séparément du chiffrement du transport, car c'est l'identifiant de session lui-même qui est protégé, pas les données qui peuvent le représenter.
  
  
−
If the Session ID could be presented by an attacker to the application to gain access, then it must be protected in transit to mitigate that risk. It should therefore be ensured that encryption is both the default and enforced for any request or response where the Session ID is passed, regardless of the mechanism used (e.g., a hidden form field). Simple checks such as replacing https:// with http:// during interaction with the application should be performed, together with modification of form posts to determine if adequate segregation between the secure and non-secure sites is implemented.<br>
+
Si l'identifiant de session peut être présenté à l'application par un attaquant pour y gagner accès, alors il doit être protégé pendant sa transmission pour réduire ce risque. Il faut donc s'assurer qu'un chifrement est activé par défaut et appliqué pour toutes les requêtes et réponses où l'identifiant de session est transmis, quelque soit le moyen utilisé (par exemple un champ caché dans un formulaire). De simples vérifications doivent être effectuées, comme remplacer https:// par http:// pendant les échanges avec l'application, ainsi que des modification de formulaires postés pour déterminer si une séparation adéquate est implémentée entre les sites sécurisés et non sécurisés.<br>
  
  
−
Note that if there is also an element to the site where the user is tracked with Session IDs but security is not present (e.g., noting which public documents a registered user downloads) it is essential that a different Session ID is used. The Session ID should therefore be monitored as the client switches from the secure to non-secure elements to ensure a different one is used.<br>
+
A noter que si l'utilisateur est tracé avec son identifiant de session dans une partie non sécurisée (par exemple, noter quels documents publics télécharge un utilisateur), il est essentiel qu'un identifiant différent soit utilisé. L'identifiant de session doit donc est surveillé quand le client accède à des éléments sécurisé ou non sécurisés, pour s'assurer qu'un identifiant différent est utilisé.<br>
  
  
−
'''Result Expected:'''<br>
+
'''Résultat attendu :'''<br>
−
Every time the authentication is successful, the user should expect to receive:
+
Lors de chaque authentification réussie, l'utilisateur doit s'attendre à recevoir :
−
* A different session token
+
* Un jeton de session différent
−
* A token sent via encrypted channel every time they make an HTTP Request
+
* Un jeton envoyé par un canal chiffré lors de chaque requête HTTP
  
  
−
'''Testing for Proxies & Caching vulnerabilities:''' <br>
+
'''Tester les vulnérabilités de proxies et de cache :''' <br>
−
Proxies must also be considered when reviewing application security. In many cases, clients will access the application through corporate, ISP, or other proxies or protocol aware gateways (e.g., Firewalls). The HTTP protocol provides directives to control the behavior of downstream proxies, and the correct implementation of these directives should also be assessed.
+
Les proxies doivent aussi être pris en compte lorsqu'on évalue une application. Dans beaucoup de cas, les clients accèdent aux application via des proxies ou des passerelles (firewalls, ...), fournis par des entreprises, des FAI, ou autres. Le protocole HTTP fournit des directives pour contrôler le comportement des proxies en aval. L'implémentation de ces directives doit aussi être étudiée.
  
  
−
In general, the Session ID should never be sent over unencrypted transport and should never be cached. The application should be examined to ensure that encrypted communications are both the default and enforced for any transfer of Session IDs. Furthermore, whenever the Session ID is passed, directives should be in place to prevent its caching by intermediate and even local caches.<br>
+
En général, l'identifiant de session ne doit jamais être transmis via un cana non chiffré et ne doit jamais être stocké en cache. L'application doit être véirifiée pour assurer que les transmission d'identifiant de session sont chiffrées par défaut et que ce chiffrage est effectif. De plus, chaque fois que l'identifiant de session est transmis, des directives doivent être en place pour empêcher son stockage en cache intermédiaire et même local.<br>
  
  
−
The application should also be configured to secure data in caches over both HTTP/1.0 and HTTP/1.1 – RFC 2616 discusses the appropriate controls with reference to HTTP. HTTP/1.1 provides a number of cache control mechanisms. Cache-Control: no-cache indicates that a proxy must not re-use any data. Whilst Cache-Control: Private appears to be a suitable directive, this still allows a non-shared proxy to cache data. In the case of web-cafes or other shared systems, this presents a clear risk. Even with single-user workstations the cached Session ID may be exposed through a compromise of the file-system or where network stores are used. HTTP/1.0 caches do not recognise the Cache-Control: no-cache directive.
+
L'application doit aussi être configurée pour sécuriser les données en cache via HTTP/1.0 et HTTP/1.1 - la RFC 2616 décrit les contrôles appropriés en rapport avec HTTP. HTTP/1.1 fournit un certain nombre de mécanismes de contrôle de cache. Cache-control: no-cache indique qu'un proxy ne doit réutiliser aucune donnée. Alors que Cache-control: Private semble être une directive convenable, elle permet à un proxy non partagé de stocker des données en cache. Dans le cas de web cafés ou autre systèmes partagés, cela représente clairement un risque. Même des stations de travail mono-utilisateurs peuvent voir leur données de session stockée en cache compromises via le système de fichier ou lorsqu'un partage réseau est utilisé. Les caches HTTP/1.0 ne reconnaissent pas la directive Cahce-control: no-cache.
  
  
−
'''Result Expected:'''<br>
+
'''Résultat attendu :'''<br>
−
The “Expires: 0” and Cache-Control: max-age=0 directives should be used to further ensure caches do not expose the data.
+
Les directives "Expires: 0" et Cache-control: max-age=0 devrait être utilisées pour renforcer la protection contre l'exposition de données par les caches.
−
Each request/response passing Session ID data should be examined to ensure appropriate cache directives are in use.
+
Chaque requête/réponse passant l'identifiant de session devrait être examinée pour assure que les directives appropriées sont utilisées.
 
<br>
 
<br>
  
  
−
'''Testing for GET & POST vulnerabilities:''' <br>
+
'''Tester les vulnérabilités GET & POST :''' <br>
−
In general, GET requests should not be used, as the Session ID may be exposed in Proxy or Firewall logs. They are also far more easily manipulated than other types of transport, although it should be noted that almost any mechanism can be manipulated by the client with the right tools. Furthermore, [[Cross-site Scripting (XSS)]] attacks are most easily exploited by sending a specially constructed link to the victim. This is far less likely if data is sent from the client as POSTs.
+
En général, les requêtes GET ne devraient pas être utilisées, car l'identifiant de session serait exposé dans les logs de proxies ou de firewall. Elles sont aussi bien plus facilement manipulable que les autres types de transport, bien qu'il faille souligner que presque tous les mécanismes peuvent être manipulés par le client avec les outils adéquats. De plus les attaques cross-site scripting ( [[Cross-site Scripting (XSS)]] ) sont plus faciles à exploiter en envoyant à la victime des liens spécialement construits. Cela est beaucoup moins évident sir les données sont envoyées par POST.
 
<br>
 
<br>
  
  
−
'''Result Expected:'''<br>
+
'''Résultat attendu :'''<br>
−
All server side code receiving data from POST requests should be tested to ensure it does not accept the data if sent as a GET.
+
Tout le code serveur recevant des données en requêtes POST doit être vérifié pour assurer qu'il n'accepte pas aussi les données en GET.
−
For example, consider the following POST request generated by a log in page.
+
Par exemple, la requête POST suivante, générée par une page d'authentification :
 
<pre>
 
<pre>
 
POST http://owaspapp.com/login.asp HTTP/1.1
 
POST http://owaspapp.com/login.asp HTTP/1.1
Line 78: Line 78:
  
  
−
If login.asp is badly implemented, it may be possible to log in using the following URL:
+
Si login.asp est mal implémentée, il peut être possible de s'authentifier avec l'URL suivante :
 
http://owaspapp.com/login.asp?Login=Username&password=Password&SessionID=12345678
 
http://owaspapp.com/login.asp?Login=Username&password=Password&SessionID=12345678
  
  
−
Potentially insecure server-side scripts may be identified by checking each POST in this way.<br>
+
Les scripts serveur potentiellement non sécurisés peuvent être identifiés en vérifiant chaque requête POST de cette manière.<br>
  
  
−
'''Testing for Transport vulnerabilities:''' <br>
+
'''Tester les vulnérabilités de transport :''' <br>
−
All interaction between the Client and Application should be tested at least against the following criteria.
+
Toutes les interaction entre le client et l'application doivent être testées au moins selon des critères suivants :
−
* How are Session IDs transferred? e.g., GET, POST, Form Field (including hidden fields)
+
* Comment les identifiants de session sont-ils transférés ? C'est-à-dire en GET, POST, champs de formulaires (y compris champs cachés)
−
* Are Session IDs always sent over encrypted transport by default?
+
* Est-ce que les identifiants de sesion sont toujours envoyés sur des canaux chiffrés par défaut ?
−
* Is it possible to manipulate the application to send Session IDs unencrypted? e.g., by changing HTTP to HTTPS?
+
* Est-il possible de manipuler l'application pour que les identifiants de session soient envoyés sur des canaux non chiffrés ? C'est-à-dire en remplaçant HTTPS par HTTP
−
* What cache-control directives are applied to requests/responses passing Session IDs?
+
* Quelles directives de contrôle de cache sont-elles emplyées sur les requêtes/réponses contenant des identifiants de session ?
−
* Are these directives always present? If not, where are the exceptions?
+
* Est-ce que ces directives sont toujours présentes ? Si non, quelles sont les exceptions ?
−
* Are GET requests incorporating the Session ID used?
+
* Est-ce que des requêtes GET contenant des identifiants de session sont utilisées ?
−
* If POST is used, can it be interchanged with GET?
+
* Si POST est utilisé, peut-on le remplacer par GET ?
  
  

Latest revision as of 21:43, 23 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

S'ils sont exposé, les jetons de session (Cookie, identifiant de session, champs caché) vont permettre à un attaquant d'usurper l'identité d'une victime et d'accèder frauduleusement à l'application. Il est important que ces jetons soit protégés contre l'espionnage, particulièrement pendant leur transit entre navigateur client et serveurs d'application.


Ici, nous nous concentrons sur la sécurité du transport appliquée au transfert d'identifiant de session sensible, plutôt que de données en général, ce qui peut être plus strict que les données en cache et les politiques de transport des données servies par le site.


En utilisant un proxy personnel, il est possible de vérifier pour chaque requête et réponse :

  • Le protocole utilisé (HTTP ou HTTPS)
  • Les entêtes HTTP
  • Le corps du message (POST, contenu de page)


Chaque fois que les données d'identifiant de session sont transmises entre le client et le serveur, le protocole, le cache, et les directives de confidentialité doivent être examinées. La securité de transport se réfère ici aux identifiants de session transmis en requêtes GET ou POST, au corps des messages, ou autres moyens dans des requêtes HTTP valides.


Comment tester

Tester les vulnérabilités sur le chiffrement et la réutilisation des jetons de session :
La protection contre l'espionnage est souvent assurée par un chiffrement SSL, mais cela peut aussi inclure d'autres canaux ou moyens de chiffrement. Il faut noter que le chiffrement ou le hashage cryptographique de l'identifiant de session doit être considéré séparément du chiffrement du transport, car c'est l'identifiant de session lui-même qui est protégé, pas les données qui peuvent le représenter.


Si l'identifiant de session peut être présenté à l'application par un attaquant pour y gagner accès, alors il doit être protégé pendant sa transmission pour réduire ce risque. Il faut donc s'assurer qu'un chifrement est activé par défaut et appliqué pour toutes les requêtes et réponses où l'identifiant de session est transmis, quelque soit le moyen utilisé (par exemple un champ caché dans un formulaire). De simples vérifications doivent être effectuées, comme remplacer https:// par http:// pendant les échanges avec l'application, ainsi que des modification de formulaires postés pour déterminer si une séparation adéquate est implémentée entre les sites sécurisés et non sécurisés.


A noter que si l'utilisateur est tracé avec son identifiant de session dans une partie non sécurisée (par exemple, noter quels documents publics télécharge un utilisateur), il est essentiel qu'un identifiant différent soit utilisé. L'identifiant de session doit donc est surveillé quand le client accède à des éléments sécurisé ou non sécurisés, pour s'assurer qu'un identifiant différent est utilisé.


Résultat attendu :
Lors de chaque authentification réussie, l'utilisateur doit s'attendre à recevoir :

  • Un jeton de session différent
  • Un jeton envoyé par un canal chiffré lors de chaque requête HTTP


Tester les vulnérabilités de proxies et de cache :
Les proxies doivent aussi être pris en compte lorsqu'on évalue une application. Dans beaucoup de cas, les clients accèdent aux application via des proxies ou des passerelles (firewalls, ...), fournis par des entreprises, des FAI, ou autres. Le protocole HTTP fournit des directives pour contrôler le comportement des proxies en aval. L'implémentation de ces directives doit aussi être étudiée.


En général, l'identifiant de session ne doit jamais être transmis via un cana non chiffré et ne doit jamais être stocké en cache. L'application doit être véirifiée pour assurer que les transmission d'identifiant de session sont chiffrées par défaut et que ce chiffrage est effectif. De plus, chaque fois que l'identifiant de session est transmis, des directives doivent être en place pour empêcher son stockage en cache intermédiaire et même local.


L'application doit aussi être configurée pour sécuriser les données en cache via HTTP/1.0 et HTTP/1.1 - la RFC 2616 décrit les contrôles appropriés en rapport avec HTTP. HTTP/1.1 fournit un certain nombre de mécanismes de contrôle de cache. Cache-control: no-cache indique qu'un proxy ne doit réutiliser aucune donnée. Alors que Cache-control: Private semble être une directive convenable, elle permet à un proxy non partagé de stocker des données en cache. Dans le cas de web cafés ou autre systèmes partagés, cela représente clairement un risque. Même des stations de travail mono-utilisateurs peuvent voir leur données de session stockée en cache compromises via le système de fichier ou lorsqu'un partage réseau est utilisé. Les caches HTTP/1.0 ne reconnaissent pas la directive Cahce-control: no-cache.


Résultat attendu :
Les directives "Expires: 0" et Cache-control: max-age=0 devrait être utilisées pour renforcer la protection contre l'exposition de données par les caches. Chaque requête/réponse passant l'identifiant de session devrait être examinée pour assure que les directives appropriées sont utilisées.


Tester les vulnérabilités GET & POST :
En général, les requêtes GET ne devraient pas être utilisées, car l'identifiant de session serait exposé dans les logs de proxies ou de firewall. Elles sont aussi bien plus facilement manipulable que les autres types de transport, bien qu'il faille souligner que presque tous les mécanismes peuvent être manipulés par le client avec les outils adéquats. De plus les attaques cross-site scripting ( Cross-site Scripting (XSS) ) sont plus faciles à exploiter en envoyant à la victime des liens spécialement construits. Cela est beaucoup moins évident sir les données sont envoyées par POST.


Résultat attendu :
Tout le code serveur recevant des données en requêtes POST doit être vérifié pour assurer qu'il n'accepte pas aussi les données en GET. Par exemple, la requête POST suivante, générée par une page d'authentification : 

POST http://owaspapp.com/login.asp HTTP/1.1
Host: owaspapp.com 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 Paros/3.0.2b 
Accept: */*
Accept-Language: en-us, en
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 
Keep-Alive: 300 
Cookie: ASPSESSIONIDABCDEFG=ASKLJDLKJRELKHJG 
Cache-Control: max-age=0 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 34

Login=Username&password=Password&SessionID=12345678


Si login.asp est mal implémentée, il peut être possible de s'authentifier avec l'URL suivante : http://owaspapp.com/login.asp?Login=Username&password=Password&SessionID=12345678


Les scripts serveur potentiellement non sécurisés peuvent être identifiés en vérifiant chaque requête POST de cette manière.


Tester les vulnérabilités de transport :
Toutes les interaction entre le client et l'application doivent être testées au moins selon des critères suivants :

  • Comment les identifiants de session sont-ils transférés ? C'est-à-dire en GET, POST, champs de formulaires (y compris champs cachés)
  • Est-ce que les identifiants de sesion sont toujours envoyés sur des canaux chiffrés par défaut ?
  • Est-il possible de manipuler l'application pour que les identifiants de session soient envoyés sur des canaux non chiffrés ? C'est-à-dire en remplaçant HTTPS par HTTP
  • Quelles directives de contrôle de cache sont-elles emplyées sur les requêtes/réponses contenant des identifiants de session ?
  • Est-ce que ces directives sont toujours présentes ? Si non, quelles sont les exceptions ?
  • Est-ce que des requêtes GET contenant des identifiants de session sont utilisées ?
  • Si POST est utilisé, peut-on le remplacer par GET ?


References

Whitepapers

Retrieved from "https://wiki.owasp.org/index.php?title=4.7.4_Tester_les_variables_de_session_exposées_(OTG-SESS-004)&oldid=185791"