Contexte

L'injection d'entités externes XML (XXE) est une vulnérabilité de sécurité web qui permet à un attaquant de manipuler le traitement des données XML par une application, permettant souvent l'accès à des fichiers sur le système de fichiers du serveur de l'application et l'interaction avec tout système externe ou backend que l'application peut atteindre. Dans certains cas, un attaquant peut exploiter une vulnérabilité XXE pour exécuter des attaques de falsification de requête côté serveur (SSRF) et compromettre les serveurs sous-jacents ou l'infrastructure centrale.

Certaines applications utilisent le format XML pour échanger des données entre le serveur et le navigateur, en utilisant des bibliothèques standard ou des API de plateforme pour traiter les données XML sur le serveur. Les vulnérabilités XXE résultent de fonctionnalités potentiellement dangereuses de la spécification XML, qui sont prises en charge par les analyseurs standard même si l'application ne les utilise normalement pas.

Les entités externes XML sont une catégorie d'entité XML personnalisée qui charge des valeurs définies à partir de l'extérieur de la DTD dans laquelle elles sont déclarées. Les entités externes sont particulièrement intéressantes d'un point de vue de sécurité car elles permettent d'établir une entité en fonction d'un chemin de fichier ou du contenu d'une URL.

Il existe différents types d'attaques XXE, notamment l'exploitation de XXE pour récupérer des fichiers, où une entité externe contenant le contenu du fichier est définie et renvoyée dans la réponse de l'application. De même, l'exploitation de XXE pour exécuter des attaques SSRF consiste à définir une entité externe en fonction d'une URL vers un système backend. XXE aveugle peut être exploité pour l'exfiltration de données hors bande, où des données sensibles sont transmises du serveur d'application à un système contrôlé par un attaquant. Enfin, XXE aveugle peut être utilisé pour récupérer des données via des messages d'erreur en déclenchant un message d'erreur d'analyse contenant des données confidentielles.

Exploitation de XXE pour récupérer des fichiers

Pour mener une attaque d'injection XXE qui récupère un fichier arbitraire à partir du système de fichiers du serveur, deux modifications sont requises dans le XML soumis :

Insérez (ou modifiez) un élément DOCTYPE spécifiant une entité externe qui inclut le chemin du fichier. Modifiez une valeur de données dans le XML renvoyé dans la réponse de l'application pour utiliser l'entité externe définie. Par exemple, supposons qu'une application de commerce électronique vérifie l'état des stocks d'un produit en envoyant le code XML suivant au serveur :

 <?xml version="1.0" encoding="UTF-8"?>
<stockCheck><productId>08</productId></stockCheck>

Comme l'application ne dispose d'aucune défense spécifique contre les attaques XXE, il est possible d'exploiter la vulnérabilité XXE pour récupérer le fichier /etc/passwd en soumettant la charge utile XXE suivante:

 <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<stockCheck><productId>&xxe;</productId></stockCheck>

This response from the application can reveal sensitive data such as system configuration, user accounts, and passwords to the attacker. Therefore, it is crucial to prevent XXE vulnerabilities in web applications by validating and sanitizing user input, restricting access to sensitive resources, and using secure configurations for XML parsers.

 Invalid product ID: root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin

Exploiter XXE pour effectuer des attaques SSRF

Outre la récupération de données confidentielles, les attaques XXE peuvent également conduire à des attaques de type Server-Side Request Forgery (SSRF). Cette vulnérabilité peut être grave, permettant à l'application côté serveur de transmettre des requêtes HTTP à n'importe quelle URL accessible au serveur. Pour effectuer une attaque SSRF en exploitant une vulnérabilité XXE, une entité XML externe doit être définie en utilisant l'URL cible, et l'entité doit être utilisée dans une valeur de données. Si l'entité définie peut être utilisée dans une valeur de données renvoyée dans la réponse de l'application, la réponse de l'URL peut être vue dans la réponse de l'application, offrant une interaction bidirectionnelle avec le système principal. Sinon, seules des attaques SSRF aveugles peuvent être exécutées, ce qui peut toujours avoir des conséquences critiques.

Dans l'exemple XXE suivant, l'entité externe va forcer le serveur à transmettre une requête HTTP à un système interne de l'infrastructure de l'organisation:

 <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://internal.website.com/"> ]>

Vulnérabilités XXE aveugles

De nombreuses vulnérabilités XXE sont "aveugles", ce qui signifie que l'application ne divulgue pas les valeurs des entités externes définies dans ses réponses, rendant la récupération directe de fichiers côté serveur impossible.

Malgré cela, les vulnérabilités XXE aveugles peuvent toujours être identifiées et exploitées, mais des techniques plus sophistiquées sont nécessaires. Des techniques hors bande peuvent parfois être utilisées pour découvrir et exploiter des vulnérabilités afin d'extraire des données. De plus, des erreurs d'analyse XML peuvent parfois être déclenchées, ce qui expose des données sensibles dans des messages d'erreur.

Trouver une surface d'attaque cachée pour l'injection XXE

La surface d'attaque des vulnérabilités d'injection XXE est souvent apparente car le trafic HTTP habituel de l'application comprend des requêtes contenant des données au format XML. Cependant, dans certains cas, la surface d'attaque est moins visible. Néanmoins, avec la bonne approche, une surface d'attaque XXE peut être localisée dans des requêtes qui ne contiennent pas de XML.

Attaques XInclude

Certaines applications acceptent des données de clients, les intègrent côté serveur dans un document XML, puis analysent le document. Par exemple, cela se produit lorsque des données soumises par un client sont incluses dans une requête SOAP de backend que le service SOAP de backend traite ensuite.

Dans de tels cas, les attaques XXE traditionnelles ne sont pas possibles car vous n'avez pas un contrôle total sur le document XML et ne pouvez donc pas définir ou modifier un élément DOCTYPE. Cependant, vous pouvez peut-être utiliser XInclude à la place. XInclude est un composant de la spécification XML qui permet la construction d'un document XML à partir de sous-documents. Comme les attaques XInclude peuvent être placées dans n'importe quelle valeur de données dans un document XML, l'attaque peut être exécutée dans des circonstances où vous ne contrôlez qu'un seul élément de données placé dans un document XML côté serveur.

 <foo xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include parse="text" href="file:///etc/passwd"/></foo>

Attaques XXE via le téléchargement de fichiers

Certaines applications permettent le téléchargement de fichiers qui sont ensuite gérés côté serveur. Différents formats de fichiers, y compris ceux basés sur XML, sont utilisés pour ces fichiers. Parmi les formats de fichiers basés sur XML, citons les formats de documents de bureau tels que DOCX, ainsi que les formats d'image tels que SVG.

Considérons un exemple dans lequel une application permet aux utilisateurs de télécharger des images, puis effectue un traitement ou une validation côté serveur après le téléchargement. Même si l'application s'attend à recevoir un format d'image tel que PNG ou JPEG, la bibliothèque de traitement d'images qu'elle utilise peut également prendre en charge les images SVG. Comme le format SVG est basé sur XML, un attaquant peut télécharger une image SVG malveillante et accéder à une surface d'attaque cachée pour les vulnérabilités XXE.

Attaques XXE via le type de contenu modifié

Il est courant que la plupart des requêtes POST utilisent un type de contenu par défaut, généralement généré par des formulaires HTML et connu sous le nom de application/x-www-form-urlencoded. Cependant, certains sites Web peuvent encore recevoir des requêtes dans d'autres types de contenu, y compris XML, qu'ils peuvent tolérer même si ce n'est pas le format attendu.

 POST /action HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 7

foo=bar

Ensuite, il est possible que vous puissiez envoyer la demande suivante et obtenir le même résultat:

 POST /action HTTP/1.0
Content-Type: text/xml
Content-Length: 52

<?xml version="1.0" encoding="UTF-8"?><foo>bar</foo>

Si une application analyse le contenu du corps de la requête comme du XML et accepte des requêtes contenant du XML dans le corps de la requête, la surface d'attaque XXE peut être cachée. Cependant, les attaquants peuvent atteindre cette surface en modifiant le format de la requête pour utiliser du XML.

Comment trouver et tester les vulnérabilités XXE

Voici quelques façons possibles de reformuler la phrase tout en conservant un nombre similaire de lignes :

• Pour détecter les vulnérabilités XXE, vous pouvez essayer différentes techniques telles que l'utilisation d'entités externes pour récupérer un fichier à partir du serveur, la définition d'une entité externe basée sur une URL pour surveiller les interactions ou tenter une attaque XInclude pour récupérer un fichier en incluant des données non XML dans un document XML côté serveur.
• Pour tester les vulnérabilités XXE, vous pouvez vérifier si l'application est vulnérable à la récupération de fichiers en définissant une entité externe et en l'utilisant dans la réponse de l'application. Vous pouvez également tester les vulnérabilités XXE aveugles en définissant une entité externe basée sur une URL et en surveillant les interactions du système. Enfin, vous pouvez utiliser une attaque XInclude pour tester si l'inclusion de données utilisateur non XML dans un document XML côté serveur est vulnérable à la récupération de fichiers.
• Une façon de tester les vulnérabilités XXE consiste à essayer de récupérer un fichier à partir du serveur en définissant une entité externe basée sur un fichier de système d'exploitation bien connu et en l'utilisant dans la réponse de l'application. Une autre façon consiste à tester les vulnérabilités XXE aveugles en définissant une entité externe basée sur une URL pour surveiller les interactions avec le système. Enfin, vous pouvez vérifier les vulnérabilités liées à l'inclusion de données utilisateur non XML dans un document XML côté serveur à l'aide d'une attaque XInclude pour récupérer un fichier de système d'exploitation.

##Comment prévenir les vulnérabilités XXE Les vulnérabilités XXE se produisent parce que la bibliothèque d'analyse XML de l'application prend en charge des fonctionnalités XML potentiellement dangereuses que l'application n'utilise pas ou ne prévoit pas d'utiliser. La désactivation de ces fonctionnalités est le moyen le plus simple et le plus efficace de prévenir les attaques XXE. La désactivation de la résolution des entités externes et de la prise en charge XInclude est généralement suffisante et peut être accomplie grâce à des options de configuration ou des remplacements programmatiques du comportement par défaut. Consultez la documentation de votre bibliothèque d'analyse XML ou de votre API pour obtenir des conseils sur la désactivation des fonctionnalités inutiles.