《缺陷周话》第四期：XML外部实体注入

代码审计是使用静态分析发现源代码中安全缺陷的方法，能够辅助开发或测试人员在软件上线前较为全面地了解其安全问题，防患于未然，因此一直以来都是学术界和产业界研究的热点，并且已经成为安全开发生命周期 SDL 和 DevSecOps 等保障体系的重要技术手段。

360代码卫士团队基于自主研发的国内首款源代码安全检测商用工具，以及十余年漏洞技术研究的积累，推出“缺陷周话”系列栏目。每周针对 CWE、OWASP 等标准中的一类缺陷，结合实例和 工具 使用进行详细介绍，旨在为广大开发和安全人员提供代码审计的基础性标准化教程。

一、XML外部实体注入

XML 外部实体注入漏洞也就是我们常说的 XXE 漏洞。XML 作为一种使用较为广泛的数据传输格式，很多应用程序都包含有处理 xml 数据的代码，默认情况下，许多过时的或配置不当的 XML 处理器都会对外部实体进行引用。

如果攻击者可以上传 XML 文档或者在 XML 文档中添加恶意内容，通过易受攻击的代码、依赖项或集成，就能够攻击包含缺陷的XML处理器。XXE 漏洞的出现和开发语言无关，只要是应用程序中对 xml 数据做了解析，而这些数据又受用户控制，那么应用程序都可能受到 XXE 攻击。本篇文章以 java 程序为例给大家介绍 XXE 漏洞的成因及修复。XXE 漏洞详细请见 CWE-611: Improper Restriction of XML External Entity Reference (‘XXE’)( http://cwe.mitre.org/data/definitions/611.html )。

二、XML外部实体注入

XXE 漏洞可能会用于提取数据、执行远程服务器请求、扫描内部系统、执行拒绝服务攻击和其他攻击。业务影响主要取决于受影响的引用程序和数据保护需求。

2018年至今，CVE 中共有发布了 92 条漏洞信息与其相关。部分CVE如下：

三、示例代码

3.1 缺陷代码

本节使用示例代码来源为某开源支付 Java  SDK ( https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=11_1 )，源文件名：WXPayUtil.java，文件路径为：java-sdk-v3\src\main\java\com\github\wxpay\sdk。 

在上述代码可以看到在25行处数据通过 xmlToMap 形参传入，数据未做任何过滤，且 XML 处理器也未做安全设置就在32行处对数据做了解析，而实际场景中，参数 strXML 也是受攻击者控制的，这样攻击者可能通过构造恶意的  strXML 来进行 XXE 攻击。

使用360代码卫士对上述示例代码进行检测，可以在文件第32行检出“有风险的XML外部实体注入”缺陷。如图1所示：

图1   检测出有风险的XML外部实体注入

3.2 修复代码

在上述修复代码中的第28行使用的是一个xml工具类WXPayXmlUtil，用于生成一个安全的xml处理器。而 WXPayXmlUtil 类中最为关键的是第16行，通过 setFeature 让生成的 xml 处理器完全禁用 DTDS。通过图2可以看出，360代码卫士对修复后的代码并未检出缺陷。

图2   XXE漏洞修复示例

四、如何避免XXE漏洞

常见的避免方法：

1. 尽可能使用简单的数据格式（如：JSON），避免对敏感数据进行序列化；

2. 及时修复或更新应用程序或底层操作系统使用的所有XML处理器和库。同时，通过依赖项检测，将SOAP更新到1.2版本或更高版本；

3. 在应用程序的所有XML解析器中禁用XML外部实体和DTD进程，具体实现可以参考《OWASP Cheat Sheet ‘XXE Prevention’》( https://www.owasp.org/index.php/XML_External_Entity_ (XXE)_Prevention_Cheat_Sheet)

如下代码是java应用程序中使用DocumentBuilderFactory解析xml时防范XXE漏洞的示例：

4. 输入校验：在服务器端使用白名单进行输入验证和过滤，以防在XML文档、标题或节点中出现恶意数据。

5. 验证XML和XSL文件上传功能是否使用XSD验证或其他类似验证的方法来验证上传的XML文件

6. DAST工具需要额外的手动步骤来检查和利用XXE漏洞，而使用ASAT工具可以通过检测依赖项和安全配置来发现XXE漏洞。

*本文作者：360 代码卫士，转载请注明来自 FreeBuf.COM