四、扩展与反思

1.  危害不只是“0元也能买买买”

在很多媒体的报道中，强调该漏洞的风险在于攻击者可以不支付也可以获得商品。确实，攻击者在通过上述漏洞获得微信支付的秘钥以后，有不止一种途径可以做到不支付就获得商品：例如，攻击者首先在系统中下单，获得商户订单号；然后便可以调用微信支付的异步回调，其中的签名参数便可以使用前面获取的秘钥对订单号等信息进行MD5获得；这样攻击者的异步回调就可以通过应用服务器的签名认证，从而获得商品。不过，在很多有一定规模的购物网站（或其他有支付功能的网站），会有对账系统，如定时将系统中的订单状态与微信、支付宝的后台对比，如果出现不一致可以及时报警并处理，因此该漏洞在这方面的影响可能并没有想象的那么大。

然而，除了“0元也能买买买”，攻击者可以做的事情还有很多很多；理论上来说，攻击者可能获得应用服务器上的目录结构、代码、数据、配置文件等，可以根据需要进行进一步破坏。

2.  漏洞不限于微信支付SDK

虽然微信支付曝出该漏洞受到了广泛关注，但该漏洞绝不仅仅存在于微信支付中：由于众多XML解析器默认不会禁用对外部实体的访问，因此应用的接口如果有以下几个特点就很容易掉进XXE漏洞的坑里：

（1）接口使用xml做请求参数

（2）接口对外公开，或容易获得：例如一些接口提供给外部客户调用，或者接口使用http很容易抓包，或者接口比较容易猜到(如微信支付的异步回调接口)

（3）接口中解析xml参数时，没有禁用对外部实体的访问

建议大家最好检查一下自己的应用中是否有类似的漏洞，及时修复。

3.  xml与json

xml 与 json是系统间交互常用的两种数据格式，虽然很多情况下二者可以互换，但是笔者认为，json 作为更加轻量级更加纯粹的数据格式，更适合于系统间的交互；而xml，作为更加重量级更加复杂的数据格式，其 DTD 支持自定义文档类型，在更加复杂的配置场景下有着更好的效果，典型的场景如 spring 相关的配置。

4.  题外话：微信支付的签名认证

在前面曾经提到，应用中存储的秘钥一旦泄露，攻击者便可以完全绕过签名认证，这是因为微信支付使用的是对称式的签名认证：微信方和应用方，使用相同的秘钥对相同的明文进行MD5签名，只要应用方的秘钥泄露，签名认证就完全成了摆设。

在这方面支付宝的做法更规范也更安全：支付宝为应用生成公私钥对，公钥由应用方保存，私钥由支付宝保存；在回调时，支付宝使用私钥进行签名，应用方使用公钥进行验证；这样只要支付宝保存的私钥不泄露，攻击者只有公钥则难以通过签名认证。

参考文献

• https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=23_5
• http://seclists.org/fulldisclosure/2018/Jul/3
• https://www.cnblogs.com/tongwen/p/5194483.html