XML External Entities: DTD-Verarbeitung in Parsern deaktivieren

Worum es geht

Eine Dokumenttypdefinition innerhalb eines XML-Dokuments kann Entitäten definieren. Eine externe Entität (<!ENTITY x SYSTEM "file:///etc/passwd">) veranlasst den Parser, eine Datei oder URL zu lesen und den Inhalt einzusetzen; eine Parameterentität kann eine entfernte DTD abrufen und Daten blind exfiltrieren; verschachtelte Entitäten („billion laughs") expandieren exponentiell. Das OWASP-Cheat-Sheet (zitiert) hält fest, dass die sicherste Vorbeugung darin besteht, DTDs vollständig zu deaktivieren, was auch die Denial-of-Service-Varianten stoppt, und dass, wo DTDs benötigt werden, externe Entitäten und externe DTD-Deklarationen auf die jeweils parserspezifische Weise deaktiviert werden müssen.

Warum es wichtig ist

XML trifft weiterhin von aussen ein: in SAML-Assertions, SOAP, Dokumentformaten (SVG ist XML; DOCX und XLSX sind gezipptes XML), RSS-Feeds, Sitemaps und Konfigurations-Uploads. Der Parser, nicht die Anwendung, öffnet file:/// oder http://169.254.169.254/, falls er das für nötig hält; die Schwachstelle steckt deshalb in einer Voreinstellung und nicht im sichtbaren Code.

So wird es angewendet

• Java: die Xerces-Funktion http://apache.org/xml/features/disallow-doctype-decl bei DocumentBuilderFactory und SAXParserFactory auf true setzen. StAX kennt diese Funktion nicht: XMLInputFactory.SUPPORT_DTD und IS_SUPPORTING_EXTERNAL_ENTITIES auf false setzen. Transformer und Validatoren verbrauchen einen Parser; ihnen einen gehärteten XMLReader übergeben, oder bei JAXP-1.5-Implementierungen ACCESS_EXTERNAL_DTD auf den leeren String setzen. Die Tabelle des Cheat-Sheets führt für die eingebauten Parser ab Java 22 zusätzlich jdk.xml.dtd.support=deny auf.
• libxml2 (und Bindings wie lxml oder PHP): XML_PARSE_NOENT oder XML_PARSE_DTDLOAD nicht übergeben; das Cheat-Sheet merkt an, dass libxml2 die Ersetzung externer Entitäten seit Version 2.9 standardmässig deaktiviert und dass PHP 8.0 und neuer XXE standardmässig verhindern.
• Python: Die Parser der Standardbibliothek stützen sich auf Expat, das laut Python-Dokumentation (zitiert) standardmässig weder auf lokale Dateien zugreift noch Netzwerkverbindungen aufbaut; dieselbe Seite warnt, dass Expat-Versionen unter 2.7.2 für billion laughs, quadratic blowup und Large-Token-Angriffe anfällig sein können, und rät, pyexpat.EXPAT_VERSION zu prüfen. Für nicht vertrauenswürdige Eingaben defusedxml verwenden.
• .NET: Das Cheat-Sheet meldet die eingebauten Parser ab Framework 4.5.2 als sicher gegenüber externen Entitäten, mit standardmässig null gesetztem XmlResolver; bei älteren Zielversionen XmlResolver selbst auf null setzen und DtdProcessing auf Prohibit belassen. ASP.NET-Anwendungen müssen zudem httpRuntime targetFramework in der Web.config auf 4.5.2 oder neuer setzen, sonst gelten die unsicheren Standardwerte unabhängig vom installierten Framework.
• Unabhängig vom Stack: einen Test hinzufügen, der ein Dokument mit externer Entität und eines mit rekursiven Entitäten einspeist und die Zurückweisung prüft.

Stolpersteine

Bibliotheken, die ihren eigenen Parser bauen und die eigenen Factory-Einstellungen ignorieren (SAML-Toolkits, PDF- und Office-Konverter). Den DOM-Parser zu korrigieren, aber nicht den anderswo genutzten SAX- oder StAX-Pfad. Fehlende Grössenbegrenzungen, selbst wenn Entitäten deaktiviert sind. Eine Fehlerseite, die den geparsten Inhalt zurückspiegelt, für harmlos zu halten; sie ist der Exfiltrationskanal.