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

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

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

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

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

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

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

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

3. 数据格式选择问题

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

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

4.1 参数设计冗余随意

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

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

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

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

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