建站
咨詢
售后
建站咨詢
新聞中心
寫在前面的話
成都創(chuàng)新互聯(lián)公司專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都網(wǎng)站制作、網(wǎng)站建設(shè)、惠安網(wǎng)絡(luò)推廣、小程序開(kāi)發(fā)、惠安網(wǎng)絡(luò)營(yíng)銷、惠安企業(yè)策劃、惠安品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營(yíng)等，從售前售中售后，我們都將竭誠(chéng)為您服務(wù)，您的肯定，是我們最大的嘉獎(jiǎng)；成都創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供惠安建站搭建服務(wù)，24小時(shí)服務(wù)熱線：18980820575，官方網(wǎng)址：www.cdcxhl.com
在深入了解漏洞獎(jiǎng)勵(lì)計(jì)劃中的安全漏洞時(shí)，我們往往需要尋找一些用戶不可見(jiàn)的功能下手。支付Webhook就是一種典型例子，像Stripe或Braintree這樣的支付服務(wù)提供商都會(huì)使用這種技術(shù)來(lái)將用戶的訂購(gòu)細(xì)節(jié)告知網(wǎng)站。重要的是，用戶根本不會(huì)跟這些Webhook節(jié)點(diǎn)進(jìn)行交互，所有的通信都是在支付提供商和服務(wù)器之間完成的。這也就意味著，很多漏洞Hunter可能從來(lái)都不會(huì)想到要去測(cè)試Webhook功能，這也就會(huì)錯(cuò)過(guò)很多潛在的高危漏洞。
漏洞發(fā)現(xiàn)
當(dāng)我在對(duì)一個(gè)提供了月度訂購(gòu)服務(wù)的網(wǎng)站進(jìn)行測(cè)試時(shí)，我恰好得到了該網(wǎng)站內(nèi)部API的開(kāi)發(fā)文檔。其中有一個(gè)節(jié)點(diǎn)吸引了我的注意力，這個(gè)節(jié)點(diǎn)(/api/webhooks/stripe)可以接收PUT請(qǐng)求，根據(jù)我之前對(duì)支付提供商進(jìn)行安全測(cè)試的經(jīng)驗(yàn)來(lái)看，我認(rèn)為如果我可以向這個(gè)節(jié)點(diǎn)發(fā)送偽造請(qǐng)求并讓網(wǎng)站認(rèn)為我已經(jīng)完成了支付。
我首先發(fā)送了一個(gè)空的JSON請(qǐng)求，隨后服務(wù)器返回了一條錯(cuò)誤信息。在對(duì)該網(wǎng)站W(wǎng)ebhook所使用的Stripe格式進(jìn)行了分析之后，我發(fā)送了包含下列內(nèi)容(body)的JSON請(qǐng)求：
- {
- "payment": {
- "status":"success",
- "provider":"stripe"
- },
- "id":"..."
- }
此時(shí)服務(wù)器返回的響應(yīng)信息顯示狀態(tài)為“成功”：
- {
- "id":"...",
- "amount":1,
- "status":"success",
- "provider":"stripe"
- }
就這樣，我的賬號(hào)授權(quán)成功了，并且顯示已經(jīng)成功支付了訂閱服務(wù)。這就不得不讓我思考了：現(xiàn)在還有多少網(wǎng)站存在這樣的漏洞?支付服務(wù)提供商如何防止這種漏洞出現(xiàn)呢?
解決方案
實(shí)際上，支付提供商是有能力防止這種漏洞出現(xiàn)的，所以我才會(huì)驚訝這些節(jié)點(diǎn)竟然沒(méi)有受到相應(yīng)的安全保護(hù)。Braintree的實(shí)現(xiàn)方案就是正確的：用戶必須通過(guò)Braintree的代碼來(lái)對(duì)傳入的Webhook數(shù)據(jù)進(jìn)行解析，代碼會(huì)自動(dòng)驗(yàn)證請(qǐng)求的合法性，并提取出JSON body。這樣一來(lái)，Webhook節(jié)點(diǎn)就會(huì)非常的安全，而且也不會(huì)被攻擊者的偽造請(qǐng)求所欺騙。
該網(wǎng)站所使用的支付服務(wù)提供商-Stripe在面對(duì)Webhook安全性問(wèn)題時(shí)，并不能保證“萬(wàn)無(wú)一失”。雖然Stripe確實(shí)提到了驗(yàn)證Webhook的簽名，但這只是一種安全建議，他們也并沒(méi)有強(qiáng)調(diào)這一點(diǎn)對(duì)Webhook安全性的整體安全性有多么重要的影響。除此之外，API文檔中給出的代碼樣例中并沒(méi)有包含任何的Webhook簽名認(rèn)證，而是直接對(duì)JSON請(qǐng)求進(jìn)行了解析。
默認(rèn)情況下Webhook都是不安全的，這就非常棘手了。在開(kāi)發(fā)整合了支付的服務(wù)時(shí)，用戶往往會(huì)采取“阻力”最小的實(shí)現(xiàn)方法，因此這意味著很多網(wǎng)站都不會(huì)對(duì)輸入請(qǐng)求的簽名進(jìn)行驗(yàn)證。
另一個(gè)訂閱支付服務(wù)提供商Recurly利用了HTTP基礎(chǔ)認(rèn)證來(lái)在服務(wù)器之間共享一個(gè)密鑰，現(xiàn)在可能有人又要問(wèn)了，難道驗(yàn)證共享密鑰就不麻煩了嗎…除此之外，Recurly還提供了一個(gè)IP地址列表，只有來(lái)自這個(gè)IP地址列表的Webhook請(qǐng)求才會(huì)被認(rèn)為是有效的。但是，這還遠(yuǎn)遠(yuǎn)不夠。比如說(shuō)，攻擊者可以創(chuàng)建一個(gè)單獨(dú)的Recurly賬號(hào)，然后發(fā)送有效但惡意的Webhook請(qǐng)求，這同樣會(huì)引起安全問(wèn)題。
漏洞線索
在測(cè)試跟支付相關(guān)的Webhook漏洞時(shí)，我們可以先對(duì)那些提供了月度訂閱服務(wù)的網(wǎng)站進(jìn)行分析，這是一條非常有效的線索，因?yàn)榻^大多數(shù)的支付服務(wù)提供商都沒(méi)有針對(duì)Webhook來(lái)實(shí)現(xiàn)足夠有效的安全保護(hù)。
下面我們給出幾種尋找Webhook節(jié)點(diǎn)的方法：
- 搜索跟“Webhook”或“payment”相關(guān)的JavaScript文件，很多支付網(wǎng)站可能會(huì)直接暴露內(nèi)部節(jié)點(diǎn);
- 搜索目標(biāo)組織的GitHub代碼庫(kù)或相關(guān)文檔，尋找關(guān)于Webhook的相關(guān)引用內(nèi)容;
- 大多數(shù)Webhook節(jié)點(diǎn)的數(shù)據(jù)格式可能都比較相似，所以我們可以嘗試訪問(wèn)不同的API節(jié)點(diǎn)來(lái)尋找Webhook節(jié)點(diǎn)，比如說(shuō)/api/stripe/webhook、/api/payments/webhook或/api/stripeWebhook。
總結(jié)
毫無(wú)疑問(wèn)，如果支付網(wǎng)站想要檢測(cè)任何可疑的網(wǎng)絡(luò)行為，那么驗(yàn)證支付Webhook請(qǐng)求絕對(duì)是要默認(rèn)進(jìn)行的。雖然有些支付提供商會(huì)給用戶提供一些方法來(lái)防止這種攻擊，但這仍然需要提供商和客戶的共同努力。
文章名稱：看我如何利用Webhook繞過(guò)支付請(qǐng)求
網(wǎng)站網(wǎng)址：http://www.dlmjj.cn/article/djogpso.html
