一、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如下：
cve-2018-8027apache camel 2.20.0 到 2.20.3 和2.21.0 core 在 xsd 验证处理器中存在 xxe 漏洞。
cve-2018-13439 微信支付 java sdk 中的 wxpayutil 类中存在xxe漏洞。
cve-2018-1000548 在版本号小于 14.3 的 umlet 中，在文件解析中存在xml外部实体注入漏洞，可能导致机密数据泄露、拒绝服务、服务器端请求伪造。此攻击可以通过特制的 uxf 文件进行攻击。
cve-2018-1364
ibm content bavigator 2.0 和 3.0 版本中在处理xml数据时，易受xml外部实体（xxe）攻击。远程攻击者可以利用此漏洞暴露敏感信息或占用内存资源。
三、示例代码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漏洞。
以上就是xml外部实体注入漏洞的示例分析的详细内容。