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”。

<!DOCTYPE results [ <!ENTITY harmless "completely harmless"> ]>

如今，包含这个实体定义的XML文档能够在任何容许的地方引用&harmless;实体。

<?xml version="1.0"?>
<!DOCTYPE results [<!ENTITY harmless "completely harmless">]>
<results>
    <result>This result is &harmless;</result>
</results>

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

This result is completely harmless

无疑，好处是，自定义实体能够用较短的实体名来表明重复的文本和XML。当XML须要遵照特定的语法规范，或者须要自定义实体使编辑更为简单时，这种方法并很多见。可是，考虑到遵照不信任外部输入的原则，咱们要特别当心地对待应用程序中使用的全部XML，辨别它们的真正目的。下面的这个就确定不是无害的输入：

<?xml version="1.0"?>
<!DOCTYPE results [<!ENTITY harmless SYSTEM
"file:///var/www/config.ini">]>
<results>
    <result>&harmless;</result>
</results>

取决于请求的本地文件的内容，某些内容可用于扩充&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注入实例

文件内容和信息泄露

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

<?xml version="1.0"?>
<!DOCTYPE results [<!ENTITY harmless SYSTEM
"file:///var/www/config.ini">]>
<results>
    <result>&harmless;</result>
</results>

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

<?xml version="1.0"?>
<!DOCTYPE results [
    <!ENTITY harmless SYSTEM
    "php://filter/read=convert.base64-encode/resource=/var/www/config.ini"
    >
]>
<results>
    <result>&harmless;</result>
</results>

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。

<?xml version="1.0"?>
<!DOCTYPE results [
    <!ENTITY harmless SYSTEM
    "php://filter/read=convert.base64-encode/resource=http://example.com/viewlog.php"
    >
]>
<results>
    <result>&harmless;</result>
</results>

若是只有本地请求能够查看日志，攻击者就能够成功获取日志。一样的思路也适用于只接受本地请求的维护和管理接口。

拒绝服务（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("/<!DOCTYPE/i", $collapsedXml)) {
    throw new \InvalidArgumentException(
        'Invalid XML: Detected use of illegal DOCTYPE'
    );
}

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

原文地址：Injection Attacks

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

本文转自 OneAPM 官方博客