在線支付已經走進每個人的生活。搶紅包、網上購物、生活繳費等服務中處處都有在線支付的身影。但是在線支付體系暴露過許多次安全問題，黑客利用在線支付的漏洞可以悄無聲息的免費清空購物車等，造成商戶和支付平臺的損失。由於種種原因，支付平臺的安全問題很少被細緻公開的討論過。
本文由2015年支付寶安全特別獎得主丁羽和黎桐辛，以及韋韜共同撰寫。其中丁羽和韋韜來自百度X-Lab，黎桐辛來自北京大學。文章對在線支付體系的原理進行了介紹，並分享了幾個在線支付過程中曾出現的嚴重漏洞以及利用過程。希望這些經驗能引起相關廠家和商戶的重視，使我們的在線支付更加安全。
引言
電子商務已經成爲當今互聯網中重要的組成部分。同時“錢包”類服務成爲了電子商務的關鍵組件。越來越多的電商服務通過“錢包”服務來進行支付。“錢包”提供的接口簡單易用，任何一個開發者都可以快速的將“錢包”服務供應商提供的SDK整合進自己的App中，提供App內的快速支付手段。目前國內最大的“錢包”類服務包括：支付寶錢包、微信錢包、百度錢包等，各有長處。
因此，支付過程的安全問題也成爲了關鍵。如果錢包服務出現了安全漏洞，那麼很可能會影響到成千上萬的商家，數十億的現金流，後果往往非常嚴重。對於支付平臺的安全研究自從其誕生之日起就開始了。經過數次血的教訓，幾大支付平臺均修正了數個大大小小的漏洞，反覆改進設計和實現。現今的支付平臺已經相當安全可靠。
本文對藉助支付平臺進行的支付流程進行分析，對支付平臺的安全進行討論。同時我們展示了商戶端和支付平臺出現過的幾個嚴重安全漏洞。攻擊者通過這幾個安全漏洞可以達到修改金額、任意購買等效果，使得支付平臺和商戶的利益收到巨大損失。本文中涉及的安全漏洞均已得到修正。
支付流程概述
目前市場上的大大小小的第三方支付平臺有許多家，規模有大有小但是從整個支付流程上看這些支付平臺的同質化程度很高。只有少數很大的支付平臺做出了比較大的改動，進一步增強了安全性。這一節我們對支付平臺普遍採用的支付協議做下介紹。
在支付流程中主要包括四個實體：商戶前端、商家服務器、錢包模塊、以及錢包服務器。商戶前端是用戶直接交互的部分，用戶通過操作商戶前端來購買商品等。這裏商戶前端不僅限於移動設備上安裝的App，也可以是商家提供的網站。商家服務器是商戶的後端，提供相應的服務。錢包模塊是進行支付的“中介”，如支付寶、微信錢包、百度錢包等都有對應的支付模塊。
通常支付模塊可以是用戶App中的一個SDK，與商戶App一起安裝在用戶的手機上。支付模塊也可以以web的形式提供服務。錢包服務器負責處理支付請求，並通知商家服務器支付結果。錢包服務需要與錢包模塊交互以獲得訂單信息，同時需要與相關的機構（例如銀行）進行扣款處理，最後與商家服務和錢包模塊進行通訊以通知支付結果。因此整個支付過程是一個"四方通訊"的過程。一筆成功交易的後面通常包含四方之間數十次的複雜交互，任何一個環節的安全隱患都會擴大整個支付過程的攻擊面。多個安全隱患的疊加可能使得攻擊者可以進行訂單篡改等攻擊，使用戶、商戶、錢包服務的利益收到損失。
一個完整的經由支付平臺的支付過程通常可以劃分爲以下幾步：
1. 商戶前端對錢包初始化
2. 商戶前端與商戶服務交互，創建訂單
3. 商戶前端經由錢包，對訂單進行支付
4. 錢包與錢包服務器通訊，錢包服務器進行扣款，通知錢包和商戶服務器支付結果。
5. 商戶前端從錢包的支付返回中獲取結果，並和商戶服務器進行確認。
6. 支付完成，商戶獲得對應款項。
下面我們來介紹支付的四方通訊的詳細過程。
圖1 支付過程的四方通訊
1. 商戶前端與錢包模塊進行通訊，對錢包進行初始化。在這個過程中通常需要用戶登錄自己的錢包賬戶，進行必要的認證等操作。
2. 錢包模塊初始化完成，返回到用戶App中。
3. 商戶前端與商家服務器通訊，建立訂單。帶有的參數通常包括用戶信息、需要購買的商品id、時間戳、商品金額、錢包類型等。
4. 商家將訂單參數返回給商戶前端，帶有的參數通常包括：訂單號(order_no)、支付金額(total_fee)、支付結果通知地址(notify_url)、消息完整性簽名(sign)等。此時也有另一種實現，即虛線部分的4'。在4'中，商戶服務將大量參數直接通知給錢包服務，而只返回給用戶一個簡短的消息，包括一個錢包服務返回給商家服務的交易事務id。此後用戶只需通過錢包對這個交易事務id進行支付即可。
5. 商戶前端對商戶返回的信息進行包裝，發送給錢包模塊。
6. 錢包模塊與錢包服務進行交互，帶有的參數包括用戶的錢包session等信息，以及步驟4中返回的訂單信息等。
7. 錢包服務在進行必要的扣款處理（如與銀行進行交互）和風控處理後，將支付結果以同步通知7(1)和異步通知7(2)的方式分別通知錢包模塊和商戶服務。在支付結果通知中一般包括支付結果、支付金額、支付的訂單號、支付事務的流水號、商戶號，以及消息完整性簽名等。可選的參數包括商品信息、字符集/編碼方式、幣種信息等。商戶服務器在獲得7(2)的異步通知後，也需要驗證其消息的完整性，並對訂單狀態進行對應的更新（支付成功或者支付異常）。
8. 錢包模塊接收到錢包服務返回的同步通知後，進行必要的完整性驗證，並將支付結果返回給商戶前端。
9. 商戶前端在得到錢包模塊返回的消息，驗證其完整性。若獲得的是支付成功的消息，則需要向商戶服務器發起請求，驗證支付結果（查賬）。商戶服務器此時即可進行訂單支付完成後的處理。
在整個支付過程中，各個消息的完整性是最爲關鍵的。如果消息完整性保護存在漏洞，攻擊者即可發起修改金額、修改訂單號、構造虛假訂單等攻擊。作爲消息完整性保護的關鍵——簽名機制，是支付協議的核心之一。目前應用在第三方支付平臺中的簽名機制可以分成兩種：基於非對稱密碼體制的簽名，和基於散列函數的簽名。基於非對稱密碼的簽名機制只在極少數支付平臺上得到實現。而基於散列函數的簽名則基本被所有平臺應用或曾經應用過。
在基於非對稱密碼體制的簽名機制中，每個商戶和支付平臺都生成自己的一套公鑰-私鑰對，並互相告知對方自己的公鑰。在進行支付時，發送消息方使用自己的私鑰對消息（或消息的散列值）進行簽名，接受消息方使用對方（發送消息方）的公鑰進行驗籤。這個方法的安全性來自於非對稱密碼體制的安全性，例如RSA的大質數分解難度，或計算橢圓曲線離散對數的難度。在這個機制中，最關鍵的是支付平臺的私鑰。攻擊者一旦獲得支付平臺私鑰，就可以對任意消息進行簽名，從而欺騙商戶。其次是商戶的私鑰。攻擊者獲得商戶私鑰後，結合商戶App的其他漏洞，就可以進行各類攻擊。
基於散列函數的簽名機制安全性來自於哈希函數的不可逆性。在支付平臺中此類簽名機制幾乎得到所有平臺的使用。每個商戶與支付平臺預先共享一個密鑰，以及協商一個hash函數（例如MD5或者SHA1）。在發送消息時，每個商戶活支付平臺在消息中附加上與對方共享的這個密鑰，再對整體進行hash運算，得到簽名值，與原始消息合併作爲最後的消息發送給對方。在接受消息時則將簽名值剝離，將剩下的部分與密鑰組合後進行hash運算，檢驗生成的散列值是否與發來的簽名值相符。在這個體制中，最關鍵的無疑就是商戶和支付平臺預先共享的這個密鑰了。一旦這個密鑰泄露，攻擊者既可以模仿商戶給支付平臺發信息，又可以模仿支付平臺給商戶發信息，以進行各類欺騙和攻擊，危害無窮。在目前支付平臺所採用的簽名機制中，以基於MD5的簽名最爲常見。
此外，以上提到的私鑰泄露，其實等同於令商戶/支付平臺對指定字符串進行簽名的能力。如果攻擊者可以在很少代價的情況下對指定的“畸形”/“惡意”串進行簽名的話，也相當於獲得了任意簽名的能力，從而以很小的代價發起攻擊。
值得注意的是，基於MD5的簽名機制並不僅限於"支付協議"中使用，在相當多類型的通信中均得到大量應用。而MD5如果不嚴格限定輸入並使用正確的模式將會是相當脆弱的，我們可以構造通用的簽名碰撞攻擊，將在後繼文章中進行介紹。
同時，支付結果的同步、異步通知則是最容易受到攻擊的點。支付結果的同步通知可以在端上被攻擊者篡改（例如使用代理或者Xposed）。對於異步通知，由於異步通知經常缺乏可靠的對發送者的身份鑑定，因此攻擊者可以自行構造異步通知來通知商戶服務已支付成功，從而完成攻擊。此外，異步通知的地址往往是可變的，以參數的形式傳遞給支付平臺。攻擊者一旦獲得了修改異步通知地址的能力，也會對支付過程的安全性造成威脅。
簽名機制
1. 基於MD5的消息完整性簽名機制
在目前國內大部分支付平臺以及諸如anySDK平臺等平臺的接口中均使用或曾使用基於MD5的消息完整性簽名機制。該機制主要用戶保證圖1中四方通訊時消息傳遞的完整性。
基於MD5的消息完整性簽名機制如圖2所示。該方法的關鍵在於：商家和錢包服務之間共享一個簽名密鑰。該簽名密鑰參與到每個簽名生成以及簽名驗證過程中。該密鑰不能泄露，一旦泄露則會造成極大安全隱患。攻擊者可以藉助泄露的密鑰來僞造消息，修改訂單，發送支付成功消息等。
在簽名過程中，簽名方將待簽名的原請求中的key-value對按照key的字母序進行排序，然後連接在一起。這個連接可以使用‘&’組合，也可以不使用‘&’。再將簽名密鑰附帶在組合的結尾，生成“待簽字符串”。有的簽名方案使用‘&key=’來連接key，有的則直接附加key在末尾，區別不大。然後使用MD5算法生成待簽字符串的散列值作爲簽名。最後將該散列值作爲一個域附加在原請求中，得到最終的請求。
驗簽過程和簽名過程是基本相同的。首先從最終請求中分離出簽名域，再將需要驗籤的部分按照key的順序排列並重新組合，附加上簽名密鑰，生成簽名過程中的“待簽字符串”，最後計算其MD5值，判斷其與最終請求中所帶的散列值是否相符。
2. 基於非對稱密碼體制的簽名機制
應用這一類簽名機制的平臺較少，其支付過程可參見圖3。
以RSA爲例。商戶生成一對RSA公私鑰對，錢包服務生成一對RSA公私鑰對。雙方把各自的公鑰（金色鑰匙）發給對方。
對消息進行簽名的過程和基於MD5的過程類似，也是首先將請求按key-value對排序，再使用RSA-SHA1算法（先SHA1再變形再RSA）和對方的RSA公鑰生成簽名，最後將簽名附在原請求中形成完整的請求。 驗簽過程使用自己的RSA私鑰進行驗籤，具體過程不表。
3. 待簽字符串的生成
以上兩類簽名機制均依賴於“待簽字符串”的生成。在待簽字符串的生成過程中有以下三個主要問題：
1. 參數值爲空的情況。在某些平臺中，參數值爲空的參數在待簽字符串中被忽略。在某些平臺中則不被忽略。
2. 參數值的編碼問題。在某些平臺中，參數值編碼後（編碼方式也有不同）進入待簽字符串。在某些平臺中則在解碼後進入待簽字符串。
3. 特殊字符問題。由於待簽字符串使用&和=作爲元字符，因此參數中存在的&和=等字符會影響待簽字符串的結構。不同平臺對特殊字符的處理也不同。
4. 進入待簽字符串的參數選擇。某些平臺中，所有參數均進入待簽字符串中參與簽名生成。而某些平臺中只有指定參數纔會進入待簽字符串中參與運算。
待簽字符串的種種性質導致了其“二義性”的出現。在某些情況下，同一個待簽字符串可以等價於兩個不同請求。例如這個待簽字符串
a=A&b=B&c=C&d=D
可以由一個包含四個key-value對的原請求
{"a":"A", "b":"B", "c":"C", "d":"D"}
生成。在某些情況下，還可以由以下包含五個key-value對的原請求生成
{"a":"A", "b":"B", "c":"C", "d":"D", "junk":"JUNK"}
或者，在另一些情況下，可以由以下只包含三個key-value對的原請求生成
{"a":"A&b=B", "c":"C", "d":"D"}
這些變形依賴於“待簽字符串”的生成方法。攻擊者可以通過構造畸形請求來生成具有相同“待簽字符串”的請求，從而繞過簽名驗證限制。
支付協議的安全漏洞
由以上分析，第三方支付過程的安全嚴重依賴於以下三點：
1. 密鑰的安全管理
2. 支付平臺簽名算法的正確實現
3. 商戶對支付協議的正確使用
然而在生產環境中每個環節都有可能出錯，引起嚴重的安全隱患。
1. 密鑰泄露
這是最常見的一種安全漏洞。密鑰泄漏並不是一種罕見的情況，不少app在開發時，將密鑰硬編碼在app代碼中（用於本地實現簽名計算）。消息的完整性依賴於簽名的計算，密鑰泄漏後消息將無法保證未被篡改或僞造。但對稱密鑰和不對稱密鑰泄漏後的利用和危害有所區別。
圖4展示了最常見的情況。MD5簽名密鑰編碼在用戶App中造成密鑰泄露。在對相當多的app進行逆向工程後我們發現，有部分app直接照搬一些樣例代碼，導致key被直接明文編碼到程序中，非常容易提取。還有一部分app作者使用了一些變形手段，例如將key拆成奇數位、偶數位分別存儲，或使用特定常數進行異或存儲。這些簡單變形在熟練的攻擊者面前是徒勞的。
由於商戶和支付平臺共享密鑰，密鑰泄漏後，攻擊者既可以冒充商戶向支付平臺發送訂單消息，又可以冒充支付平臺向商戶發送支付結果。當然，後者更加直接（如圖4）。
例如，若攻擊者準備購買一件商品，其訂單消息爲
notify_url=http://seller.com/notify&out_trade_no=12345&seller=alice&total_fee=100&sign=XXX,
攻擊者可以首先通過修改notify_url到攻擊者掌控的地址，如http://attacker.com/,提交請求:
notify_url=http://attacker.com/notify&out_trade_no=12345&seller=alice&total_fee=100&sign=XXX
來獲得notify_url的結構。再僞造以下消息簽名後發送給商戶，僞造異步通知，實現免費購物。
target_url: http://seller.com/notify
post_data: put_trade_no=12345&seller=alice&total_fee=100&trade_status=SUCCESS&sign=XXX.
商戶收到消息後驗證簽名正確，所有參數均正確，將完成攻擊者的訂單。而事實上，攻擊者並未進行過任何支付。
另一方面，基於非對稱密碼體制的簽名方案中，私鑰泄露後攻擊者也可以進行攻擊。但是仍依賴於其他的邏輯漏洞。攻擊者只能獲取商戶的私鑰，而支付平臺的私鑰往往被妥善保護無法獲得。因此，攻擊者無法冒充支付平臺向商戶發送支付成功的消息，而只能冒充商戶向支付平臺僞造訂單或者篡改訂單，修改支付金額。
如圖5所示，若攻擊者準備購買一件商品，其訂單消息爲
notify_url=http://seller.com/notify&out_trade_no=12345&seller=alice&total_fee=100&sign=XXX
攻擊者修改金額，使用私鑰重新簽名，並提交支付訂單
notify_url=http://seller.com/notify&out_trade_no=12345&seller=alice&total_fee=1&sign=XXX
成功支付1元后，商戶會收到支付結果消息
out_trade_no=12345&seller=alice&total_fee=1&trade_status=SUCCESS&sign=XXX
商戶進行消息的驗證，會發現簽名正確，商戶號正確，訂單12345支付成功。若商戶沒有驗證支付金額與訂單是否匹配，將完成攻擊者的訂單。從而攻擊者以1元購買了100元的商品。在許多App中，曾出現過只驗證簽名和訂單id的情況，沒有驗證實付金額，因此可以通過這種金額篡改進行攻擊。
爲了防禦這樣的攻擊，商家一定要修改app和服務端的設計，使得簽名全部在服務端進行。網上充斥着大量可以直接照搬的富含漏洞的樣例代碼，一定不要簡單修改這些代碼就直接接入支付平臺。此外，每筆交易均要進行查賬，驗證錢真的得到了支付，纔可以標記訂單爲成功支付。
一旦出現這樣的祕鑰泄漏商家將面臨嚴峻的安全風險，支付平臺也將面臨嚴重的連帶品牌危機。發生這樣的危機時，如果簡單的替換祕鑰將會直接導致老App客戶端無法進行交易，如果不替換則將面臨嚴峻的支付風險。目前臨時緩解方案是依靠商家服務後臺與錢包服務後臺的增強校驗和風控來探測和抵抗攻擊。
2. 簽名算法實現錯誤
簽名泄露隻影響個別自己實現錯誤的商家，而支付平臺的漏洞則會影響千萬商家。在這一節我們討論我們提交給兩個國內著名支付平臺的平臺漏洞，他們均已得到修復。
案例一
第三方支付平臺A採用了對稱密鑰的設計，並提供了服務端SDK供商家集成。服務端SDK提供了API驗證簽名是否正確。
在PHP和C#的SDK實現中，當簽名字段不存在時，SDK會直接返回簽名正確，這就導致了攻擊者可以直接冒充支付平臺向商戶發送僞造的支付結果消息並通過簽名認證。
以PHP版代碼爲例
public function CheckSign()
{
if(!$this->IsSignSet()){
returntrue;
}
$sign = $this->MakeSign();
if($this->GetSign() == $sign){
returntrue;
}
throw newException("簽名錯誤！");
}
public function IsSignSet()
{
return array_key_exists('sign', $this->values);
}
檢查簽名時，首先會利用函數 IsSignSet判斷簽名是否存在。若簽名不存在，直接認爲簽名正確。
由於該支付平臺要求商戶服務器將訂單（包括通知URL）發送給支付服務器獲取一個ID，隨後商戶應用將ID傳遞給支付客戶端調起支付界面，在實際攻擊中， 攻擊者還需要從其他渠道獲取通知URL（例如路徑猜測、URL硬編碼或存在網絡請求中等）纔可僞造支付結果。
案例二
支付平臺B採用了非對稱密鑰的設計，每個商戶有自己的一套公鑰私鑰，但支付平臺的公鑰私鑰僅一套，即所有商戶使用同一個公鑰驗證來自支付平臺的消息。
除此以外，訂單消息和支付結果消息中包含字段body描述商品信息，且訂單消息和對應支付結果消息中的body一致。
如果攻擊者希望免費(低價)購物,應該如何進行呢？回顧上文中關於待簽字符串二義性的討論，待簽字符串爲形如：
key1=value1&key2=value2&key3=value3
的格式。&和=作爲了連接符號。
如果某一個參數值(value)中包含&和=符號，待簽字符串和原始的參數集合就可能不再是一對一，即存在多組參數集合對應同一組待簽字符串。
例如：參數集合
{"key1":"value1","key2":"value2&key3=fake_value&zend_key=a", "key3":"value3"}
的待簽字符串爲
key1=value1&key2=value2&key3=fake_value&zend_key=a&key3=value3
考慮另一個參數集合
{"key1":"value1","key2":"value2", "key3":"fake_value","zend_key":"a&key3=value3"}
的待簽字符串同爲
key1=value1&key2=value2&key3=fake_value&zend_key=a&key3=value3
兩組集合的待簽字符串一樣，但key3的值不同。攻擊者若知道其中一組的簽名，便知道另一組參數在相同密鑰下的簽名了。
有了這個發現，如何在實際中利用並實現免費(低價)購物呢? 攻擊者需要“騙一個畸形訂單支付成功的簽名”！
首先，攻擊者需要擁有一個商戶evil的私鑰（可自行註冊或利用已泄漏密鑰）
現在攻擊者準備向商戶alice購買一件商品，正常的訂單消息參數爲
{"body":"商品A"，"notify_url":"http://seller.com/notify","out_trade_no":"12345","seller":"alice", "total_fee":"100","sign":"XXX"}
若訂單支付成功，支付結果的參數應爲
{"body":"商品A","out_trade_no":"12345", "seller":"alice", "total_fee":"100", "trade_status":"SUCCESS","sign":"YYY"}，
因此，攻擊者的目標是向http://seller.com/notify發送一個支付完成的消息，並且包含
{"body":"商品A", "out_trade_no":"12345", "seller":"alice", "total_fee":"100", "trade_status":"SUCCESS"}
這些參數和正確的簽名。
這樣一條消息會經過支付平臺的簽名，攻擊者無法直接僞造。但是前面提到，所有商戶使用同一個公鑰驗證來自支付平臺的消息，也就是說支付平臺發給商戶evil的消息若轉發給商戶alice，簽名可以通過驗證，僅僅是商戶號等參數值不正確。因此，攻擊者可以考慮利用evil的支付結果來僞造給alice的支付結果。
攻擊者首先發給支付平臺一個屬於商戶Evil的訂單消息
{“body”:“商品A&out_trade_no=12345&seller=alice&total_fee=100&trade_status=SUCCESS&z=”，“notify_url”:“http://evil.com/notify”, “out_trade_no”:”12345”,“seller”:“evil”, “total_fee”:“1”， “sign”:“XXXX”}，
支付1元后，http://evil.com/notify會收到支付結果，並且經過了支付平臺簽名。
{“body”:“商品A&out_trade_no=12345&seller=alice&total_fee=100&trade_status=SUCCESS&z=”， “out_trade_no”:”12345”, “seller”:“evil”, “total_fee”:“1”,“trade_status”:“SUCCESS”, “sign”:“signed by payment platform”}，
攻擊者可以將其變換爲
{“body”:“商品A”,“out_trade_no”:“12345”，“seller”:“alice”, “total_fee”:“100”, “trade_status”:“SUCCESS”,“z”:“&out_trade_no=12345&seller=evil&total_fee=1&trade_status=SUCCESS”, “sign”:“signed by payment platform”}
然後發送給商戶Alice的URL http://seller.com/notify。這些數據具有正確的簽名和期望的商家號、訂單號、支付金額，將會通過alice驗證，從而alice會通過攻擊者的訂單。
攻擊者因此實現了免費(低價)購物。
3. 商戶驗證支付結果時存在邏輯錯誤
3.1. 簽名驗證
儘管支付平臺提供了服務端SDK，商戶後端在實現邏輯時可能並未使用SDK。那麼，商戶應正確實現簽名的驗證邏輯，避免相關邏輯錯誤，如簽名不存在時通過簽名驗證。
3.2. 總金額、商戶號的驗證
商戶在收到支付結果通知，驗證完簽名後，還應正確處理支付結果中的相關參數。支付金額、商戶號都應該被驗證。
當支付金額未被驗證，攻擊者可以支付較低的費用實現購物。支付金額不一致可能是訂單消息在簽名之前金額被篡改或是攻擊者僞造了訂單消息（參考不對稱密鑰泄漏）。
若商戶號未被驗證，攻擊者可以考慮複用另一商戶的支付結果，對當前商戶進行攻擊。攻擊發生的條件在於發給不同商戶的支付結果使用了同樣的私鑰簽名，同時攻擊者註冊了自己商戶。攻擊者生成一個訂單，支付給自己的商戶後，將支付結果複用。
若商戶號和總金額均未被驗證，攻擊者還可以再次考慮複用另一商戶的支付結果對當前商戶進行攻擊。雖然複用支付結果仍要求發給不同商戶的支付結果使用了同樣的私鑰簽名，但攻擊者不再需要註冊自己的商戶，而是利用已泄漏的商戶密鑰。實現攻擊時，攻擊者生成一個費用較低的訂單，完成支付後複用支付結果。
3.3. 只在客戶端驗證
在用戶完成支付後，支付平臺往往既會異步通知商戶服務器支付結果，又會同步通知商戶客戶端支付結果以向用戶展示。
然而，支付結果的驗證應在服務端完成。僅在客戶端驗證將容易受到攻擊。攻擊者可以直接修改客戶端邏輯實現免費購物。
總結
本文總結了常見支付平臺的支付過程的機制，探討了其中存在和可能存在的問題，並通過實例展現了商戶端和支付平臺出現的安全問題。除了本文中探討的問題，還有許許多多安全隱患在近年得到不斷修正。總的來說現在的網上支付還是比較可靠的。在下篇中我們繼續對基於MD5的消息簽名機制進行討論，發掘更多的安全問題。
參考文獻
1. 微信支付安全規範,https://pay.weixin.qq.com/wiki/doc/api/app/app.php?chapter=4_3
2. 支付寶手機網站支付:簽名與驗籤, 2016年5月30日版,https://doc.open.alipay.com/docs/doc.htm?treeId=60&articleId=104741&docType=1
3. 支付寶手機網站支付結果異步通知, 2017年1月9日版,https://doc.open.alipay.com/docs/doc.htm?treeId=203&articleId=105286&docType=1
4. 支付寶App支付同步返回, 2017年1月9日版,https://doc.open.alipay.com/docs/doc.htm?treeId=204&articleId=105302&docType=1
5. 支付寶App支付異步通知, 2017年1月9日版,https://doc.open.alipay.com/docs/doc.htm?treeId=203&articleId=105286&docType=1
6. 百度錢包商戶接入流程,https://b.baifubao.com/sp_register/0/page_controller/0?page=access_process
7. 新浪支付開發指南,V1.0和V2.0回調接口,http://open.weibo.com/wiki/支付開發指南
8. 網銀在線,京東支付接口文檔, https://www.chinabank.com.cn/service/support.jsp
9. 騰訊財付通支付網關商戶開發指南,http://support.tenpay.com/demo/tenpay_wangguan.zip
10. 快錢人民幣支付網關商戶接口規範, https://github.com/hoosin/pay/blob/master/%E5%BF%AB%E9%92%B1%E4%BA%BA%E6%B0%91%E5%B8%81%E6%94%AF%E4%BB%98%E7%BD%91%E5%85%B3%E5%95%86%E6%88%B7%E6%8E%A5%E5%8F%A3%E8%A7%84%E8%8C%83.pdf
11. 支付平臺僞造支付結果漏洞,https://virusdefender.net/index.php/archives/155/
12. 阿里飛豬信用住服務器異步通知接口,https://open.alitrip.com/docs/doc.htm?&docType=1&articleId=104043
13. AnySDK, H5通知接口,http://docs.anysdk.com/faq/h5-special-notice/
長按關注
百度安全實驗室
本文分享自微信公衆號 - 百度安全實驗室（BaiduX_lab）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。