寫在前面的話

在深入了解漏洞獎勵計劃中的安全漏洞時，我們往往需要尋找一些用戶不可見的功能下手。支付Webhook就是一種典型例子，像Stripe或Braintree這樣的支付服務提供商都會使用這種技術來將用戶的訂購細節告知網站。重要的是，用戶根本不會跟這些Webhook節點進行交互，所有的通信都是在支付提供商和服務器之間完成的。這也就意味著，很多漏洞Hunter可能從來都不會想到要去測試Webhook功能，這也就會錯過很多潛在的高危漏洞。

[[224949]]

漏洞發現

當我在對一個提供了月度訂購服務的網站進行測試時，我恰好得到了該網站內部API的開發文檔。其中有一個節點吸引了我的注意力，這個節點(/api/webhooks/stripe)可以接收PUT請求，根據我之前對支付提供商進行安全測試的經驗來看，我認為如果我可以向這個節點發送偽造請求并讓網站認為我已經完成了支付。

我首先發送了一個空的JSON請求，隨后服務器返回了一條錯誤信息。在對該網站Webhook所使用的Stripe格式進行了分析之后，我發送了包含下列內容(body)的JSON請求：

{ 
  "payment": { 
    "status":"success", 
    "provider":"stripe" 
  }, 
  "id":"..." 
} 

此時服務器返回的響應信息顯示狀態為“成功”：

{ 
  "id":"...", 
  "amount":1, 
  "status":"success", 
  "provider":"stripe" 
} 

就這樣，我的賬號授權成功了，并且顯示已經成功支付了訂閱服務。這就不得不讓我思考了：現在還有多少網站存在這樣的漏洞?支付服務提供商如何防止這種漏洞出現呢?

解決方案

實際上，支付提供商是有能力防止這種漏洞出現的，所以我才會驚訝這些節點竟然沒有受到相應的安全保護。Braintree的實現方案就是正確的：用戶必須通過Braintree的代碼來對傳入的Webhook數據進行解析，代碼會自動驗證請求的合法性，并提取出JSON body。這樣一來，Webhook節點就會非常的安全，而且也不會被攻擊者的偽造請求所欺騙。

該網站所使用的支付服務提供商-Stripe在面對Webhook安全性問題時，并不能保證“萬無一失”。雖然Stripe確實提到了驗證Webhook的簽名，但這只是一種安全建議，他們也并沒有強調這一點對Webhook安全性的整體安全性有多么重要的影響。除此之外，API文檔中給出的代碼樣例中并沒有包含任何的Webhook簽名認證，而是直接對JSON請求進行了解析。

默認情況下Webhook都是不安全的，這就非常棘手了。在開發整合了支付的服務時，用戶往往會采取“阻力”最小的實現方法，因此這意味著很多網站都不會對輸入請求的簽名進行驗證。

另一個訂閱支付服務提供商Recurly利用了HTTP基礎認證來在服務器之間共享一個密鑰，現在可能有人又要問了，難道驗證共享密鑰就不麻煩了嗎…除此之外，Recurly還提供了一個IP地址列表，只有來自這個IP地址列表的Webhook請求才會被認為是有效的。但是，這還遠遠不夠。比如說，攻擊者可以創建一個單獨的Recurly賬號，然后發送有效但惡意的Webhook請求，這同樣會引起安全問題。

漏洞線索

在測試跟支付相關的Webhook漏洞時，我們可以先對那些提供了月度訂閱服務的網站進行分析，這是一條非常有效的線索，因為絕大多數的支付服務提供商都沒有針對Webhook來實現足夠有效的安全保護。

下面我們給出幾種尋找Webhook節點的方法：

• 搜索跟“Webhook”或“payment”相關的JavaScript文件，很多支付網站可能會直接暴露內部節點;
• 搜索目標組織的GitHub代碼庫或相關文檔，尋找關于Webhook的相關引用內容;
• 大多數Webhook節點的數據格式可能都比較相似，所以我們可以嘗試訪問不同的API節點來尋找Webhook節點，比如說/api/stripe/webhook、/api/payments/webhook或/api/stripeWebhook。

總結

毫無疑問，如果支付網站想要檢測任何可疑的網絡行為，那么驗證支付Webhook請求絕對是要默認進行的。雖然有些支付提供商會給用戶提供一些方法來防止這種攻擊，但這仍然需要提供商和客戶的共同努力。