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等。攻击者插入类似这样的内容：
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<foo>&xxe;</foo>
一旦解析器加载并展开&xxe;，响应体就可能直接返回系统密码文件内容。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
最有效的防御手段是禁用外部实体解析
这不是可选项，而是必须项。不同语言有对应的安全配置方式：
- 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，它默认拦截所有危险行为
辅助防护不能只靠过滤关键词
单纯正则匹配<!ENTITY或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的端点
