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

4.7.1 Tester le système de management des sessions (OTG-SESS-001)

From OWASP
Revision as of 16:07, 20 November 2014 by Jcpraud (talk | contribs)

Jump to: navigation, search
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

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.

These characteristics are summarized below:

  1. 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.
  2. 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)
  3. 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).
  4. “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.


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).


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.


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).


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.


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:

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


This example shows 5 different fields, carrying different types of data:

ID – hexadecimal
CR – small integer
TM and LM – large integer. (And curiously they hold the same value. Worth to see what happens modifying one of them)
S – alphanumeric


Even when no delimiters are used, having enough samples can help. As an example, let's look at the following series:

0123456789abcdef


Brute Force Attacks

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.


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.

  • How long would a brute-force attack on all possible Session IDs take?
  • 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?
  • Do delays between connection attempts with different Session IDs mitigate the risk of this attack?


Gray Box testing and example

If the tester has access to the session management schema implementation, they can check for the following:

  • Random Session Token

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).

  • Token length

Session ID will be at least 50 characters length.

  • Session Time-out

Session token should have a defined time-out (it depends on the criticality of the application managed data)

  • Cookie configuration:
    • non-persistent: only RAM memory
    • secure (set only on HTTPS channel): Set Cookie: cookie=data; path=/; domain=.aaa.it; secure
    • HTTPOnly (not readable by a script): Set Cookie: cookie=data; path=/; domain=.aaa.it; HTTPOnly


More information here: Testing for cookies attributes


Tools

References

Whitepapers


Videos


Related Security Activities

Description of Session Management Vulnerabilities

See the OWASP articles on Session Management Vulnerabilities.


Description of Session Management Countermeasures

See the OWASP articles on Session Management Countermeasures.


How to Avoid Session Management Vulnerabilities

See the OWASP Development Guide article on how to Avoid Session Management Vulnerabilities.


How to Review Code for Session Management| Vulnerabilities

See the OWASP Code Review Guide article on how to Review Code for Session Management Vulnerabilities.