文章总结： 本文剖析了XML外部实体注入（XXE）漏洞的原理。文章阐述了攻击者如何利用解析器读取文件、发起SSRF或实施拒绝服务。文中指出了XXE在SOAP、SAML及文件上传中的常见位置。防御方面，强调了禁用DTD处理和外部实体解析、使用安全解析库等关键措施。 综合评分： 88 文章分类： 渗透测试,WEB安全,漏洞分析,安全开发

0127.XML 中隐藏的危险：深入剖析 XXE 注入，助力现代渗透测试人员。

原创

Fuzzyy Duck Fuzzyy Duck

Rsec

2026年2月9日 17:31 贵州

本文章仅用网络安全研究学习，请勿使用相关技术进行违法犯罪活动。

声明：本文搬运自互联网，如你是原作者，请联系我们！

类型：XXE

如果您曾测试过 API、遗留企业系统或身份验证工作流程，您可能已经注意到 XML 在后台默默运行。虽然 JSON 在现代 Web 应用中占据主导地位，但 XML 仍然是单点登录、支付集成、文档处理管道和移动后端服务等关键基础设施的基石。

由于它通常存在于较旧或更新频率较低的组件中，因此很容易成为高危漏洞的攻击目标。其中最危险的漏洞之一是 XML 外部实体注入，通常称为 XXE。

本文从 XML 的基本原理入手，解释了 XXE 的内部工作原理，展示了解析器内部实际发生的情况，然后深入探讨了现实世界的利用场景、攻击向量和工程级预防策略。

了解 XML：它存在的意义以及它为何至今仍然重要

XML 是可扩展标记语言的缩写。它的设计初衷是用于以人机可读的格式存储和传输结构化数据。在 JSON 成为 Web API 的默认标准之前，XML 是企业通信的通用标准。

一个简单的 XML 文档如下所示：

与 HTML 不同，XML 没有预定义的标签。开发者需要根据应用场景自定义结构。这种灵活性固然强大，但也带来了复杂性。从安全角度来看，XML 最重要的特性是能够定义文档类型定义（DTD）。

DTD（文档类型定义）允许开发人员定义文档结构和称为实体的可重用变量。XXE 漏洞正是源于这些实体。

实体：一项从功能演变成安全噩梦的机制

#

XML 中的实体类似于变量或宏，它允许在整个文档中重复使用值。

内部实体看起来无害：

但是 XML 也支持外部实体，允许解析器从文档外部加载内容：

这指示 XML 解析器从服务器文件系统中读取一个文件，并在解析过程中将其内容插入到 XML 文档中。此功能最初是为了实现模块化文档重用而设计的。然而，当攻击者控制实体定义时，他们可以强制服务器读取文件、发起网络请求或耗尽系统资源。

XXE 的真正含义

#

XXE 不仅仅是“注入 XML”，它还滥用了 XML 解析器解析外部实体的方式。当四个条件同时满足时，该漏洞就会出现：应用程序接受 XML 输入、解析器处理 DTD、启用了外部实体解析，并且攻击者可以修改 XML 内容。

当所有这些条件都存在时，XML 解析器就成了文件系统访问和网络通信的非预期代理。

XXE 攻击期间服务器内部会发生什么

#

要深入理解 XXE，你必须像 XML 解析器一样思考。

假设某个应用程序收到以下请求：

首先，应用程序接收到 Content-Type 设置为 application/xml 的 HTTP 请求。请求体被传递给 XML 解析器库。解析器识别 DOCTYPE 声明并加载 DTD 指令。它注册名为 xxe 的实体，并将其与本地文件路径关联起来。

当解析器遇到实体引用 &xxe; 时，它会暂停正常的处理过程并解析该实体。这意味着打开文件，读取其内容，并将其直接插入到 XML 结构中，然后再将最终解析后的文档返回给应用程序。

从应用程序的角度来看，它根本看不到实体引用，只能看到展开后的结果。这就是为什么 XXE 通常会绕过应用程序级别的输入验证。

攻击者利用 XXE 能做到什么

#

最常见且最可靠的结果是本地文件泄露。攻击者会瞄准配置文件、环境变量、SSH 密钥和应用程序密钥。在容器化环境中，这可能包括 Kubernetes 令牌或内部服务凭证。

利用 XXE 漏洞检索文件

服务器端请求伪造是另一种强大的攻击手段。由于解析器可以获取远程资源，攻击者可以强制服务器向未对外暴露的内部服务发出请求。这在云环境中尤其危险，因为元数据端点会存储临时凭据。

利用 XXE 进行 SSRF 攻击

在更高级的攻击场景中，攻击者会使用带外数据窃取技术。即使应用程序不在 HTTP 响应中返回文件内容，解析器也可能被诱骗向攻击者控制的服务器发送数据。

带外 XXE

通过实体扩展攻击（例如 Billion Laughs 攻击）也可以发起拒绝服务攻击，其中嵌套的实体引用会消耗大量的内存和 CPU。

十亿次笑声攻击

在这里查看所有类型和有效载荷。

XXE payload

https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XXE%20Injection/README.md

XXE 至今仍然存在的原因

#

许多开发者认为现代框架会自动防止 XXE 漏洞。虽然对于新库来说通常如此，但遗留系统仍然随处可见。企业级 SOAP 服务、旧版 Java 集成、过时的文档处理工具以及被遗忘的内部 API 通常都使用不安全的默认解析器。

另一个主要原因是直接从旧文档或论坛复制粘贴配置代码。XML 安全设置通常很微妙，很容易配置错误。

XXE 在现实世界中的藏身之处

#

XXE 漏洞常见于 SOAP Web 服务中，尤其是在请求使用 Content-Type text/xml 时。SAML 身份验证流程是另一个常见漏洞来源，因为它们严重依赖 XML 解析和签名验证。文件上传功能也是一个容易被忽视的漏洞，特别是当应用程序接受 SVG、DOCX 或其他基于 XML 的格式并在服务器端解析它们时。

移动应用也值得关注。许多企业移动应用使用 XML 与后端系统通信，尤其是在较老的金融和电信生态系统中。

集成端点尤其危险，因为它们通常不如公共 API 那样受到监控和维护。

渗透测试人员应积极尝试的攻击向量

#

直接使用 XML 请求体是最明显的攻击途径。然而，文件上传往往效果更好，因为开发者很少会预期文件内容中包含 XML 有效负载。内容类型切换是另一种有效的技巧，即用 XML 输入测试预期接收 JSON 的端点。

移动应用流量拦截通常会揭示隐藏的 XML 端点。测试过程中发现的遗留内部 API 也是高价值的 XXE 攻击目标。

#

从工程角度看预防

#

最有效的防御措施是完全禁用 DTD 处理。如果应用程序不需要 DTD，则绝对不应该启用它们。此外，还应在解析器配置中显式禁用外部实体解析。

应始终使用现代的安全解析器库。输入验证虽然有用，但绝不应作为主要防御手段，因为实体扩展发生在应用程序逻辑执行之前。

网络层面的控制措施也有助于降低影响。如果应用服务器无法访问内部元数据服务或外部互联网资源，那么通过 XXE 进行的 SSRF 攻击的危险性就会大大降低。

最后想说的话

#

XML 或许看起来像是过时的技术，但它仍然是互联网关键部分的运行基础。XXE 就存在于传统设计决策与现代攻击手段的交汇点。了解 XML 解析器的内部工作原理能让你作为渗透测试人员获得巨大优势，因为你不再仅仅将 XML 视为另一种数据格式，而是将其视为一个可编程的执行层。

如果你测试足够多的企业级或集成密集型环境，最终会遇到 XML。而当你遇到 XML 时，总值得问一个问题：解析器是否过于信任我？

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：Rsec Fuzzyy Duck Fuzzyy Duck《0127.XML 中隐藏的危险：深入剖析 XXE 注入，助力现代渗透测试人员。》