XML作为一种历史悠久的数据交换格式，至今仍广泛出现在Web服务、配置文件和办公文档中。看似普通的解析动作，如果交给未经安全配置的解析器处理不可信输入，就可能引发外部实体注入、拒绝服务和远程代码执行等严重问题。理解解析器在底层如何处理实体与文档类型定义，是构建安全防线的基础。
一、XML解析面临的主要安全风险
最常见的威胁是XML外部实体注入，也就是常说的XXE。当解析器允许引用外部实体时，攻击者可以在XML中声明一个指向本地文件或内部网络的实体，解析过程中系统会替他把内容取回来并回显到响应里。比如下面这段恶意XML，就试图读取Linux系统的密码文件：
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <foo>&xxe;</foo>
除了信息泄露，攻击者还会利用实体膨胀发起拒绝服务攻击。通过在DTD中定义相互嵌套的实体，短短几百字节的输入在解析时会被展开成几十亿个字符，迅速耗尽服务器内存。另一种隐患来自XSLT转换，如果解析链路中允许用户提供样式表，且解析器未限制扩展函数，就可能执行系统命令。
很多语言标准库默认追求功能完整而非安全，因此上述特性往往是开启状态。开发者若直接拿默认解析器处理外部数据，等于把系统资源的钥匙交了出去。认清这些风险点，才能有针对性地去关闭危险开关。
二、通用安全配置原则
无论使用哪种语言，安全解析XML的核心思路是一致的：禁止外部实体、禁用或不信任DTD、限制输入规模、校验结构合法性。外部实体是XXE的载体，必须彻底关闭；DTD虽然有一定校验作用，但也是实体攻击的入口，对不可信数据应当直接拒绝带DOCTYPE的文档。
输入体积限制能缓解实体膨胀类攻击，可以在读取流之前检查Content-Length，或在解析时设置内存上限。Schema校验则确保数据符合业务预期，避免解析器处理意料之外的节点。下面以Java为例，看看如何把这些原则落到代码上。
Java中DocumentBuilderFactory的安全初始化
Java自带的DOM解析器默认允许外部实体，需要手动设置多个特性来加固。以下代码展示了安全的创建方式：
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.DocumentBuilder;
public class SafeXmlParser {
public static DocumentBuilder newSafeBuilder() throws Exception {
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
// 禁用外部实体
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);
// 关闭XML外部DTD的加载
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);
return dbf.newDocumentBuilder();
}
}
上面最关键的一行是disallow-doctype-decl设为true，它直接禁止文档中出现DOCTYPE，从源头掐断实体声明。如果业务必须使用DTD做校验，则应退而求其次，仅关闭外部实体并配合白名单校验，但风险会相应升高。
这种配置方式的优点是改动集中、易于封装成统一工具类；缺点是不同JDK版本对特性字符串的支持略有差异，需要在目标环境做冒烟测试。团队应把该方法纳入基础组件，避免业务代码各自创建解析器。
Python中xml.etree的安全处理
Python标准库的xml.etree.ElementTree在较新版本中默认不展开外部实体，但使用lxml等第三方库时仍需显式配置。下面是基于lxml的防御示例：
from lxml import etree
def parse_safe(xml_bytes):
parser = etree.XMLParser(
resolve_entities=False,
no_network=True,
dtd_validation=False,
load_dtd=False
)
return etree.fromstring(xml_bytes, parser)
resolve_entities设为False让解析器不去展开任何实体引用，no_network禁止网络访问，load_dtd关闭DTD加载。这样即便输入包含实体声明，也只会当作普通文本节点，不会触发资源读取。
相比Java需要记特性名，lxml的参数语义更直观。但要注意如果用了etree.parse直接读文件而未传parser，仍会走默认配置，因此必须保证入口统一。
三、进阶防护与架构建议
在代码层之外，还应在系统边界做纵深防御。比如网关层对超过特定大小的XML请求直接拒绝，WAF规则匹配DOCTYPE与ENTITY关键字。对于必须支持复杂XML的场景，可引入专用解析服务，将解析过程隔离在低权限容器中，即便被突破也不影响主系统。
另一个常被忽略的点是依赖库版本。许多XML相关漏洞出自底层C库如libxml2，应及时跟随操作系统或语言运行时打补丁。下面用表格对比几种常见解析方案的安全表现：
| 解析方式 | 外部实体默认 | 防御要点 |
|---|---|---|
| Java DOM默认 | 开启 | 禁用DOCTYPE与实体 |
| Python lxml默认 | 视配置 | resolve_entities=False |
| SAX流式解析 | 可配置 | 重写EntityResolver返回空 |
流式解析如SAX适合大文件，通过重写EntityResolver可以拦截一切实体请求。但它要求开发者写更多回调代码，出错概率也更高，适合对性能敏感且团队经验丰富的项目。
总体而言，XML解析安全不是单点开关，而是从选型、配置、输入控制到依赖维护的一连串动作。把安全解析器封装为组织内唯一入口，配合边界限流与监控，才能稳健地消化外部XML数据。