如何利用Webhook繞過支付請求，很多新手對此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

成都創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括貴陽網(wǎng)站建設(shè)、貴陽網(wǎng)站制作、貴陽網(wǎng)頁制作以及貴陽網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，貴陽網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到貴陽省份的部分城市，未來相信會繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

寫在前面的話

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

漏洞發(fā)現(xiàn)

當(dāng)我在對一個(gè)提供了月度訂購服務(wù)的網(wǎng)站進(jìn)行測試時(shí)，我恰好得到了該網(wǎng)站內(nèi)部API的開發(fā)文檔。其中有一個(gè)節(jié)點(diǎn)吸引了我的注意力，這個(gè)節(jié)點(diǎn)（/api/webhooks/stripe）可以接收PUT請求，根據(jù)我之前對支付提供商進(jìn)行安全測試的經(jīng)驗(yàn)來看，我認(rèn)為如果我可以向這個(gè)節(jié)點(diǎn)發(fā)送偽造請求并讓網(wǎng)站認(rèn)為我已經(jīng)完成了支付。

我首先發(fā)送了一個(gè)空的JSON請求，隨后服務(wù)器返回了一條錯誤信息。在對該網(wǎng)站W(wǎng)ebhook所使用的Stripe格式進(jìn)行了分析之后，我發(fā)送了包含下列內(nèi)容（body）的JSON請求：

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

此時(shí)服務(wù)器返回的響應(yīng)信息顯示狀態(tài)為“成功”：

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

就這樣，我的賬號授權(quán)成功了，并且顯示已經(jīng)成功支付了訂閱服務(wù)。這就不得不讓我思考了：現(xiàn)在還有多少網(wǎng)站存在這樣的漏洞？支付服務(wù)提供商如何防止這種漏洞出現(xiàn)呢？

解決方案

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

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

默認(rèn)情況下Webhook都是不安全的，這就非常棘手了。在開發(fā)整合了支付的服務(wù)時(shí)，用戶往往會采取“阻力”最小的實(shí)現(xiàn)方法，因此這意味著很多網(wǎng)站都不會對輸入請求的簽名進(jìn)行驗(yàn)證。

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

漏洞線索

在測試跟支付相關(guān)的Webhook漏洞時(shí)，我們可以先對那些提供了月度訂閱服務(wù)的網(wǎng)站進(jìn)行分析，這是一條非常有效的線索，因?yàn)榻^大多數(shù)的支付服務(wù)提供商都沒有針對Webhook來實(shí)現(xiàn)足夠有效的安全保護(hù)。

下面我們給出幾種尋找Webhook節(jié)點(diǎn)的方法：

1.   搜索跟“Webhook”或“payment”相關(guān)的JavaScript文件，很多支付網(wǎng)站可能會直接暴露內(nèi)部節(jié)點(diǎn)；

2.   搜索目標(biāo)組織的GitHub代碼庫或相關(guān)文檔，尋找關(guān)于Webhook的相關(guān)引用內(nèi)容；

3.   大多數(shù)Webhook節(jié)點(diǎn)的數(shù)據(jù)格式可能都比較相似，所以我們可以嘗試訪問不同的API節(jié)點(diǎn)來尋找Webhook節(jié)點(diǎn)，比如說/api/stripe/webhook、/api/payments/webhook或/api/stripeWebhook。

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

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進(jìn)一步的了解或閱讀更多相關(guān)文章，請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。

網(wǎng)站題目：如何利用Webhook繞過支付請求
文章鏈接：http://aaarwkj.com/article26/jjhpcg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供、響應(yīng)式網(wǎng)站、搜索引擎優(yōu)化、全網(wǎng)營銷推廣、網(wǎng)站設(shè)計(jì)、移動網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)