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, 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 des phases de qualification dans des processus multi-phase, même si le processus inclut toutes les restrictions 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 traditionnelles localisées à des endroits précédemment intouchables, ou même considérés comme sécurisés.

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

Par exemple, un attaquant peut utiliser une variable de session surchargée pour contourner les mécanismes forçant l'authentification d'applications qui imposent l'authentification en validant l'existance 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 peuple la session avec une variable identique, basée sur des valeurs fixes ou 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 exéminant les points de sortie. Dans un test en boite noire, cette procédure est difficile et requiert un peu de chance puisque 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 email. Cette page peut alors peupler la session avec des valeurs identifiantes, qui sont reçues directement du côté client, ou obtenues par des requêtes ou calculs basés sur l'entrée reçue. A ce moment, 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é 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

Le variable de session ne devraient être utilisées que pour un seul but.