Entités externes XML : désactiver le traitement des DTD dans les analyseurs

Ce que c'est

Une définition de type de document (DTD) à l'intérieur d'un document XML peut définir des entités. Une entité externe (<!ENTITY x SYSTEM "file:///etc/passwd">) fait lire par l'analyseur un fichier ou une URL et en substitue le contenu ; une entité paramètre peut aller chercher une DTD distante et exfiltrer des données à l'aveugle ; des entités imbriquées (« billion laughs ») s'étendent de façon exponentielle. La fiche OWASP citée indique que la prévention la plus sûre consiste à désactiver entièrement les DTD, ce qui arrête aussi les variantes de déni de service, et que là où les DTD sont nécessaires, les entités externes et les déclarations de DTD externes doivent être désactivées selon la méthode propre à l'analyseur.

Pourquoi c'est important

Le XML continue d'arriver de l'extérieur via les assertions SAML, SOAP, les formats de document (le SVG est du XML ; DOCX et XLSX sont du XML compressé en zip), les flux RSS, les sitemaps et les téléversements de configuration. C'est l'analyseur, et non l'application, qui décide d'ouvrir file:/// ou http://169.254.169.254/, si bien que la vulnérabilité réside dans une valeur par défaut plutôt que dans du code visible.

Comment l'appliquer

• Java : positionner à vrai la fonctionnalité Xerces http://apache.org/xml/features/disallow-doctype-decl sur DocumentBuilderFactory et SAXParserFactory. StAX ne dispose pas d'une telle fonctionnalité : mettre XMLInputFactory.SUPPORT_DTD et IS_SUPPORTING_EXTERNAL_ENTITIES à false. Les transformateurs et les validateurs consomment un analyseur ; leur fournir un XMLReader durci, ou, sur les implémentations JAXP 1.5, positionner ACCESS_EXTERNAL_DTD à la chaîne vide. Le tableau de la fiche liste aussi jdk.xml.dtd.support=deny pour les analyseurs intégrés de Java 22 et versions ultérieures.
• libxml2 (et ses liaisons telles que lxml ou PHP) : ne pas passer XML_PARSE_NOENT ni XML_PARSE_DTDLOAD ; la fiche note que libxml2 désactive par défaut la substitution d'entités externes depuis la version 2.9 et que PHP 8.0 et versions ultérieures préviennent les XXE par défaut.
• Python : les analyseurs de la bibliothèque standard s'appuient sur Expat, dont la documentation Python citée indique qu'il n'accède pas aux fichiers locaux ni ne crée de connexions réseau par défaut ; la même page avertit que les versions d'Expat antérieures à 2.7.2 peuvent être vulnérables aux attaques « billion laughs », à l'explosion quadratique et aux jetons de grande taille, et invite à vérifier pyexpat.EXPAT_VERSION. Utiliser defusedxml pour les entrées non fiables.
• .NET : la fiche indique que les analyseurs intégrés sont protégés des entités externes à partir du framework 4.5.2, avec XmlResolver à null par défaut ; sur des cibles plus anciennes, positionner soi-même XmlResolver à null et garder DtdProcessing à Prohibit. Les applications ASP.NET doivent aussi positionner httpRuntime targetFramework à 4.5.2 ou une version ultérieure dans Web.config, sans quoi les valeurs par défaut non sûres s'appliquent, quelle que soit la version du framework installé.
• Quelle que soit la pile technique : ajouter un test qui soumet un document contenant une entité externe et un autre contenant des entités récursives, et qui vérifie leur rejet.

Pièges

Les bibliothèques qui construisent leur propre analyseur et ignorent les réglages de la factory fournie (kits SAML, convertisseurs PDF et bureautiques). Corriger l'analyseur DOM sans corriger le chemin SAX ou StAX utilisé ailleurs. Limites de taille absentes même là où les entités sont désactivées. Considérer comme inoffensive une page d'erreur qui réaffiche le contenu analysé ; c'est justement le canal d'exfiltration.