xml解析器默认加载外部实体是规范行为而非bug，需显式禁用以防范xxe；实操须统一配置所有解析入口、前置内容检测、避免仅依赖后缀校验，并优先考虑json等替代方案。
XML解析器默认会加载外部实体
绝大多数XML解析库（比如Java的DocumentBuilder、Python的xml.etree.ElementTree、PHP的simplexml_load_string）在未显式禁用时，都会尝试解析并加载DOCTYPE中声明的外部实体（如）。这不是bug，是规范默认行为——但业务里几乎从不需要它。
实操建议：
- Java：创建
DocumentBuilderFactory后必须调用setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)，仅设setFeature("http://xml.org/sax/features/external-general-entities", false)不够，攻击者可绕过 - Python：别用
xml.etree.ElementTree.parse()直接解析不可信XML；改用defusedxml.ElementTree.parse()，或手动配置xml.sax.make_parser()并禁用feature_external_ges - PHP：启用
libxml_disable_entity_loader(true)（注意：该函数在PHP 8.0+已废弃，需改用libxml_set_external_entity_loader(null)）
上传接口没做XML内容预检就解析太危险
很多后端把文件上传和XML解析拆成两步：先存临时文件，再读取解析。如果只校验文件后缀（如.xml）或Content-Type（如application/xml），攻击者传一个xxx.jpg但内容是恶意XML，照样触发XXE。
实操建议：
- 上传阶段就做内容检测：用
libxml_parse_file()（PHP）或xml.parsers.expat.ParserCreate()（Python）做轻量预解析，捕获XML_ERROR_EXTERNAL_ENTITY_HANDLING类错误 - 禁止接受含
DOCTYPE的XML：正则/快速拦截（注意：不能替代解析器配置，仅作前置过滤） - 若业务真需要DTD（极少见），必须白名单限定外部实体协议，例如只允许
http://且域名可控，禁用file://、php://、gopher://
DOM/SAX解析器配置差异容易漏掉一个开关
同一个语言常有多个XML解析路径，不同API关闭外部实体的方式不统一。比如Java里SAXParserFactory要设setFeature("http://xml.org/sax/features/external-general-entities", false)，而DocumentBuilderFactory还要额外关disallow-doctype-decl；漏掉任一，XXE就可能生效。
实操建议：
- 检查所有XML入口点：不只是用户上传，还包括HTTP回调、第三方Webhook、配置文件加载、日志XML片段提取等场景
- 统一封装解析函数，内部强制设置全部安全开关，禁止业务代码直调原生解析器
- 测试时用经典payload验证：
<?xml version="1.0"?> ]><foo>&xxe;</foo>，观察是否发起外连
禁用外部实体后报错“Invalid XML: no DTD found”不是漏洞回退
有些老系统禁用DOCTYPE后，原有合法XML因依赖内部DTD（如定义）而解析失败。这时不能为了兼容又打开外部实体，那是拿安全换可用。
实操建议：
- 把内部实体声明硬编码进解析逻辑：例如预处理XML，将
- 用
EntityResolver（Java）或xml_set_entity_decl_handler（PHP）提供白名单实体映射，不加载任何远程资源 - 优先考虑替换技术栈：用JSON替代XML传输，或用Protocol Buffers等二进制格式，彻底规避文本解析风险
真正难的不是加几行禁用代码，而是找到所有XML解析点——它们可能藏在日志收集模块、SOAP客户端、甚至某个被遗忘的Excel导出工具里。
