如何利用Webhooks繞過支付環節

為了深入挖掘bug獎勵計劃範圍內的各種漏洞，很有必要對於那些最終用戶不可見的功能進行安全測試。例如，支付webhooks就是這樣的一個例子，支付提供商（如Stripe或Braintree）使用它來向網站報告用戶訂閱詳細信息的更新情況。最重要的是，用戶從來不會與這些webhook端點直接打交道——所有的通信都發生在支付提供商和伺服器之間。換句話說，bug賞金獵人很可能會忽視webhook，這樣的話，就更談不上測試其中潛在的安全漏洞了。

挖掘漏洞

在針對按月訂閱的網站進行測試時，我發現了一份公司內部發行的API文檔。其中，最吸引我的一個端點是對/api/webhooks/stripe的PUT請求。根據以往針對付款服務提供商的安全測試經驗，我立即想到，首先應該向該端點發送虛假請求，看看能否欺騙網站使其誤認為我已付款。

當我發送一個空的JSON請求後，伺服器返回了一個錯誤信息。在查看Stripe為webhooks規定的格式後，我又發送了以下內容：

{

"payment": {

"status":"success",

"provider":"stripe"

},

"id":"..."

}

這次，伺服器返回的是一個成功的信息：

{

"id":"...",

"amount":1,

"status":"success",

"provider":"stripe"

}

就這樣，我的帳戶已成功授權，並顯示為付費訂閱。這讓我不禁想到：到底有多少這樣的漏洞被我們忽略了，而支付提供商到底為防止這種漏洞提供了哪些防禦措施呢？

支付服務提供商的防範措施

雖然支付服務提供商有能力防止該漏洞，但是奇怪的是，有的提供商並沒有對終端提供相應的保護。不過，Braintree的做法就非常值得借鑒：用戶必須通過Braintree的庫來解析傳入的webhook，它會自動驗證請求並提取JSON正文。這樣，webhook端點在默認情況下就是安全的，而不會被攻擊者所欺騙。

Stripe是Braintree公司使用的支付服務提供商，但是它在webhook安全性方面做得卻不那麼完善。儘管Stripe的文檔中明確指出會驗證webhook簽名，但這似乎只是一個旁註，因為它沒有強調確保webhooks需源自Stripe的重要性。並且，文檔中列出的示例代碼也沒有包含任何簽名驗證，而是直接解析JSON請求。

如果不能確保默認情況下的安全性的話，這就是一個很大的隱患。因為用戶在集成支付功能時，通常會採用最省勁的方式，這意味著許多用戶根本就不會對傳入的簽名進行相應的驗證。

Recurly公司也是一家訂閱支付提供商，它提供了HTTP基本認證，以便在伺服器之間共享密鑰。再次強調一下，採用這種措施之前，一定要考慮用戶是否能夠忍受驗證共享密鑰所帶來的麻煩。此外，Recurly還提供了一個IP地址列表，並要求webhook請求必須源自該表中的地址。但是，僅僅採取這些措施還是不夠的：例如，如果攻擊者創建單獨的Recurly帳戶來發送惡意但有效的webhook呢？

最後，根據接受比特幣付款的BitPay公司聲稱：「由於BitPay沒有對IPN進行簽名，所以，不應完全信任有效載荷中的信息。」也許有人會贊成這種做法，因為安全性的缺乏是眾所周知的，所以用戶在閱讀這些信息時反而會提高警惕性。

查找webhook端點的方法

在測試webhook與支付相關漏洞的時候，能得到的最直接線索就是公司提供的每月訂閱。根據支付提供商（如上所述）的情況來看，該網站可能沒有提供足夠的防禦措施。

下面給出查找webhook端點的方法：

·通過「webhook」或「payment」搜索JavaScript文件。有的公司可能會無意中暴露內部終端。

·通過被測試對象在GitHub上的代碼庫或類似的地方，查找對webhooks的引用。

·由於webhook端點的格式通常具有相似的形式，因此，可以據此嘗試訪問不同的API端點，如 /api/stripe/webhook、 /api/payments/webhook、 /api/stripeWebhook等。

小結

毫無疑問，對付款webhooks進行測試的時候，應該涵蓋所有敏感操作的默認值。雖然有的支付提供商為其客戶提供了針對此類攻擊的防禦措施，但不是所有的提供商都是這樣做的，所以，用戶仍要提供警惕性，做好自身的安全防護工作。

與此同時，還應該檢查付款端點是否存在錯誤配置。實際上，這些測試不僅限於支付情形，相反，對於任何服務來說，所有傳入的webhook消息都應該進行相應的安全檢測。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！