微信支付的技术问题之我见——写在微信支付爆出支付惊天漏洞之际

其实这边文章很早就想发布了，但是一直没有进行润色，怕措辞不当引起不必要的误会。但是今天突然就闪电般爆出了微信支付的漏洞，问题出在SDK身上，第三方可以利用XXE虚构支付通知。我其实当时就为微信支付捏着把冷汗。

不管怎样，先把这边笔记贴出来大家参考下。

1. 流程设计问题

APP支付对比支付宝支付就可以知道，微信支付多了一个预付款的服务器流程，就是商户服务器向微信支付服务器申请PrepayID的过程。

其实这个所谓的PrepayID根本就没有什么必要。如果非要从内部技术论证这个PrepayID是如何如何重要，也可以归结为内部偷懒或者部门沟通不畅导致的。

凭空多出的流程，加重了商户服务器的负担，增加了用户响应时间。

2. 签名设计问题

在有这么多成熟非堆成加密/签名算法的今天，微信居然选择了一个对密钥（其实是passphrase）进行md5或者hmac的摘要算法来确保用户的数据是经过授权的。

这种做法导致了两个问题，第一，需要所谓的随机数，第二，最重要的，商户的密钥成为了双方共识（对称）的凭证（否则无法验证摘要数据）。

后面是一个非常大的问题，传统的RSA非对称机制中，通信双方不是对等的。私钥持有方生成的数据，接收方只能验证，无法捏造。而微信这种对等机制中，商户和腾讯都是能够生成原始数据的（因为都拥有密钥）。这样的情况下，如果商户构造一个数据作为接收信息，腾讯在技术上是无法证明这个数据到底是商户捏造的还是腾讯服务器发出的（当然有南山法院在，问题不大）。但为什么不在机制上做得更健壮一些呢，用技术来解决这些潜在的问题呢？

3. 数据格式选择问题

21世纪过去快20年了，用的支付数据是xml格式。xml格式当然牛逼，但是用在支付这种扁平数据的场景上，比json要不方便至少十倍吧。

别告诉我是历史原因，就算历史原因，并行使用两套接口也不是不行。就算舍不得用一个新的版本地址，content-type也是标准的header，可以拿来做区分吧。

4. 接口参数问题

4.1 参数设计冗余随意

这个问题其实和数据格式xml也有点关系。从接口描述来看，xml深度其实就是1层。但是在这一层中出现了这些用来描述结果的字段：

return_code

reutrn_msg

result_code

err_code

err_code_des

就算把mesage、description去掉，还有三个：

return_code

result_code

err_code

你这只管腾讯的工程师方便填写，完全不管接收方如何组织自己的出错处理流程啊。

5. 文档问题

5.1 文档的目录结构随心所欲

根本不是按照逻辑组织的，APP支付又是标题又是章节，下面这个目录结构谁能说是经过仔细斟酌的？

... 有图后面再更新吧。