最近在使用某个第三方提供的支付 sdk 开发的时候,发现一个问题,可能造成支付结果伪造。目前漏洞已经修复。

整个的流程大致是这样的,你的前端(app 或者网页)将姓名地址手机等订单信息发送到服务器,服务器创建订单,然后使用这个订单号创建一个该 sdk 的 charge 对象,返回给前端,sdk 会使用这个 charge 对象调用支付宝等进行支付。等待用户支付完成后,sdk的服务器会向你的一个异步通知 notify_url 推送消息,然后服务器根据消息里面的订单号和支付结果修改付款状态。其实这个和支付宝等官方的 sdk 流程没什么大的区别,只是帮助封装了一些加密解密的操作。

因为这异步通知的消息格式是确定的,字段的值是全部可预测的的(因为在 charge 对象里面都能看到),所以我们能不能伪造这个异步通知结果呢,这样的话,就能不付款买东西了。

但是问题来了,这个异步通知的 url 我们是不知道的。怎么才能获取到呢?其实是在一个 ajax 请求中泄露的。

登录管理控制台,链接是这个形式的,https://xxxx.com/app/detail?app_id=app_****,后面就是我的 app_id,而这个在前端和服务器交互数据中可以看到的。把我的 app_id 换成别人的,结果发现点击哪里都是显示应用不存在,但是使用浏览器开发者工具能看到一个 ajax 请求,https://xxxx.com/auto/app?app_id=***,返回结果确实是那个 app_id 的,里面就是包含 notify_url。

这样,将前面获取的订单号,app_id 等等直接构造一个 charge 对象,post 到那个 notify_url 就好了。服务器返回” success” 的话,就表明已经收到消息。

分析这个漏洞,sdk开发者和用户都有责任。

首先,sdk 开发者应该指导用户正确的去校验消息和确认支付状态。目前没有签名等校验方法,只能拿订单号再去查询一遍。而绝大多数的用户没有考虑的这么多,收到了通知就修改了订单状态。

翻了翻支付宝的文档,在 wap 版本中,它的异步通知 url 是每次自定义的,而且是不公开的。大致的流程是使用交易服务器使用订单号等换取一个 token,然后将 token 传递给前端。它的每次请求都有签名的,RSA 或者 MD5,RSA 的数据都是加密的,需要用自己的私钥解密后才能看到内容。MD5的那个是明文数据,MD5校验值是数据的一部分。这个时候,如果用户选择了 RSA 签名,基本上消息不能伪造了,因为在不泄露的情况下你不知道用户私钥(当然前面不泄露 notify_url 也不能伪造结果),就没办法去加密数据。MD5的话,只能自己去验证签名了,因为 MD5 的时候加入了用户私钥。

用户在使用的时候我觉得是最安全的方法是:

为什么说注意不同平台之间差异呢,因为后台给使用这个支付服务的 app 抓包的时候,发现上面提到的有些信息并不完全是未知的。app支付的流程并不一样,上面流程中使用订单号换取 token 的步骤没了,而是直接将数据传递给 app,这个时候 notify_url 也是公开的了。所以还是需要服务器校验。

在上面看了几个支付宝的文档,网页版的和 app 版本的应该不是一个团队写的,风格、加密方式等等都不一样。真心蛋疼。。。