xml外部实体注入漏洞怎么修复

上周帮一家电商公司做渗透测试，部实他们的体注订单接口直接返回了服务器上的/etc/passwd文件内容。攻击者只需要在XML里塞一行<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>，入漏就能把数据库配置、洞修源码路径全部拖出来。部实这不是体注个例——在野的XXE攻击几乎都指向同一个根源：解析器默认允许加载外部实体，而开发者根本没关掉这个开关。入漏

修复XXE的洞修第一原则不是过滤输入，而是部实彻底禁用外部实体解析。别想着用黑名单拦截file://或http://，体注攻击者换个编码、入漏加个空格就能绕过。洞修正确做法是部实在解析XML之前，直接设置解析器特性。体注拿Java的入漏DocumentBuilderFactory举例：

dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); dbf.setFeature("http://xml.org/sax/features/external-general-entities", false); dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false); 

这一行disallow-doctype-decl最狠，直接让DOCTYPE声明报错，连解析的机会都不给。Python的lxml库则用parser = etree.XMLParser(resolve_entities=False, no_network=True)。每个语言都有对应的开关，麻烦的是你得去翻文档——大多数默认配置都在裸奔。

如果业务确实需要接收DOCTYPE，比如要处理合法的实体定义，那就得退一步：禁用外部实体但保留内部实体。具体做法是把外部实体解析设为false，同时把http://apache.org/xml/features/nonvalidating/load-external-dtd也关掉。这里有个坑：很多开发者只关了external-general-entities，忘了参数实体（parameter entities）和外部DTD子集，结果攻击者用%xxe;照样能打穿。我见过某大厂就是因为漏了参数实体，被一个盲打XXE搞走了整个用户表。

解析器配置完了，还有一层防护要补——对XML内容做结构限制。比如校验XML里是否包含DOCTYPE声明，如果业务根本不需要就拒绝请求。更实际的做法是限制XML大小和嵌套深度，防止实体扩展型攻击（billion laughs）。那玩意儿虽然不读文件，但能让CPU直接飙到100%，服务瘫痪。我在一次应急响应里见过，一个10KB的XML经过实体嵌套展开后变成了3GB内存占用，服务器直接OOM。

最后说个容易被忽略的入口：第三方组件里的XML解析。很多框架内部会解析XML，比如Spring的BeanWrapper、Apache POI解析Excel（xlsx本质是zip包里的XML），甚至某些日志库都会碰XML。你光修了自己的代码没用，依赖库里的解析器可能还在默认状态。用mvn dependency:tree或者pip-audit扫一遍依赖，看有没有引入不安全的XML库版本。去年Log4j2的漏洞就是因为JMSAppender里嵌了个XML解析器，官方补丁都出了好几版才堵全。

修复完记得做回归测试——不光要测正常业务，还得专门构造恶意载荷验证。我惯用的测试payload是<?xml version="1.0"?><!DOCTYPE root [<!ENTITY test SYSTEM "file:///etc/hostname">]><root>&test;</root>，如果响应里出现主机名说明没修干净。更狠的测试是外带数据，用http://你的服务器/钓鱼做实体URL，看有没有DNS请求打过来。记住，修XXE不是改一行配置就完事，得从解析器、业务逻辑、依赖管理三个层面同时下手。毕竟攻击者不会只试一种姿势。