Skip to content

Qu'est-ce qu'une attaque XXE et comment l'atténuer ?

Réponse courte

Le XXE abuse d'un analyseur XML qui résout les entités externes définies dans la DTD d'un document. Un attaquant déclare une entité pointant vers un fichier local ou une URL interne, et l'analyseur la récupère — permettant la divulgation de fichiers, le SSRF et le déni de service. Le correctif est de désactiver le traitement des DTD et la résolution des entités externes dans la configuration de l'analyseur.

L'injection d'entité externe XML (XXE) exploite une fonctionnalité puissante et rarement nécessaire du XML : un document peut définir des entités dans sa Document Type Definition (DTD), et ces entités peuvent pointer vers des ressources externes. Quand un analyseur mal configuré traite du XML fourni par un attaquant, il résout volontiers ces références externes — récupérant ce que l'attaquant a nommé.

Ce qu'un attaquant peut faire

La charge utile classique déclare une entité qui pointe vers un fichier local :

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<foo>&xxe;</foo>

Quand l'analyseur développe &xxe;, le contenu du fichier est extrait dans la réponse — divulgation arbitraire de fichiers. La même astuce avec http:// fait que le serveur récupère une URL interne, transformant le XXE en SSRF (y compris le point de terminaison de métadonnées cloud). Même le XXE à l'aveugle, où la réponse n'est pas renvoyée, peut exfiltrer des données hors bande en faisant déclencher à l'entité une requête sortante vers un serveur d'attaquant. Et l'expansion récursive d'entités (l'attaque « billion laughs ») peut épuiser la mémoire pour un DoS.

Pourquoi c'est si courant

Les analyseurs XML de nombreux langages activaient historiquement le traitement des DTD et des entités externes par défaut. Tout point de terminaison qui accepte du XML — SOAP, SAML, envois de SVG, documents bureautiques, RSS — est un candidat, souvent là où les développeurs ne réalisent même pas que du XML est analysé.

Atténuation

Le correctif fiable est de durcir l'analyseur :

  • Désactivez entièrement le traitement des DTD lorsque c'est possible (par exemple disallow-doctype-decl).
  • Si les DTD sont nécessaires, désactivez les entités générales et de paramètre externes.
  • Maintenez les bibliothèques d'analyseur à jour et privilégiez les valeurs par défaut sûres.
  • Lorsque c'est faisable, utilisez un format moins dangereux comme JSON.

La validation des entrées seule n'aide pas, car le danger réside dans l'analyse, pas dans les valeurs des données.

Les recruteurs recherchent le mécanisme d'entité externe, le trio d'impacts (lecture de fichiers, SSRF, DoS), la conscience du XXE à l'aveugle, et « désactiver les DTD / entités externes » comme correctif plutôt que le filtrage des entrées.

Questions de suivi probables

  • En quoi l'attaque « billion laughs » est-elle une forme de DoS lié au XXE ?
  • Pourquoi le XXE peut-il être exploité même quand le corps de la réponse n'est pas renvoyé ?
  • Quel format de données plus sûr suggéreriez-vous à la place du XML ?

Sources

Recevez 100 questions d'entretien en cybersécurité + réponses

Laissez votre e-mail et nous vous enverrons le pack PDF gratuit et le jeu de flashcards.

Pas de spam. Désabonnez-vous à tout moment.