Entidades externas XML: cómo desactivar el procesamiento de DTD en los parsers

Qué es

Una definición de tipo de documento (DTD) dentro de un documento XML puede definir entidades. Una entidad externa (<!ENTITY x SYSTEM "file:///etc/passwd">) hace que el parser lea un archivo o una URL y sustituya su contenido; una entidad de parámetro puede descargar una DTD remota y exfiltrar datos a ciegas; las entidades anidadas ("billion laughs") se expanden de forma exponencial. La hoja de referencia de OWASP (citada) afirma que la prevención más segura es desactivar las DTD por completo, lo que además detiene las variantes de denegación de servicio, y que, cuando las DTD son necesarias, hay que desactivar las entidades externas y las declaraciones de DTD externas con el método propio de cada parser.

Por qué importa

Todavía llega XML desde el exterior en aserciones SAML, SOAP, formatos de documento (SVG es XML; DOCX y XLSX son XML comprimido en zip), feeds RSS, sitemaps y cargas de archivos de configuración. Es el parser, y no la aplicación, quien decide si abre file:/// o http://169.254.169.254/, de modo que la vulnerabilidad reside en un valor por defecto y no en código visible.

Cómo aplicarlo

• Java: establezca en true la característica de Xerces http://apache.org/xml/features/disallow-doctype-decl en DocumentBuilderFactory y SAXParserFactory. StAX no tiene esa característica: establezca XMLInputFactory.SUPPORT_DTD e IS_SUPPORTING_EXTERNAL_ENTITIES en false. Los transformadores y validadores consumen un parser; páseles un XMLReader endurecido o, en implementaciones JAXP 1.5, establezca ACCESS_EXTERNAL_DTD en una cadena vacía. La tabla de la hoja de referencia también menciona jdk.xml.dtd.support=deny para los parsers integrados de Java 22 y posteriores.
• libxml2 (y sus bindings, como lxml o PHP): no pase XML_PARSE_NOENT ni XML_PARSE_DTDLOAD; la hoja de referencia señala que libxml2 desactiva por defecto la sustitución de entidades externas desde la versión 2.9 y que PHP 8.0 y posteriores previenen XXE por defecto.
• Python: los parsers de la biblioteca estándar se basan en Expat, que según la documentación de Python (citada) no accede a archivos locales ni crea conexiones de red por defecto; la misma página advierte de que las versiones de Expat anteriores a la 2.7.2 pueden ser vulnerables a billion laughs, a la expansión cuadrática (quadratic blowup) y a ataques con tokens grandes, e indica que se compruebe pyexpat.EXPAT_VERSION. Use defusedxml para entradas no confiables.
• .NET: la hoja de referencia indica que los parsers integrados son seguros frente a entidades externas desde la versión 4.5.2 del framework, con XmlResolver en null por defecto; en destinos anteriores, establezca usted mismo XmlResolver en null y mantenga DtdProcessing en Prohibit. Las aplicaciones ASP.NET deben además establecer httpRuntime targetFramework en 4.5.2 o posterior en Web.config; de lo contrario se aplican los valores por defecto inseguros, sea cual sea el framework instalado.
• Sea cual sea la pila tecnológica: añada una prueba que alimente un documento con una entidad externa y otro con entidades recursivas, y verifique que ambos se rechazan.

Trampas

Bibliotecas que construyen su propio parser e ignoran la configuración de su factory (toolkits SAML, conversores de PDF y de documentos ofimáticos). Corregir el parser DOM pero no la ruta SAX o StAX que se usa en otro lugar. Falta de límites de tamaño incluso cuando las entidades están desactivadas. Considerar inofensiva una página de error que repite el contenido analizado: es el canal de exfiltración.