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.8 Tester la confusion de session (OTG-SESS-008)"
(Created page with "{{Template:OWASP Testing Guide v4}} == Sommaire == La surcharge de variable de session (aussi connue sous le nom de confusion de session) est une vulnérabilité au niveau...") |
(Corrections) |
||
| Line 4: | Line 4: | ||
== Sommaire == | == 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 : | + | 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. | * 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. | * Elever les privilèges du compte d'un utilisateur malicieux, dans un environnement considéré par ailleurs comme sûr. | ||
| − | * Eviter | + | * 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. | * 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 | + | * 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 | + | 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 | + | 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 | + | 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== | ==Comment tester== | ||
=== Test en boite noire === | === 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 | + | 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==== | ====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 | + | 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 === | === Test en boite grise === | ||
| − | Le moyen le plus efficace pour détecter ces | + | Le moyen le plus efficace pour détecter ces vulnérabilités est de faire une revue de code. |
| Line 44: | Line 44: | ||
==Contre-mesures== | ==Contre-mesures== | ||
| − | + | Une variable de session ne devrait être utilisée que pour un seul usage cohérent. | |
Latest revision as of 15:24, 5 July 2015
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.
