4.8.10 Tester les injections XPath (OTG-INPVAL-010)

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

XPath est un langage conçu et développé à l'origine pour accéder à des parties d'un document XML. Lors des tests d'injection XPath, on vérifie s'il est possible d'injecter de la syntaxe XPath dans une requête qui sera interprêtée par l'application, permettant l'attaquant d'exécuter des requêtes XPath contrôlées par l'utilisateur. Exploitée avec succès, cette vulnérabilité peut permettre à l'attaquant de contourner les mécanismes d'authentification ou d'accéder à des informations sans autorisation.

Les applications utilise largement des bases de données pour stocker et consulter les données dont elles ont besoins pour leurs opérations. Historiquement, les bases de données relationnelles étaient la technologie la plus commune, mais ces dernières années, on observe une popularité croissante des bases de données utilisant le langage XML. De la même manière qu'on accède aux bases relationnelles avec le langage SQL, on accède aux bases XML en utilisant XPath comme langage de requête standard.

D'un point de vue conceptuel, XPath est très similaire à SQL dans son objectif et ses applications, les attaques par injection XPath suivent donc la même logique que les attaques par injection SQL. Par certains aspects, XPath est même plus puissant que SQL, cat toute sa puissance est déjà présente dans ses spécifications, alors qu'une large part des techniques utilisées pour les attaques par injection SQL dépendent des caractéristiques du dialecte SQL utilisé par la base cible. Cela signifie que les attaques par injection Xpath sont beaucoup plus adaptable et omniprésentes. Un autre avantage des attaques par injection XPath est que, contrairement à SQL, aucune ACL n'est vérifiée, puisque notre requête peut accéder à l'ensemble du document XML.

Comment tester

Le schéma des attaques XPath a été publié initialement par Amit Klein [1] et est très similaire aux injections SQL usuelles. Pour avoir un premier aperçu du problème, imaginons une page de connexion gérant l'authentification à une application dans laquelle l'utilisateur doit entrer son identifiant et son mot de passe. Considérons que notre base de données est représentée par le fichier XML suivant :

<?xml version="1.0" encoding="ISO-8859-1"?> 
<users> 
<user> 
<username>gandalf</username> 
<password>!c3</password> 
<account>admin</account> 
</user> 
<user> 
<username>Stefan0</username> 
<password>w1s3c</password> 
<account>guest</account> 
</user> 
<user> 
<username>tony</username> 
<password>Un6R34kb!e</password> 
<account>guest</account> 
</user> 
</users> 

La requête XPath suivante renvoie le compte dont l'identifiant est "gandalf" et le mot de passe est "!c3" :

string(//user[username/text()='gandalf' and password/text()='!c3']/account/text()) 

Si l'applciation ne filtre pas correctement les entrées utilisateur, le testeur pourra injecccccter du code XPath et interférer avec le résultat de la requête. Par exemple, en entrant les valeurs suivantes :

Username: ' or '1' = '1 
Password: ' or '1' = '1 

Cela ressemble à quelque chose de connu, n'est-ce pas ? Avec ces paramètres, la requête devient :

string(//user[username/text()='' or '1' = '1' and password/text()='' or '1' = '1']/account/text()) 

Comme dans une attaque par injection SQL, nous avons créé une requête qui renvoie toujours vrai, ce qui signifie que l'application va authentifier l'utilisateur même si aucun identifiant ou mot de passe n'a été fourni. Comme dans le cas des injections SQL, la première étape d'une injection XPath est d'insérer une simple quote (') dans le champ à tester, causant une erreur de syntaxe dans la requête, et de vérifier si l'application retourne un message d'erreur.

Si l'on a pas connaissance des détails des données XML et si l'application de fournie pas de messages d'erreurs utiles pour nous aider à découvrir sa logique interne, il est possible de procéder à des attaques par injection XPath en aveugle (Blind XPath Injection), dont le but est de reconstituer la structure de données complète. Cette technique est similaire aux injection SQL inférentielles, puisque l'approche est d'injecter du code créant une requête qui va renvoyer un bit d'information. Les Blind XPath Injection sont expliquée plus en détails par Amit Klein dans les référence en base de page.

Références

Whitepapers

• [1] Amit Klein: "Blind XPath Injection" - http://www.modsecurity.org/archive/amit/blind-xpath-injection.pdf
• [2] XPath 1.0 specifications - http://www.w3.org/TR/xpath