现在许多不同的客户端技术，如web端，移动端，云端等使用XML向业务应用程序发送消息。为了使应用程序使用这些自定义的XML消息，应用程序必须去解析XML文档并检查格式是否正确。

本文将描述XML外部实体（XXE）注入攻击及其基础知识，以便更好地了解如何攻击以及如何处理。

既然我们将谈论XXE注入，那么首先我们应该了解外部实体的含义以及实现的内容。

外部实体是指XML处理器必须解析的数据。它对于在多个文档之间创建共享的公共引用很有用。对外部实体进行的任何更改将在包含对其的引用的文档中自动更新。即XML使用外部实体将信息或“内容”将自动提取到XML文档的正文中。

为此，我们需要在XML文档内部声明一个外部实体。我们可以在内部确定其值（内部子集）：

或从外部来源：（外部子集）：

注意到SYSTEM标识符没？该标识符意味着该实体将从外部来源获取内容，在本例中，该内容是“site.com”下的一个页面。

为了声明这些实体，我们需要在文档类型定义（DTD）中进行。DTD是一组标记声明，用于定义XML的文档类型。它定义了XML文档的合法结构块和具有合法元素和属性列表的文档结构。DTD可以在XML文档内部声明，也可以作为外部引用声明—使用SYSTEM标识符指向可解析位置中的另一组声明。

我们来看一个DTD的例子，一个在DTD里面有一个SYSTEM标识符的实体：

最后，最重要的—参数实体！

该类型的实体用“％”字符（或十六进制编码的％）声明，并且仅在经过解析和验证后才用于替换DTD中的文本或其他内容：

XXE攻击概述及其技术

XML外部实体（XXE）攻击是许多基于注入的攻击方式之一，当攻击者将声明XML消息中的外部实体发送到应用程序并使用XML解析器解析时，就会发生这种攻击。

这个漏洞有许多不同的类型和行为，因为它可能会发生在不同类型的技术中—因为不同类型的XML解析器的原因。在这种情况下，令人高兴的是，每个解析器具有不同的功能和“特征”。

在我们开始之前，让我们先认识下可能面临的最常见的XXE漏洞类型—了解这些漏洞类型将有助于我们调试攻击并创建最终正确的POC：

1. 基础的XXE注入— 外部实体注入本地DTD。
2. 基于盲注的XXE注入—XML解析器在响应中不显示任何错误。
3. 基于错误的XXE注入—成功解析之后，XML解析器始终显示SAME响应。（即“您的消息已被接收”），因此，我们可能希望解析器将文件的内容“打印”到错误响应中。

 

按照上一个概述，我们可以通过使用SYSTEM标识符来引用外部实体的数据。所以现在我们可以引入XXE注入的第一种技术，它将外部实体注入到包含引用本地文件路径（如/ etc / passwd）的SYSTEM标识符的XML文档中：

现在让我们做一个更复杂和更严重的攻击：

1. 如果作为通用功能的一部分，应用程序服务器没有作出回应呢？（记得刚刚提到的基于错误的XXE吗？）
2. 如果我们想从其中具有XML特殊字符的外部源读取数据呢？如果在解析过程中解析失败呢？

 

这时我们可以加载引用我们的远程服务器并尝试从其URL获取内容的辅助外部DTD—这可以是一组字符，或下面的示例转储文件，最重要的是它甚至没有经过XML模式验证过程，因为它在解析器甚至获取远程内容之前发送！

例如，远程DTD文件—包含带有SYSTEM标识符和“file”处理程序的参数实体。请注意，参数实体“file”也连接到实体“send”内的URL：

解析DTD后，我们得到以下实体：

最终，服务器会尝试以文件内容发送参数“c”所指定的内容，到达我们定义的URL—我们记录该内容，并通过这样做来转储文件的内容：

步骤A：

步骤B： — 远程DTD正在解析。我们正在窃取文件的内容...

步骤C：

我们成功得到文件内容！

用这种技术记住的几件事情：

• 文件内容中的字符“#”将导致URL截断。
• 如果我们使用“or”定义参数实体，内容可能会中断。

这取决于我们使用的是哪种（所以请确保在出现错误的情况下同时使用这两种测试场景）。

 【原文链接：https://appsec-labs.com/portal/xxe-attacking-guide/  本文由 安全脉搏编辑w2n1ck 翻译，转载请注明“转自安全脉搏”，并附上链接。】

基于错误的XXE注入

有时候，当解析过程成功时，当我们从服务器得到通用的响应时，我们可能希望服务器返回详细错误—因此，我们可以使用与远程DTD相同的技术，但会发生故意的错误如：

解析器将尝试解析DTD并访问发送实体中给出的路径，但是由于不能到达“my-evil-domain。$$$$ ”，我们将导致以下错误：

然后我们就可以根据信息调试我们自己的payload！# 安全脉搏 https://www.secpulse.com/archives/58915.html

请注意，由服务器响应的任何错误显示哪一行导致解析错误，同时出现语法错误，有时我们可能会使用此信息来调试我们自己的payload，使用“\ n”。例如：

<！DOCTYPE Author[ \ n
<！ENTITY %% intentate_error_here“test”>]> \ n

包含payload的两个额外的“\ n”会在第一行“\ n”之后的第2行中出现错误，而其余的XML内容将会显示在第3行。

总之，XXE是一个非常强大的攻击，它允许我们操纵错误的XML解析器并利用它们。请注意，有更多的技术和攻击利用方式可以通过XXE注入完成。如前所述，每个解析器都有不同的能力，因此我们可以提出不同的漏洞：

此表由研究员Timothy Morgan提供—这些协议可用于上传文件（jar:// ..），在旧版本Java中允许任意数据通过TCP连接（gopher:// ..），阅读PHP源代码查看PHP的处理方式。

自己尝试下载我们的演示实验室，可以在这里下载！该演示包含一个带有XML有效载荷的.NET xml解析器和需要的远程DTD文件。

 

有关如何防止XXE攻击的更多信息—请点击这里

安全脉搏历史XXE文章：

1.玩转JSON节点的Content-Type XXE攻击

2.未知攻焉知防——XXE漏洞攻防

3.当Opennms XXE漏洞遇上默认口令(CVE-2015-0975)

4.Oracle数据库XXE注入漏洞(CVE-2014-6577)分析

 

【原文链接：https://appsec-labs.com/portal/xxe-attacking-guide/  本文由 安全脉搏编辑w2n1ck 翻译，转载请注明“转自安全脉搏”，并附上链接。】