4.7.8 Tester la confusion de session (OTG-SESS-008)

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

La surcharge de variable de session (aussi connue sous le nom de confusion de session) est une vulnérabilité au niveau application qui permet à un attaquant de commettre une variété d'actions malicieuses, entre autres, telles que :

• Contourner des mécanismes d'authentification efficaces, et usurper l'identification d'utilisateurs légitimes.
• Elever les privilèges du compte d'un utilisateur malicieux, dans un environnement considéré par ailleurs comme sûr.
• Eviter les phases de qualification dans des processus multi-phase, même si le processus inclut toutes les restrictions usuelles recommandées au niveau code.
• Manipuler des caleurs côté serveur par des méthodes indirectes qui ne peuvent être ni prévues ni détectées.
• Exécuter des attaques standard à des endroits précédemment inaccessibles, ou même considérés comme sécurisés.

Cette vulnérabilité se manifeste quand une application utilise la même variable de session pour plus d'un usage. Un attaquant peut potentiellement accéder à des pages dans un ordre imprévu par les développeurs, entraînant une variable de session, initialisée dans un contexte, à être utilisée dans un autre.

Par exemple, un attaquant peut utiliser la surchage de variable de session pour contourner les mécanismes forçant l'authentification d'applications qui imposent l'authentification en validant l'existence de variables de session contenant des valeurs liées à l'identité, et qui sont normalement stockées dans la session après une authentification réussie. Cela signifie qu'un attaquant accède d'abord à une partie de l'application qui initialise le contexte de session, puis accède une partie privilégiée qui examine ce contexte.

Par exemple, un vecteur d'attaque de contournement d'authentification peut être exécuté en accédant à un point d'entrée public (par exemple, la page de récupération de mot de passe) qui génère des sessions avec une variable de session identique basée sur des valeurs fixes ou sur une entrée utilisateur.

Comment tester

Test en boite noire

Cette vulnérabilité peut être détectée et exploitée en énumérant toutes les variables de session utilisées par l'application et, dans quel contexte, elles sont valides. En particulier, c'est possible en accédant à une séquence de points d'entrée et en examinant les points de sortie. Dans un test en boite noire, cette procédure est difficile et requiert un peu de chance car chaque séquence peut aboutir à un résultat différent.

Exemples

Un exemple très simple pourrait être la réinitialisation de mot de passe qui, en point d'entrée, peut demander à l'utilisateur de fournir une information l'identifiant comme son nom d'utilisateur ou son adresse de messagerie. Cette page peut alors générer la session avec ces valeurs d'identification, reçues directement du client, ou être obtenues par des requêtes ou des calculs basés sur l'entrée reçue. A ce stade, il peut y avoir certaines pages dans l'application qui afficheront des données privées basées sur cet objet de session. De la même manière, l'attaquant pourrait contourner le processus d'authentification.

Test en boite grise

Le moyen le plus efficace pour détecter ces vulnérabilités est de faire une revue de code.

References

Whitepapers

• Session Puzzles: http://puzzlemall.googlecode.com/files/Session%20Puzzles%20-%20Indirect%20Application%20Attack%20Vectors%20-%20May%202011%20-%20Whitepaper.pdf
• Session Puzzling and Session Race Conditions: http://sectooladdict.blogspot.com/2011/09/session-puzzling-and-session-race.html

Contre-mesures

Une variable de session ne devrait être utilisée que pour un seul usage cohérent.