Injection Attacks-XML注入

注入攻击

XML注入

虽然JSON的出现实现了服务器与客户端之间的“轻量级”数据交流，但是，作为另一种流行的可行方案，许多web服务API同时还是继续支持XML。另外，除了web服务之外，XML也是许多使用XML schemas 实行数据交换的协议的基础，例如RSS，Atom，SOAP，以及RDF等等，举不胜举。

XML无处不在：它存在于web应用的服务器中，或者在浏览器中作为XMLHttpRequest的请求和应答的格式，亦或在浏览器的扩展程序中。由于应用广泛，XML成为了吸引注入攻击的目标。它受众广，同时常用的XML解析器，例如libxml2，允许对XML进行一些默认处理。libxml2常在DOM、SimpleXML和XMLReader扩展中的PHP中使用。当浏览器的XML交换很频繁时，我们要考虑到，XML作为请求格式时，就算是认证用户，也有可能正通过跨站脚本攻击发送攻击者所编写的XML。

XML外部实体注入攻击

面对XML外部实体攻击（XXE）的脆弱点在于，XML解析器的库往往都支持自定义的XML实体引用。你应该熟悉，XML拥有表示>、<和&apos 等特殊标记字符的实体，作为对一般实体的标准补充。同时XML允许用户在XML文档内自定义实体，以此来扩展其标准实体集。这些自定义实体可以直接写在可选的DOCTYPE中，而它们代表的扩展值则可引用一个外部资源。正是普通XML的这种支持自定义引用、可引用外部资源内容的可扩展性，导致系统易受XXE的攻击。通常，我们的系统绝不应当允许不受信任的输入以无法预期的方式参与到系统交互中来，同时绝大大多数程序开发人员都不会考虑到XXE。因此值得我们特别注意。

例如，让我们来试着定义一个新的自定义实体“harmless”。

 ]>

现在，包含这个实体定义的XML文档可以在任何允许的地方引用&harmless;实体。

]>

    This result is &harmless;
 

XML解析器，例如PHP DOM，在解析这段XML时，会在加载完文档后立即处理这个自定义实体。因此，请求相关文本时，会得到如下的返回：

This result is completely harmless

无疑，好处是，自定义实体可以用较短的实体名来代表重复的文本和XML。当XML需要遵守特定的语法规范，或者需要自定义实体使编辑更为简单时，这种方法并不少见。但是，考虑到遵守不信任外部输入的原则，我们要特别小心地对待应用程序中使用的所有XML，辨别它们的真正目的。下面的这个就肯定不是无害的输入：

]>

    &harmless;

取决于请求的本地文件的内容，某些内容可用于扩充&harmless;实体，这些内容可以从XML解析器中提取出来，包含在web应用的输出中，攻击者看到它们，即会造成信息泄露。获取的文件将会被解析成XML，除非避开某些可以触发解析的特殊字符，而这限制了泄露的范围。如果文件被解析为XML但并不包含有效的XML内容，系统会报错，这样一来可以避免内容泄露。但是，PHP中有一个巧妙的“技俩”，可以绕过这种范围的限制，既使得攻击者接收不到应答，远程HTTP请求却仍然可以影响web应用。

PHP有三种常用的方法，用来解析和使用XML：PHP DOM、SimpleXML，以及XMLReader。这三种方法都需要使用libxml2扩展，也默认启用外部实体支持。这种默认设置导致PHP在XXE面前很脆弱，而我们在考虑web应用或XML应用库的安全性时，很容易疏忽这一点。

你也知道，XHTML和HTML5都可以被序列化为有效的XML，也就是说，某些XHTML页面和被序列化的HTML5可以被解析为XML，例如，使用DOMDocument::loadXML()，而不是DOMDocument::loadHTML()时。这种XML解析方法在XEE注入的面前也很脆弱。注意，与XHTML DOCTYPES不同，libxml2目前甚至无法识别HTML5 DOCTYPE，因此无法让其成为有效的XML。

XXE注入实例

文件内容和信息泄露

在早前的一个信息泄露的例子中，我们注意到自定义实体可能引用一个外部文件。

]>

    &harmless;

这会把文件内容扩展到自定义的&harmless;实体中。由于所有类似的请求都是在本地完成的，这使得该应用有权限读取的所有文件内容都可能被泄露。只要应用的输出中包含了这个扩展了的实体，攻击者就可以查看那些文件，包括没有公开的文件。因这种方式而造成内容泄露的文件是相当有限的，只能是XML文件，和不会造成XML解析错误的文件。但是，PHP可以完全忽略这种限制。

 

]>

    &harmless;

PHP允许通过URI访问PHP wrapper，这是一般文件系统函数，如file_get_contents()、require()、require_once()、file()、和copy()等，接受的协议之一。PHP wrapper支持一些过滤器，这些过滤器运行在给定的资源上，结果可以通过函数调用返回。在上述例子中，我们对想要读取的目标文件使用了convert.base-64-encode过滤器。

这意味着，攻击者通过利用XXE的脆弱性，可以用PHP读取任何可读的文件，不论文本格式如何。攻击者只需用base64将应用输出解码，就可以毫无顾忌的分析一大堆非公开文件的内容。尽管这本身不会直接伤害终端用户或是应用后台，但是它能让攻击者了解目标应用，从而以最小的代价、最低的风险发现应用的其他弱点。

绕过访问控制

访问控制可以通过各种方法来实现。由于XXE攻击是挂在web应用后台的，它无法使用当前用户会话产生任何影响，但是攻击者仍然可以借助从本地服务器发送请求，来绕过后台访问控制。我们来看一下下面这个简单的访问控制：

if (isset($_SERVER['HTTP_CLIENT_IP'])
    || isset($_SERVER['HTTP_X_FORWARDED_FOR'])
    || !in_array(@$_SERVER['REMOTE_ADDR'], array(
        '127.0.0.1',
        '::1',
    ))
) {
    header('HTTP/1.0 403 Forbidden');
    exit(
        'You are not allowed to access this file.'
    );
}

这段PHP和无数的类似代码都用于限制特定PHP文件对本地服务器的访问，如 localhost。但是，应用前端的XXE脆弱性，正好为攻击者提供了绕过访问控制所需的凭证，因为XML解析器发出的所有HTTP请求都来自localhost。

]>

    &harmless;

如果只有本地请求可以查看日志，攻击者就可以成功获取日志。同样的思路也适用于只接受本地请求的维护和管理接口。

拒绝服务（DOS）

几乎所有可以控制服务器资源利用的东西，都可用于制造DOS攻击。通过XML外部实体注入，攻击者可以发送任意的HTTP请求，从而在恰当的时候耗尽服务器资源。

下文中还有一些其他的例子，通过XML实体扩展造成XXE攻击，从而制造潜在的DOS攻击。

抵御XML外部实体注入

这类攻击十分“诱人“，但对它的防御也简单的出奇。既然DOM、SimpleXML和XMLReader依赖于libxml2，我们可以简单地利用libxml_disable_entity_loader()函数来禁止外部实体引用。与此同时，DOCTYPE中预定义的自定义实体却不会受到影响，因为它们并没有使用任何需要文件系统操作或发送HTTP请求的外部资源。

$oldValue = libxml_disable_entity_loader(true);
$dom = new DOMDocument();
$dom->loadXML($xml);
libxml_disable_entity_loader($oldValue);

在所有涉及通过字符串、文件或者远程URI来加载XML时，都需要使用这些操作。

当应用程序及其大部分请求都不需要外部实体时，你可以简单地从全局禁掉外部资源加载。大多数时候，这比找出所有的XML加载实例来逐个操作要更好。记住，许多库天生自带XEE脆弱性：

libxml_disable_entity_loader(true);

每次需要临时允许加载外部资源时，加载完后切记再把这里设为TRUE。例如，在将Docbook XML转换为HTML时，所使用的XSL样式就是依赖于外部实体的，这里需要外部实体，但是是无害的。

但是，libxml2函数绝不是"万能钥匙"。我们需要确认，其他用于解析或处理XML的扩展和PHP库的引用外部实体的功能，都处于关掉状态。

如果不能通过上述方法来开关外部实体引用，你还可以检查一下XML文档是否声明了DOCTYPE。如果声明了，同时禁掉了外部实体，则可以简单地丢弃XML文档，拒绝可能造成解析器脆弱性的不受信任的XML访问，同时将这种行为记录为一次可能的攻击。我们需要将这种行为记录下来，因为除此之外不会有任何系统报错记录。可以在日常输入验证中进行这项检查。但是，这种方法并不理想，笔者还是强烈建议从源头上解决外部实体的问题。

/**
 * Attempt a quickie detection
 */
$collapsedXML = preg_replace("/[:space:]/", '', $xml);
if(preg_match("/

同时，值得注意的是，当我们怀疑一段数据有可能是某个攻击的结果时，最好的方法是丢弃它，而不是继续使用它。既然它已经表现出了危险，为什么还要继续使用它呢？因此，将上述两个步骤合并起来，我们可以在无法丢弃数据时（例如第三方的库），通过主动跳过坏数据起到保护作用。之所以我们更愿意完全丢弃这些数据，还因为上文提到过的一个理由：libxml_disable_entity_loader()不会将自定义实体完全禁掉，只有引用外部资源的才会被禁掉。因此这仍有可能导致一个被称为XML实体扩展的注入攻击。在下文中我们会提到这种攻击。

原文地址：Injection Attacks

本文系 OneAPM 工程师编译整理。OneAPM 是应用性能管理领域的新兴领军企业，能帮助企业用户和开发者轻松实现：缓慢的程序代码和 SQL 语句的实时抓取。想阅读更多技术文章，请访问 OneAPM 官方博客。

本文转自 OneAPM 官方博客