其實這邊文章很早就想發佈了，但是一直沒有進行潤色，怕措辭不當引起不必要的誤會。但是今天突然就閃電般爆出了微信支付的漏洞，問題出在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支付又是標題又是章節，下面這個目錄結構誰能說是經過仔細斟酌的？
... 有圖後面再更新吧。