XXE漏洞源于XML解析器默认加载外部实体，需显式禁用DOCTYPE和外部实体；防御须在解析前校验内容、优先使用defusedxml等安全库，并推荐改用JSON等无实体格式。
XML解析器默认开启外部实体导致XXE
绝大多数XML解析器（如Java的DocumentBuilder、Python的xml.etree.ElementTree、PHP的libxml）在默认配置下会加载并解析外部实体（DOCTYPE中的SYSTEM或PUBLIC声明），这是XXE漏洞的根本成因。上传的XML文件一旦包含恶意 ]>，就可能触发敏感文件读取、SSRF甚至命令执行。
关键不是“要不要解析XML”，而是“是否显式禁用外部实体”。依赖框架默认行为等于裸奔。
- Java：必须调用
setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)或setFeature("http://xml.org/sax/features/external-general-entities", false) - Python：
xml.etree.ElementTree不安全，改用defusedxml.ElementTree；若用lxml，需设置parser = etree.XMLParser(resolve_entities=False) - PHP：调用
libxml_disable_entity_loader(true)（注意：PHP 8.0+已废弃该函数，应改用LIBXML_NOENT | LIBXML_DTDLOAD等标志位控制）
仅校验文件后缀或Content-Type无法阻止XXE
攻击者可将恶意XML内容保存为report.pdf或image.jpg，再通过Content-Type: image/jpeg绕过前端/中间件的MIME类型检查。后端若仍按XML解析，XXE照常触发。
真正有效的校验是：在解析前确认内容确实是可信的XML结构，且不含危险声明。
- 对上传文件先做轻量级文本扫描：拒绝包含
/code>、、SYSTEM、PUBLIC的原始字节流（注意编码绕过，如UTF-16 BOM + 混淆空格） - 不要只检查首行或前1KB，XXE实体定义可能出现在任意位置
- 避免正则硬匹配——
比/code>更健壮，但仍有被绕过风险；优先用解析器自身的禁用机制
用非XML格式替代是最彻底的防御
如果业务逻辑允许，直接放弃XML上传，改用JSON、YAML（需禁用!!python/object等危险标签）、CSV等无实体机制的格式。这不是妥协，而是消除攻击面的最有效手段。
很多所谓“必须用XML”的场景，其实只是历史接口约定，后端完全可兼容多格式并强制降级处理。
- API层统一接受
application/json，XML请求返回415 Unsupported Media Type - 遗留系统集成时，在网关层做XML→JSON转换（如用XSLT或
xmllint --xpath提取后转JSON），后端只处理JSON - 若必须存XML，也应在入库前剥离
DOCTYPE和ENTITY节点，仅保留...
import defusedxml.ElementTree as ET
try:
tree = ET.parse(upload_file)
except ET.ParseError as e:
raise ValueError("Invalid or unsafe XML content") from e
# defusedxml 已默认禁用外部实体，无需额外配置XXE的隐蔽性在于它不依赖代码执行，只靠解析器特性就能泄露数据。哪怕你把所有eval、exec都封死，只要XML解析器开着外部实体，上传一个文件就可能让服务器自曝内网IP或数据库密码。禁用开关的位置、时机、作用域，三者缺一不可。
