XXE攻击是因XML解析器未禁用外部实体导致的漏洞,可读取本地文件、发起内网请求等;防御必须禁用外部实体,辅以输入校验、最小权限和WAF拦截,并加强检测监控。

XML实体注入攻击(XXE,XML External Entity Injection)本质是攻击者利用XML解析器对外部实体的不当处理,诱导服务器读取本地文件、发起内网请求、触发拒绝服务,甚至在特定条件下执行命令。它不依赖代码执行漏洞,而是靠解析器“太听话”——只要配置松懈,一个恶意DOCTYPE声明就能让服务器主动打开/etc/passwd或访问192.168.1.100:8080。
XXE是怎么发生的
关键前提是:应用接收并解析用户可控的XML数据,且XML解析器未禁用外部实体功能。典型场景包括SOAP接口、配置文件上传、REST API中接受XML格式Body等。攻击者插入类似这样的内容:
]>
一旦解析器加载并展开&xxe;,响应体就可能直接返回系统密码文件内容。
最有效的防御手段是禁用外部实体解析
这不是可选项,而是必须项。不同语言有对应的安全配置方式:
- Java中使用
DocumentBuilderFactory时,务必设置两个关键特性为true:dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);dbf.setFeature("http://xml.org/sax/features/external-general-entities", false); - PHP中避免使用
libxml_disable_entity_loader(false);新版libxml(≥2.9.1)默认禁用,但若调用simplexml_load_string,仍需显式传参LIBXML_NOENT | LIBXML_DTDATTR并确保不开启实体加载 - Python推荐直接使用
defusedxml替代原生xml.etree.ElementTree,它默认拦截所有危险行为
辅助防护不能只靠过滤关键词
单纯正则匹配或SYSTEM容易被绕过(比如大小写混淆、注释干扰、编码变形)。真正可靠的做法是:
- 解析前先做白名单式输入校验:只允许必要标签、属性和字符集,拒绝含DOCTYPE、ENTITY、CDATA等结构的XML
- 运行XML解析服务的进程采用最小权限原则,禁止以root或SYSTEM身份运行
- 在Web层(如Nginx、WAF)配置规则,拦截含
file://、http://、php://等协议的XML请求体
别忽略检测和监控环节
防御不是一劳永逸。建议:
- 在测试阶段用经典payload主动探测,例如发送含
file:///etc/hostname的XML,观察是否回显 - 在生产环境记录XML解析异常日志,特别是
SAXParseException或EntityResolutionException类错误,它们可能是XXE尝试失败的痕迹 - 集成OWASP ZAP或Burp Suite插件进行自动化扫描,定期覆盖所有接受XML的端点









