前言

　　大家對支付漏洞的理解通常都是篡改價格，已有的對支付漏洞的總結也是對現有的一些案例的經驗式歸類，沒有上升到對在線支付流程深入分析的一個層面。這裏嘗試從分析在線支付流程，在線支付廠商的接入方式開始，深入業務分析整個在線交易流程中容易出現的安全問題。

　　支付寶/在線支付流程

　　支付寶即時到賬接口開發流程

　　在線支付從功能上來說是通過支付寶的支付渠道，付款者直接匯款給另一個擁有支付寶賬號的收款者。整個流程說明如下：引用自支付寶文檔。

(1)構造請求數據
商戶根據支付寶提供的接口規則，通過程序生成得到簽名結果及要傳輸給支付寶的數據集合。
(2)發送請求數據
把構造完成的數據集合，通過頁面鏈接跳轉或表單提交的方式傳遞給支付寶。
(3)支付寶對請求數據進行處理
支付寶得到這些集合後，會先進行安全校驗等驗證，一系列驗證通過後便會處理這次發送過來的數據請求。
(4)返回處理的結果數據
對於處理完成的交易，支付寶會以兩種方式把數據反饋給商戶網站。
程序上自動進行重新構造URL地址鏈接，在用戶當前頁面上通過自動跳轉的方式跳回商戶在請求時設定好的頁面路徑地址（參數return_url，如果商戶沒有設定，則不會進行該操作）
支付寶服務器主動發起通知，調用商戶在請求時設定好的頁面路徑（參數notify_url，如果商戶沒有設定，則不會進行該操作）。
(5)對獲取的返回結果數據進行處理
商戶在同步通知處理頁面（參數return_url指定頁面文件）或服務器異步通知頁面（參數notify_url指定頁面文件）獲取支付寶返回的結果數據後，可以結合自身網站的業務邏輯進行數據處理（如：訂單更新、自動充值到會員賬號中等）。

　　業務思考

　　通過這個流程可以知道。應用端做的兩個重要步驟，一個是拼接支付的請求，返回給用戶瀏覽器，用戶瀏覽器請求支付寶接口，進入支付流程，整個支付的環節是和支付寶端交互，支付完成之後，支付寶通過通知接口給應用發送支付成功的通知。應用通過支付寶的通知信息來判斷支付是否成功。

　　風險分析

　　首先第二步，發送請求數據。這一步雖然是在用戶的瀏覽器端完成的。但是支付接口都有強制的簽名來保證完整性，所以這裏數據是無法篡改的，在簽名key不泄露的情況下。所以通常見到的支付漏洞都是第一步，應用構造請求數據的時候出現的缺陷。

　　對於交易這一業務功能來講，應用只需要用戶提供商品id和商品數量就可以滿足支付所需要的所有數據了。這個地方容易出現的問題主要有以下幾種：

　　1，直接把訂單的總金額從客戶端獲取，放在了構造的請求交易數據中。

　　2，雖然只傳遞商品id和數量，但是數量沒有做白名單限制，造成可以輸入負數或者大數造成計算溢出，導致最終計算的訂單金額出現錯誤。

　　3，除了商品數量和商品id，還有其他參與訂單金額計算的參數從客戶端獲取，比如運費等

　　第三步和第四步是支付寶進行的處理，所以也不存在問題。第五步，支付寶通知應用用戶付款成功，這裏支付寶設計了notify_id供應用來驗證通知信息是否是有效的。但是一般很少見人用，因為這一步數據也是有簽名的。只要應用對支付寶的通知信息進行簽名驗證就可以。但是這個驗證是應用自己來控制的，並不像第二步是支付寶控制的進行簽名驗證，所以一旦應用沒有對支付寶通知信息進行簽名驗證就會導致偽造支付寶的通知信息，欺騙應用支付成功的漏洞。這種類型的問題看到的案例比較少。比如我是如何1元再購特斯拉的。這種類型的問題應該也比較常見，可能是對這個邏輯的測試還不夠關註。

　　所以通過分析整個在線支付的流程可以看到，容易出現支付漏洞的有兩個點，一個是構造支付請求的階段，一個是對返回的結果數據進行處理的階段。沒有對簽名進行驗證，會存在請求偽造和重放攻擊。這裏分析的是一個典型的支付流程，此外還有一些比較復雜的交易設計，比如設計了可以修改訂單的功能等，隨著功能的增加也會引入一些安全問題。

　　安全的設計方案：

　　只從客戶端獲取商品id和數量，對數量範圍進行限制。對接受支付寶通知的接口對通知信息進行簽名驗證，對支付金額和訂單金額進行對比以及驗證支付訂單號避免重放攻擊。只要考慮到這幾個問題，就可以設計一個比較安全的支付流程。

　　支付寶提供的驗證方式

　　notifyid

　　total_fee

　　sign

　　order_no 防重放

在線支付流程安全分析與支付漏洞總結