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.1 Tester le système de management des sessions (OTG-SESS-001)"

From OWASP
Jump to: navigation, search
m
 
(One intermediate revision by the same user not shown)
Line 112: Line 112:
 
====Rétro-ingénierie de cookie====
 
====Rétro-ingénierie de cookie====
  
−
Now that the tester has enumerated the cookies and has a general idea of their use, it is time to have a deeper look at cookies that seem interesting. Which cookies is the tester interested in? A cookie, in order to provide a secure method of session management, must combine several characteristics, each of which is aimed at protecting the cookie from a different class of attacks.  
+
Maintenant que le testeur a fait l'inventaire des cookies et a une bonne idée générale de leur utilisation, il est temps d'investiguer plus en détail les cookies qui semblent intéressants. Quels sont les cookies qui vont intéresser le testeur ? Pour fournir une méthode sécurisée de gestion de session, un cookie doit avoir certaines caractéristiques, chacune d'elles étant destinée à protéger le cookie d'une classe d'attaques différente.
  
−
These characteristics are summarized below:
+
Ces caractéristiques sont résumées ci-dessous :
−
#Unpredictability: a cookie must contain some amount of hard-to-guess data. The harder it is to forge a valid cookie, the harder is to break into legitimate user's session. If an attacker can guess the cookie used in an active session of a legitimate user, they will be able to fully impersonate that user (session hijacking). In order to make a cookie unpredictable, random values and/or cryptography can be used.
+
#Imprévisibilité : un cookie doit contenir une certaine quantité de données difficilement prévisibles. Plus il est difficile de construire un cookie valide, plus il sera difficile de s'introduire dans la session d'un utilisateur légitime. Si des attaquants peuvent deviner le cookie utilisé dans une session active d'un utilisateur légitime, ils pourront usurper complètement l'utilisateur (détournement de session). Il est possible d'utiliser des valeurs aléatoires et/ou de la cryptographie pour rendre le cookie complètement imprévisible.
−
#Tamper resistance: a cookie must resist malicious attempts of modification. If the tester receives a cookie like  IsAdmin=No, it is trivial to modify it to get administrative rights, unless the application performs a double check (for instance, appending to the cookie an encrypted hash of its value)
+
#Résistance à la contrefaçon : un cookie doit résister aux tentatives de modification malicieuse. Si le testeur reçoit un cookie tel que "IsAdmin=No", il est trivial de le modifier pour obtenir des droits d'administration, sauf si l'application ajoute une seconde vérification (par exemple, ajouter au cookie un hash de la valeur du cookie).
−
#Expiration: a critical cookie must be valid only for an appropriate period of time and must be deleted from the disk or memory afterwards to avoid the risk of being replayed. This does not apply to cookies that store non-critical data that needs to be remembered across sessions (e.g., site look-and-feel).
+
#Péremption : un cookie critique ne doit être valide que pour une période de temps appropriée et doit être ensuite supprimé du disque et de la mémoire, afin d'éviter le risque de rejeu. Cela ne s'applique pas aux cookie qui contiennent des données non critiques qui doivent être conservées d'une session à l'autre (ex: options de visualisation).
−
#“Secure” flag: a cookie whose value is critical for the integrity of the session should have this flag enabled in order to allow its transmission only in an encrypted channel to deter eavesdropping.
+
#Option "Secure" : un cookie dont la valeur est critique pour l'application doit avoir cette option activée, afin de n'autoriser sa transmission que via un canal chiffré pour dissuader l'espionnage.
  
 +
Ici, l'approche est de collecter suffisamment d'exemples de cookies et de chercher les motifs récurrents dans leurs valeurs. Le sens exact de "suffisamment" peut varier de quelques uns, si la méthode de génération des cookies est facile à casser, à plusieurs milliers, si le testeur a besoin de procéder à une analyse mathématique (ex: khi-deux, attracteurs, voir plus loin pour plus d'information).
  
−
The approach here is to collect a sufficient number of instances of a cookie and start looking for patterns in their value. The exact meaning of “sufficient” can vary from a handful of samples, if the cookie generation method is very easy to break, to several thousands, if the tester needs to proceed with some mathematical analysis (e.g., chi-squares, attractors. See later for more information).
+
Une attention particulière doit être portée sur les processus de l'application, puisque l'état d'une session peut avoir un impact sur les cookies collectés. Un cookie collecté avant authentification peut être très différent d'un cookie obtenu après.
  
 +
Il faut également prendre en compte un autre aspect : le temps. Enregistrez toujours le moment exact où un cookie a été obtenu, quand il est possible que le temps joue un rôle dans la valeur du cookie (le serveur pourrait utiliser l'horodatage du cookie pour une partie de sa valeur). L'heure enregistrée peut être l'heure locale, ou celle du serveur indiquée dans la réponse HTTP (ou les deux).
  
−
It is important to pay particular attention to the workflow of the application, as the state of a session can have a heavy impact on collected cookies. A cookie collected before being authenticated can be very different from a cookie obtained after the authentication.
 
  
 +
Lors de l'analyse des données collectée, le testeur devrait essayer de détecter toutes les variables qui peuvent influencer la valeur du cookie, et essayer de les modifier une par une. Envoyer au serveur des versions modifiées du même cookie peut s'avérer très utile pour comprendre comment l'application lit et utilise le cookie.
  
−
Another aspect to keep into consideration is time. Always record the exact time when a cookie has been obtained, when there is the possibility that time plays a role in the value of the cookie (the server could use a time stamp as part of the cookie value). The time recorded could be the local time or the server's time stamp included in the HTTP response (or both).
 
  
 +
Exemples de vérification à faire lors de cette étape :
 +
* Quel jeu de caractères est utilisé dans le cookie ? Le cookie a-t-il une valeur numérique ? Alphanumérique ? Hexadécimale ? Que se passe-t-il si l'on injecte dans un cookie des caractères n'appartenant pas au jeu de caractères attendu ?
 +
* Est-ce que le cookie est composé de différentes parties contenant différentes informations ? Comment ces parties sont-elles séparées ? Avec quel séparateur ? Certaines parties pourraient avoir une plus grande variance, d'autres être constantes, d'autres encore avoir un nombre limité de valeurs possibles. Décomposer le cookie en ses composants de base est l'étape première et fondamentale.
  
−
When analyzing the collected values, the tester should try to figure out all variables that could have influenced the cookie value and try to vary them one at the time. Passing to the server modified versions of the same cookie can be very helpful in understanding how the application reads and processes the cookie.
 
  
−
 
+
Un exemple de cookie à structure évidente :
−
Examples of checks to be performed at this stage include:
 
−
* What character set is used in the cookie? Has the cookie a numeric value? alphanumeric? hexadecimal? What happens if the tester inserts in a cookie characters that do not belong to the expected charset?
 
−
* Is the cookie composed of different sub-parts carrying different pieces of information? How are the different parts separated? With which delimiters? Some parts of the cookie could have a higher variance, others might be constant, others could assume only a limited set of values. Breaking down the cookie to its base components is the first and fundamental step.
 
−
 
 
−
 
 
−
An example of an easy-to-spot structured cookie is the following:
 
  
 
<pre>
 
<pre>
Line 145: Line 142:
  
  
−
This example shows 5 different fields, carrying different types of data:
+
Cet exemple contient 5 champs, contenant différents types de données :
  
 
<pre>
 
<pre>
−
ID – hexadecimal
+
ID – hexadécimal
−
CR – small integer
+
CR – entier court
−
TM and LM – large integer. (And curiously they hold the same value. Worth to see what happens modifying one of them)
+
TM and LM – large integer. (Curieusement, ils contiennent la même valeur. Il peut être intéressant de voir ce qui se passe si l'on modifie l'une d'elle)
−
S – alphanumeric
+
S – alphanumerique
 
</pre>
 
</pre>
  
  
−
Even when no delimiters are used, having enough samples can help. As an example, let's look at the following series:
+
Même si aucun séparateur n'est présent, avoir suffisamment d'exemples peut aider. Par exemple, regardons la série suivante :
  
 
<pre>
 
<pre>
Line 162: Line 159:
  
  
−
====Brute Force Attacks====
+
====Attaque en force brute====
−
Brute force attacks inevitably lead on from questions relating to predictability and randomness. The variance within the Session IDs must be considered together with application session duration and timeouts. If the variation within the Session IDs is relatively small, and Session ID validity is long, the likelihood of a successful brute-force attack is much higher.
+
Les attaques en force brute sont innévitablement liées aux question de prévisibilité et d'entropie. La variance dans un identifiant de session doit être considérée en même temps que la durée de vie de la session et le temps d'inactivité maximal. Si la variance à l'intérieur de l'identifiant de session est relativement basse, et que la durée de vie de la session est longue, les chances de succès d'une attaque en force brute sont beaucoup plus grandes.
  
  
−
A long Session ID (or rather one with a great deal of variance) and a shorter validity period would make it far harder to succeed in a brute force attack.
+
Un identifiant de session long (ou plutôt comportant une variance élevée) et une durée de validité plus courte pourrait augmenter la difficulté d'une attaque en force brute.
−
* How long would a brute-force attack on all possible Session IDs take?
+
* Combien de temps prendrait une attaque en force brute sur toutes les valeurs possibles d'un identifiant de session ?
−
* Is the Session ID space large enough to prevent brute forcing? For example, is the length of the key sufficient when compared to the valid life-span?
+
* Est-ce que le nombre de valeurs possibles de l'identifiant de session est suffisamment grand pour empêcher une attaque en force brute ? Par exemple, est-ce que la longueur de la clef est suffisante, comparée à la durée de validité de la session ?
−
* Do delays between connection attempts with different Session IDs mitigate the risk of this attack?
+
* Est-ce que les délais imposés entre les tentatives de connexion avec différent identifiants de session permettent de limiter les risques d'une attaque en force brute ?
  
  
−
=== Gray Box testing and example ===  
+
=== Exemple et test en boite grise ===  
−
If the tester has access to the session management schema implementation, they can check for the following:
+
Si le testeur a connaissance de l'implémentation du système de management de session, il peut vérifier :
−
* Random Session Token
+
* Jeton de session aléatoire
−
The Session ID or Cookie issued to the client should not be easily predictable (don't use linear algorithms based on predictable variables such as the  client IP address). The use of cryptographic algorithms with key length of 256 bits is encouraged (like AES).
+
L'identifiant de session envoyé au client ne devrait pas être facilement prévisible (n'utilisez pas d'algorithmes linéaires basés sur des variables prévisibles comme l'adresse IP du client). Utilisez de préférence des algorithmes cryptographiques avec des clefs de 256 bits (comme AES).
−
* Token length
+
* Taille des jetons
−
Session ID will be at least 50 characters length.
+
Un identifiant de session doit contenir au moins 50 caractères.
−
* Session Time-out
+
* Limite du temps d'inactivité
−
Session token should have a defined time-out (it depends on the criticality of the application managed data)
+
Les jetons de session devraient avoir une limite de temps d'inactivité défini (cela dépend de la criticité des données manipulées par l'application).
−
* Cookie configuration:
+
* Configuration des cookies:
−
** non-persistent: only RAM memory
+
** non-persistent: seulement en RAM
−
** secure (set only on HTTPS channel):  Set Cookie: cookie=data; path=/; domain=.aaa.it; secure
+
** secure (limité à HTTPS):  Set Cookie: cookie=data; path=/; domain=.aaa.it; secure
−
** [[HTTPOnly]] (not readable by a script):  Set Cookie: cookie=data; path=/; domain=.aaa.it; [[HTTPOnly]]
+
** [[HTTPOnly]] (non lisible par un script):  Set Cookie: cookie=data; path=/; domain=.aaa.it; [[HTTPOnly]]
  
  
−
More information here: [[Testing_for_cookies_attributes  (OWASP-SM-002)|Testing for cookies attributes]]
+
Pour plus d'information : [[Testing_for_cookies_attributes  (OWASP-SM-002)|Testing for cookies attributes]]
  
  
  
−
==Tools==
+
==Outils==
−
* OWASP Zed Attack Proxy Project (ZAP) - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project - features a session token analysis mechanism.
+
* OWASP Zed Attack Proxy Project (ZAP) - https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project - inclut un mécanisme d'analyse de jetons de session
 
* Burp Sequencer - http://www.portswigger.net/suite/sequencer.html
 
* Burp Sequencer - http://www.portswigger.net/suite/sequencer.html
 
* Foundstone CookieDigger - http://www.mcafee.com/us/downloads/free-tools/cookiedigger.aspx
 
* Foundstone CookieDigger - http://www.mcafee.com/us/downloads/free-tools/cookiedigger.aspx
Line 214: Line 211:
  
  
−
==Related Security Activities==
+
==Autres activités de sécurité==
  
−
===Description of Session Management Vulnerabilities===
+
===Description des vulnérabilités de management de session===
  
−
See the OWASP articles on [[:Category:Session Management Vulnerability|Session Management Vulnerabilities]].
+
Cf. les articles de l'OWASP : [[:Category:Session Management Vulnerability|Session Management Vulnerabilities]].
  
  
−
===Description of Session Management Countermeasures===
+
===Description des contre-mesures en management de session===
  
−
See the OWASP articles on [[:Category:Session Management|Session Management Countermeasures]].
+
Cf. les articles de l'OWASP : [[:Category:Session Management|Session Management Countermeasures]].
  
  
−
===How to Avoid Session Management Vulnerabilities===
+
===Comment éviter les vulnérabilités de management de session===
  
−
See the [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Session Management|Avoid Session Management]] Vulnerabilities.
+
Voir : [[:Category:OWASP Guide Project|OWASP Development Guide]] article on how to [[Session Management|Avoid Session Management]] Vulnerabilities.
  
  
−
===How to Review Code for Session Management| Vulnerabilities===
+
===Revue de code pour le management de session===
  
−
See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Codereview-Session-Management|Review Code for Session Management]] Vulnerabilities.
+
Voir : [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Codereview-Session-Management|Review Code for Session Management]] Vulnerabilities.

Latest revision as of 19:46, 20 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

Pour éviter que l'utilisateur ait à se ré-authentifier sur chaque page d'un site web ou d'un service, les applications web implémentent des mécanismes pour stocker et valider les crédentiels, et ce, pour un temps donné. Ces mécanismes sont connus sous le nom de management ou gestion de sessions. Bien qu'ils soient important pour améliorer l'expérience utilisateur, ils peuvent être exploités par un testeur d'intrusion pour accéder à un compte utilisateur, sans avoir besoin de donner les crédentiels nécessaires.

Dans ce test, le testeur va vérifier que les cookies et autres jetons de session sont créés de manière sûre et aléatoire. Un attaquant qui est capable de prédire et de fabriquer un cookie faible peut aisément détourner les sessions des utilisateurs légitimes.

Les cookies, décrits en détail dans la RFC 2965, sont le plus souvent utilisés pour implémenter la gestion de sessions. En bref, lorsqu'un utilisateur accède à une application qui a besoin de gérer des sessions et l'identité des utilisateurs, le serveur génère un (ou plusieurs) cookie et l'envoit au client. Le client renverra ce (ou ces) cookie au serveur à chaque connexion jusqu'à ce que le cookie atteigne sa durée de vie ou soit détruit. Les données stockées dans le cookie indiqueront beacuou d'informations au serveur : qui est l'utilisateur, quelles actions a-t-il faites jusqu'ici, quelles sont ses préférences, etc. Ainsi un protocole comme HTTP n'est plus sans état.

Un panier de courses en ligne est un parfait exemple de cela. Tout au long de la session d'un utilisateur, l'application garde la trace de son identité, de son profil, des produits qu'il a mis dans son panier, des quantités, des prix, des remises, etc. Les cookies sont un moyen efficace d'échanger des informations entre client et serveur (d'autres méthodes existent : paramètres d'URL ou champs cachés).

Du fait de l'importance des données qu'ils contiennent, les cookies sont vitaux pour la sécurité générale d'une application. En falsifiant des cookies, on peut détourner les sessions d'utilisateurs légitimes, escalader en privilège dans une session existante, et de manière générale influencer le comportement de l'application de manière frauduleuse.

Dans ce cadre, le testeur va vérifier si les cookies envoyés aux clients peuvent résister à une large gamme d'attaques destinées à interférer avec les sessions des utilisateurs légitimes et avec l'application elle-même. Le principal but est de générer un cookie qui sera considéré comme valide par l'application et qui octroira des accès non autorisés (détournement de session, escalade de privilèges, ...).

Généralement les principales étapes du schéma d'attaque sont les suivantes :

  • collecte de cookies : collecte d'un échantillon de cookies suffisamment important ;
  • rétro-ingénierie de cookies : analyse de l'algorythme de génération des cookies ;
  • manipulation de cookies : construction d'un cookie valide pour mener l'attaque à bien. Ce dernier point peut demander un grand nombre d'essais, selon la façon dont sont générés les cookies (cookie brute-force attack).

Un autre mode d'attaque est possible : le débordement de cookie. C'est une attaque de nature différente, puisqu'ici on ne cherche pas à générer un cookie valide. Au lieu de cela, le but est de déborder une zone mémoire, et ainsi de déclencher un comportement non-prévu de l'application. Ainsi, il peut être possible d'injecter (et d'exécuter à distance) du code malicieux.

Comment tester

Exemples et tests en black box

Chaque interaction entre client et serveur doit être testée selon au moins un des critères suivants :

  • Est-ce que tous les cookies ont l'option Secure ?
  • Est-ce que le cookie peut être transporté en clair (non chiffré) ?
  • Est-ce que l'on peut forcer le transport non chiffré du cookie ?
  • Si oui, comment l'application assure-t-elle la sécurité ?
  • Est-ce que les cookies sont persistents ?
  • Quelle est la durée de persistence des cookies ? Est-elle raisonnable ?
  • Est-ce que les cookies prévus pour être transient sont définis comme tel ?
  • Quels paramètres Cache-Control sont utilisés pour protéger les cookies en HTTP/1.1 ?
  • Quels paramètres Cache-Control sont utilisés pour protéger les cookies en HTTP/1.0 ?


Collecte de cookies

La première étape pour manipuler un cookie est de comprendre comment l'application le génère et le gère. Pour cela, les testeurs doivent essayer de répondre aux questions suivantes :

  • Combien de cookies sont utilisés par l'application ?

Naviguez sur l'application. Notez quand les cookies sont créés. Faites une liste des cookies reçus, incluant la page qui les génère (directive set-cookie), le domaine pour lequel ils sont valides, et leurs caractéristiques.

  • Quelle partie de l'application génère et/ou modifie le cookie ?

En navigant sur l'application, trouvez quels cookies restent constants, et lesquels sont modifiés. Quel événement modifie un cookie ?

  • Quelles parties de l'application nécessite ce cookie pour être accessible et fonctionner ?

Trouvez quelles parties de l'application nécessite un cookie. Accédez à une page, et essayez encore sans le cookie, ou avec une version modifiée de celui-ci. Essayez de cartographier quels cookies sont utilisés où.

Une feuille de calcul listant la correspondance de chaque cookie avec les parties de l'application les utilisant, et les informations concernées peut être un résultat de grande valeur, lors de cette étape.


Analyse de session

Du point de vue de la sécurité, les jetons de session (cookie, SessionID, champs cachés) eux-mêmes doivent être examinés pour s'assurer de leur qualité. Ils doivent être testés selon des critères comme l'entropie, l'unicité, la résistance à l'analyse statistique et cryptographique, et les fuites d'informations.

  • Structure des jetons & fuite d'information

La première étape est d'examiner la structure et le contenu d'un identifiant de session fourni par l'application. Une erreur classique est d'inclure des données spécifiques dans le jeton, au lieu de produire une valeur générique et de référencer les données significatives côté serveur.

Si l'identifiant de session est en clair, la structure et les données pertinentes sont immédiatement accessibles : 

192.168.100.1:owaspuser:password:15:58

Si une partie ou le jeton entier apparaît comme encodé ou hashé, il faut le comparer avec des techniques évidentes d'obfuscation. Par exemple la chaîne "192.168.100.1:owaspuser:password:15:58" convertie en Hexa, Base64, et MD5 : 

Hex	3139322E3136382E3130302E313A6F77617370757365723A70617373776F72643A31353A3538
Base64	MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6cGFzc3dvcmQ6MTU6NTg=
MD5	01c2fc4f0a817afd8366689bd29dd40a

Après avoir identifié le type d'obfuscation, il peut être possible de décoder la donnée originale, bien que dans la plupart des cas ce soit peut probable. Par contre il peut être utile de déterminer l'encodage à partir du format du message. En outre, si le format et la méthode d'obfuscation peuvent être déterminés, une attaque automatisée en brute force peut être mise au point.


Des jetons hybrides peuvent contenir différentes informations, comme l'adresse IP, l'identifiant utilisateur, ainsi qu'une portion codée : 

owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412


Après analyse d'un premier jeton de session, un échantillon représentatif doit être examiné. Une simple analyse des jetons doit révéler immédiatement tout schema évident. Par exemple un jeton de 32 bits peut contenir 16 bits de données statiques et 16 bits de données variables. Cela peut indiquer que les 16 premiers bits représentent un attribut fixe lié à l'utilisateur, par exemple son identifiant ou son adresse IP. Si le second groupe de 16 bits est incrémenté d'une manière régulière, cela peut indiquer que c'est une séquence ou une valeur liée au moment de la génération du jeton.


Si des éléments statiques ont été identifiés dans le jeton, d'autres échantillons doivent être collectés, en faisant varier une valeur à chaque fois. Par exemple, des essais de connexion avec un compte différent, ou depuis une adresse IP différente, peuvent indiquer une variance dans des parties du jeton auparavant statiques.

Les questions suivantes devraient être adressées lors du test de structure d'identifiant de session unique ou multiple :

  • Quelles parties de l'identifiant de session sont statiques ?
  • Quelles information confidentielles sont stockées en clair dans l'identifiant de session ? Ex: identifiant utilisateur/UID, adresse IP.
  • Quelles informations confidentielles sont facilement décodables ?
  • Quelles informations peuvent être déduites de la structure de l'identifiant de session ?
  • Quelle portions de l'identifiant de session sont statiques dans les mêmes conditions de connexion ?
  • Quels schemas évidents sont présents dans l'identifiant de session, ou dans des parties de ce dernier ?


prévisibilité et entropie de l'identifiant de session

Une analyse de la partie variable (si elle existe) de l'identifiant de session est nécessaire pour démontrer l'existence de valeurs reconnaissables et prévisible. Ces analyses peuvent être faites manuellement avec des outils spécifiques, ou statistiques/cryptanalitiques, pour déduire tout motif présent dans l'identifiant de session. Ces vérification manuelles doivent comprendre des comparaisons d'identifiant de session générés dans les mêmes conditions de connexion (même identifiant, mot de passe, adresse IP, ...).

Le temps est aussi un facteur qui doit être contrôlé. Il faut faire un grand nombre de connexions dans la même fenêtre temporelle et garder cette variable constante. Même une répartition sur 50ms ou moins peut s'avérer trop large, et empêcher l'échantillonage de montrer des composants basés sur le temps.

Les éléments variables doivent être analysés sur la durée pour déterminer s'ils sont de nature incrémentale. S'ils sont incrémentaux, les motifs liés au temps absolu ou relatif doivent être examinés. Beaucoup de systèmes utilisent le temps pour l'initialisation de générateurs pseudo-aléatoires. Quand les motifs semblent aléatoires, des hash à sens unique ou d'autres variations d'environnement doivent être considérés comme possible. Généralement, le résultat d'un hash cryptographique est un nombre décimal ou hexadécimal qui devrait être identifiable.

Lors de l'analyse d'identifiant de session, les séquences, motifs ou cycles, éléments statiques et dépendances client doivent tous être vu comme influençant la structure et le fonctionnement de l'application.

  • Est-ce que les identifiants de session sont formellement aléatoires par nature ? Est-ce que les valeurs générées peuvent être reproduites ?
  • Est-ce que les mêmes conditions d'entrée produisent le même identifiant sur un test ultérieur ?
  • Peut-on prouver que les identifiants de session sont résistants à l'analyse statistique et cryptographique ?
  • Quels éléments des identifiants de session sont liés au temps ?
  • Quelles parties de l'identifiant de session sont prévisibles ?
  • Est-ce que le prochain identifiant de session peut être déduit à partir de la connaissance complète de l'algorithme de génération et des identifiants précédants ?


Rétro-ingénierie de cookie

Maintenant que le testeur a fait l'inventaire des cookies et a une bonne idée générale de leur utilisation, il est temps d'investiguer plus en détail les cookies qui semblent intéressants. Quels sont les cookies qui vont intéresser le testeur ? Pour fournir une méthode sécurisée de gestion de session, un cookie doit avoir certaines caractéristiques, chacune d'elles étant destinée à protéger le cookie d'une classe d'attaques différente.

Ces caractéristiques sont résumées ci-dessous :

  1. Imprévisibilité : un cookie doit contenir une certaine quantité de données difficilement prévisibles. Plus il est difficile de construire un cookie valide, plus il sera difficile de s'introduire dans la session d'un utilisateur légitime. Si des attaquants peuvent deviner le cookie utilisé dans une session active d'un utilisateur légitime, ils pourront usurper complètement l'utilisateur (détournement de session). Il est possible d'utiliser des valeurs aléatoires et/ou de la cryptographie pour rendre le cookie complètement imprévisible.
  2. Résistance à la contrefaçon : un cookie doit résister aux tentatives de modification malicieuse. Si le testeur reçoit un cookie tel que "IsAdmin=No", il est trivial de le modifier pour obtenir des droits d'administration, sauf si l'application ajoute une seconde vérification (par exemple, ajouter au cookie un hash de la valeur du cookie).
  3. Péremption : un cookie critique ne doit être valide que pour une période de temps appropriée et doit être ensuite supprimé du disque et de la mémoire, afin d'éviter le risque de rejeu. Cela ne s'applique pas aux cookie qui contiennent des données non critiques qui doivent être conservées d'une session à l'autre (ex: options de visualisation).
  4. Option "Secure" : un cookie dont la valeur est critique pour l'application doit avoir cette option activée, afin de n'autoriser sa transmission que via un canal chiffré pour dissuader l'espionnage.

Ici, l'approche est de collecter suffisamment d'exemples de cookies et de chercher les motifs récurrents dans leurs valeurs. Le sens exact de "suffisamment" peut varier de quelques uns, si la méthode de génération des cookies est facile à casser, à plusieurs milliers, si le testeur a besoin de procéder à une analyse mathématique (ex: khi-deux, attracteurs, voir plus loin pour plus d'information).

Une attention particulière doit être portée sur les processus de l'application, puisque l'état d'une session peut avoir un impact sur les cookies collectés. Un cookie collecté avant authentification peut être très différent d'un cookie obtenu après.

Il faut également prendre en compte un autre aspect : le temps. Enregistrez toujours le moment exact où un cookie a été obtenu, quand il est possible que le temps joue un rôle dans la valeur du cookie (le serveur pourrait utiliser l'horodatage du cookie pour une partie de sa valeur). L'heure enregistrée peut être l'heure locale, ou celle du serveur indiquée dans la réponse HTTP (ou les deux).


Lors de l'analyse des données collectée, le testeur devrait essayer de détecter toutes les variables qui peuvent influencer la valeur du cookie, et essayer de les modifier une par une. Envoyer au serveur des versions modifiées du même cookie peut s'avérer très utile pour comprendre comment l'application lit et utilise le cookie.


Exemples de vérification à faire lors de cette étape :

  • Quel jeu de caractères est utilisé dans le cookie ? Le cookie a-t-il une valeur numérique ? Alphanumérique ? Hexadécimale ? Que se passe-t-il si l'on injecte dans un cookie des caractères n'appartenant pas au jeu de caractères attendu ?
  • Est-ce que le cookie est composé de différentes parties contenant différentes informations ? Comment ces parties sont-elles séparées ? Avec quel séparateur ? Certaines parties pourraient avoir une plus grande variance, d'autres être constantes, d'autres encore avoir un nombre limité de valeurs possibles. Décomposer le cookie en ses composants de base est l'étape première et fondamentale.


Un exemple de cookie à structure évidente : 

ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=1120514521:S=j3am5KzC4v01ba3q


Cet exemple contient 5 champs, contenant différents types de données : 

ID – hexadécimal
CR – entier court
TM and LM – large integer. (Curieusement, ils contiennent la même valeur. Il peut être intéressant de voir ce qui se passe si l'on modifie l'une d'elle)
S – alphanumerique


Même si aucun séparateur n'est présent, avoir suffisamment d'exemples peut aider. Par exemple, regardons la série suivante : 

0123456789abcdef


Attaque en force brute

Les attaques en force brute sont innévitablement liées aux question de prévisibilité et d'entropie. La variance dans un identifiant de session doit être considérée en même temps que la durée de vie de la session et le temps d'inactivité maximal. Si la variance à l'intérieur de l'identifiant de session est relativement basse, et que la durée de vie de la session est longue, les chances de succès d'une attaque en force brute sont beaucoup plus grandes.


Un identifiant de session long (ou plutôt comportant une variance élevée) et une durée de validité plus courte pourrait augmenter la difficulté d'une attaque en force brute.

  • Combien de temps prendrait une attaque en force brute sur toutes les valeurs possibles d'un identifiant de session ?
  • Est-ce que le nombre de valeurs possibles de l'identifiant de session est suffisamment grand pour empêcher une attaque en force brute ? Par exemple, est-ce que la longueur de la clef est suffisante, comparée à la durée de validité de la session ?
  • Est-ce que les délais imposés entre les tentatives de connexion avec différent identifiants de session permettent de limiter les risques d'une attaque en force brute ?


Exemple et test en boite grise

Si le testeur a connaissance de l'implémentation du système de management de session, il peut vérifier :

  • Jeton de session aléatoire

L'identifiant de session envoyé au client ne devrait pas être facilement prévisible (n'utilisez pas d'algorithmes linéaires basés sur des variables prévisibles comme l'adresse IP du client). Utilisez de préférence des algorithmes cryptographiques avec des clefs de 256 bits (comme AES).

  • Taille des jetons

Un identifiant de session doit contenir au moins 50 caractères.

  • Limite du temps d'inactivité

Les jetons de session devraient avoir une limite de temps d'inactivité défini (cela dépend de la criticité des données manipulées par l'application).

  • Configuration des cookies:
    • non-persistent: seulement en RAM
    • secure (limité à HTTPS): Set Cookie: cookie=data; path=/; domain=.aaa.it; secure
    • HTTPOnly (non lisible par un script): Set Cookie: cookie=data; path=/; domain=.aaa.it; HTTPOnly


Pour plus d'information : Testing for cookies attributes


Outils

References

Whitepapers


Videos


Autres activités de sécurité

Description des vulnérabilités de management de session

Cf. les articles de l'OWASP : Session Management Vulnerabilities.


Description des contre-mesures en management de session

Cf. les articles de l'OWASP : Session Management Countermeasures.


Comment éviter les vulnérabilités de management de session

Voir : OWASP Development Guide article on how to Avoid Session Management Vulnerabilities.


Revue de code pour le management de session

Voir : OWASP Code Review Guide article on how to Review Code for Session Management Vulnerabilities.

Retrieved from "https://wiki.owasp.org/index.php?title=4.7.1_Tester_le_système_de_management_des_sessions_(OTG-SESS-001)&oldid=185662"