XML外部实体注入漏洞在旧版解析器中的修复

处理XML外部实体注入（XXE）漏洞时，很多开发者的第一反应是禁用外部实体解析。这个思路没错，但在一些运行着旧版解析器的遗留系统中，仅仅设置一个特性（Feature）或属性（Property）往往不够，甚至可能因为配置错误而完全失效。真正棘手的情况是，你面对的是Java 6或更早环境下的Apache Xerces、Oracle SAXParser，或者是.NET 3.5及之前的XmlDocument，这些解析器的默认配置不仅开启了外部实体解析，还允许DTD处理，而且它们的安全开关与现代解析器存在细微但致命的差异。

在Java中，javax.xml.parsers.DocumentBuilderFactory是创建DOM解析器的入口。现代Java 8及以上版本默认禁用DTD，但在Java 7u67和Java 8u20之前，默认配置是危险的。如果你无法升级JDK版本，必须手动设置三层防护。第一层是禁用DTD，这通过设置特性http://apache.org/xml/features/disallow-doctype-decl为true来实现。但很多旧版Xerces并不完全支持这个特性，此时会静默失败，解析器继续处理DTD。因此必须同时设置第二层防护：禁用外部通用实体和外部参数实体。

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
String[] features = {
    "http://apache.org/xml/features/disallow-doctype-decl",
    "http://xml.org/sax/features/external-general-entities",
    "http://xml.org/sax/features/external-parameter-entities",
    "http://apache.org/xml/features/nonvalidating/load-external-dtd"
};
for (String feature : features) {
    try {
        dbf.setFeature(feature, false);
    } catch (ParserConfigurationException e) {
        // 旧版解析器可能不支持某些特性，记录但不中断
        logger.warn("Feature not supported: " + feature);
    }
}

这里有一个关键细节：load-external-dtd特性在旧版Xerces中可能被忽略，此时需要额外设置属性http://apache.org/xml/properties/security-manager，或者直接实例化一个自定义的EntityResolver，让resolveEntity方法始终返回空输入流。第三层防护是使用独立的XMLInputFactory时，必须显式设置XMLInputFactory.SUPPORT_DTD为false，同时将IS_SUPPORTING_EXTERNAL_ENTITIES也设为false。很多旧代码使用XMLStreamReader时只设了SUPPORT_DTD，却忘了外部实体是独立控制的。

SAXParser在旧版Java中比DOM更难防护，因为它的配置项分散在XMLReader和SAXParserFactory两个层面。仅仅在SAXParserFactory上设置特性不够，因为底层XMLReader可能从不同工厂实例化。正确做法是先创建SAXParserFactory，设置安全特性，然后通过它创建SAXParser，再从中获取XMLReader，在XMLReader上再次设置同样的特性。这看似重复，但在旧版实现中，SAXParser和XMLReader可能引用不同的配置对象。

SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setFeature("http://xml.org/sax/features/external-general-entities", false);
spf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
spf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);

SAXParser parser = spf.newSAXParser();
XMLReader reader = parser.getXMLReader();
reader.setFeature("http://xml.org/sax/features/external-general-entities", false);
reader.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
reader.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);

// 最后一道防线：自定义EntityResolver
reader.setEntityResolver(new EntityResolver() {
    public InputSource resolveEntity(String publicId, String systemId) {
        return new InputSource(new StringReader(""));
    }
});

自定义EntityResolver是旧版环境下的终极兜底方案。即使所有特性设置都因为解析器版本问题而失效，只要实体解析器返回空输入源，攻击者就无法读取本地文件或发起外部请求。但注意，这种拦截方式会同时阻止合法的DTD引用，如果你的业务确实需要验证DTD，需要在这里做白名单校验，只放行特定的系统ID或公共ID。

PHP的DOMDocument和SimpleXML底层依赖libxml库。在libxml 2.9之前，默认启用外部实体加载。很多资料会告诉你使用libxml_disable_entity_loader(true)来禁用实体加载器，但这个函数在PHP 8.0中已被废弃，因为它是全局状态，会影响其他线程。在旧版PHP中，这个函数确实有效，但有一个容易忽略的问题：它必须在每次XML解析前调用，因为其他第三方库可能重置了这个全局标志。更可靠的做法是使用libxml_set_external_entity_loader来注册一个自定义加载器，这个函数从PHP 5.5.8开始可用。

libxml_set_external_entity_loader(function($public, $system, $context) {
    // 完全禁止外部实体加载
    return null;
});

$dom = new DOMDocument();
$dom->loadXML($xmlString);

如果你还在维护PHP 5.4以下的系统，只能使用libxml_disable_entity_loader，但务必在每次loadXML或loadHTML调用前后都进行设置和恢复，避免影响同一进程中的其他XML处理逻辑。另外，loadHTML方法在处理HTML文档时也会触发libxml的实体解析，攻击者可以通过HTML中的DOCTYPE声明注入外部实体，因此对HTML输入同样需要做防护。

在.NET 3.5及之前的System.Xml.XmlDocument中，XmlResolver属性默认指向一个XmlUrlResolver实例，它会解析外部DTD和实体。很多开发人员知道要把XmlResolver设为null，但忽略了一个事实：如果XML文档本身包含内联DTD子集，即使没有外部引用，实体声明依然可以触发拒绝服务攻击，例如通过递归实体展开导致内存耗尽。因此除了禁用外部解析，还需要限制DTD处理。

XmlDocument doc = new XmlDocument();
doc.XmlResolver = null;

// 对于.NET 4.0之前的版本，还需要设置这个
if (doc.XmlResolver != null) {
    doc.XmlResolver = null;
}

// 使用XmlReaderSettings进一步加固
XmlReaderSettings settings = new XmlReaderSettings();
settings.DtdProcessing = DtdProcessing.Prohibit;
settings.XmlResolver = null;
settings.MaxCharactersFromEntities = 1024;

using (XmlReader reader = XmlReader.Create(new StringReader(xmlString), settings)) {
    doc.Load(reader);
}

这里的关键点是，直接设置XmlDocument的XmlResolver为null在某些旧版.NET中不够，因为如果XML包含外部实体引用，解析过程可能在设置生效前就已经触发了网络请求。正确的做法是先用XmlReader配合安全设置对XML进行预解析，再将XmlReader传递给XmlDocument.Load方法。DtdProcessing.Prohibit在.NET 4.0引入，如果你还在用.NET 3.5，需要将DtdProcessing设为DtdProcessing.Parse但配合自定义的XmlResolver来拦截外部资源，或者干脆升级到.NET 4.0以上。

Python的xml.etree.ElementTree在Python 3.8之前默认解析XML实体。从Python 3.8开始，默认的XMLParser不再处理外部实体，这是一个向后不兼容的安全修复。但在Python 2.7和Python 3.7及更早版本中，你需要显式地使用defusedxml库，或者手动配置解析器。defusedxml是一个专门为Python标准库XML模块提供安全替代的库，它通过子类化标准解析器并禁用实体解析来实现防护。

# Python 3.7及之前版本的安全写法
from defusedxml.ElementTree import parse, fromstring
tree = parse('input.xml')
root = fromstring(xml_string)

# 或者手动配置标准库（不推荐，容易遗漏）
import xml.etree.ElementTree as ET
parser = ET.XMLParser(resolve_entities=False)
tree = ET.parse('input.xml', parser=parser)

对于lxml库，情况更复杂。lxml默认使用libxml2，且默认配置允许实体解析。即使在较新版本的lxml中，也需要显式设置resolve_entities=False，同时设置no_network=True来阻止网络访问。旧版本lxml还需要额外设置load_dtd=False和dtd_validation=False。如果你在使用lxml.html模块解析HTML，同样需要传入安全的解析器实例，因为HTML解析器底层也是XML解析器。

修复旧版解析器的XXE漏洞，不能依赖单一配置项。实践中有效的做法是建立多层防御：第一层在解析器工厂层面禁用DTD和外部实体特性；第二层在解析器实例层面重复设置安全标志；第三层注册自定义的EntityResolver或XmlResolver，直接拦截所有外部资源请求；第四层对输入进行预处理，检测并移除DOCTYPE声明。预处理虽然粗暴，但在无法修改解析器配置的极端场景下（例如使用第三方闭源库），这是唯一可行的手段。

// 预处理：移除DOCTYPE声明
public static String removeDoctype(String xml) {
    if (xml == null) return null;
    return xml.replaceAll("(?i)]*>", "")
              .replaceAll("(?i)]*>", "");
}

这种正则预处理方式有明显局限性，它可能破坏合法的XML结构，也可能被编码绕过。因此它只能作为最后一层应急措施，不能替代解析器层面的安全配置。更稳健的做法是结合使用：先做预处理降低风险，再通过安全配置的解析器处理，最后用实体解析器兜底。此外，在运行时检测方面，可以通过检查解析器版本和配置状态来验证防护是否生效。例如在Java中，可以尝试解析一个包含外部实体的测试XML，观察是否抛出异常或被拦截，以此确认安全配置真正起作用。

很多旧系统使用了Apache Struts、Spring 3.x或更早的框架，这些框架内部可能自行创建XML解析器实例，绕过你在应用层设置的安全配置。例如Struts 1的Digester组件在解析配置文件时会创建独立的SAXParser，Spring 3.x的XMLBeanFactory也有类似行为。对于这类情况，需要检查框架文档，看是否提供了全局配置解析器属性的方法。如果框架没有提供配置入口，可以考虑在JVM层面设置系统属性来改变默认解析器行为，例如通过-Djavax.xml.parsers.DocumentBuilderFactory指定一个自定义的安全工厂类，但这个方案影响面广，需要充分测试。

在PHP中，同样存在框架和CMS系统自行初始化DOMDocument的情况。WordPress 4.9之前的版本在处理XML-RPC请求时存在XXE漏洞，就是因为底层使用了未加固的DOMDocument。如果你维护的旧系统使用了类似框架，升级框架版本是首选方案，如果无法升级，需要审计框架中所有创建DOMDocument或SimpleXMLElement的代码路径，通过猴子补丁或包装函数来统一注入安全配置。

最终，旧版解析器的XXE修复是一个需要深入理解解析器内部机制的工程问题。没有一行代码能解决所有情况，必须根据具体的解析器版本、编程语言环境和框架依赖，组合使用特性设置、实体解析器拦截、输入预处理和运行时检测等多种手段。在完成修复后，使用包含外部实体引用的测试用例进行验证，确认解析器确实抛出了异常或返回了安全的解析结果，而不是静默地加载了外部资源。