標題：在登錄OAuth 流程中使用”OAuth-dance”方法進行帳戶劫持（上）

'OAuth-dance”方法是什麼？

響應類型首先，你可以在OAuth-dance中使用不同的響應類型，最常見的三種是：

1.代碼+狀態。該代碼用於調用OAuth-provider 服務器端以獲取令牌。 state 參數用於驗證正確的用戶正在撥打電話。在對OAuth-provider進行服務器端調用之前，OAuth-client負責在服務器端調用OAuth-provider之前驗證狀態參數。

2.id_token。是使用來自OAuth-provider的公共證書籤名的JSON Web 令牌(JWT)，以驗證所提供的身份確實是它聲稱的身份。

3.token。是服務提供者的API 中使用的訪問令牌。

響應模式在OAuth-dance 中，授權流程可以使用多種模式向網站提供代碼或令牌，以下是四種最常見的模式：

1.Query，將查詢參數作為重定向發送回網站(https://example.com/callback?code=xxxstate=xxx)。用於“代碼+狀態”情況。該代碼只能使用一次，並且在使用該代碼時你需要OAuth 客戶端密鑰來獲取訪問令牌。不建議對令牌使用此模式，因為令牌可以多次使用，並且不應最終出現在服務器日誌或類似文件中。大多數OAuth-provider不支持令牌的這種模式，僅支持代碼。例如：

response_mode=query 被Apple 使用。

response_type=code 由Google 或Facebook 使用。

2.Fragment。使用Fragment重定向(https://example.com/callback#access_token=xxx)。在這種模式下，URL 的Fragment部分不會出現在任何服務器日誌中，只能使用javascript訪問客戶端。此響應模式用於令牌。如下所示：

response_mode=fragment 被Apple 和Microsoft 使用；

response_type 包含id_token 或token，由Google、Facebook、Atlassian 和其他人使用。

3.Web-message。使用postMessage 到網站的固定來源：

postMessage('{'access_token':'xxx'}','https://example.com')

如果支持，它通常可以用於所有不同的響應類型。如下所示：

response_mode=web_message 由Apple 使用。

redirect_uri=storagerelay://. 被Google 使用。

redirect_uri=https://staticxx.facebook.com/./connect/xd_arbiter/. 被Facebook 使用。

4.Form-post。使用表單發佈到有效的redirect_uri，一個常規的POST-request被發送回網站。這可用於代碼和令牌。如下所示：

response_mode=form_post 由Apple 使用。

ux_mode=redirectlogin_uri=https://example.com/callback 由Google 登錄(GSI) 使用。

一些OAuth 提供商通過圍繞OAuth-dance 提供完整的SDK 包裝器來簡化OAuth 流程，例如Google 的GSI。這與id_token 的常規OAuth 流程完全一樣。令牌通過form-POST 或postMessage 發送回網站。

通過postMessage 竊取令牌我一直在尋找與postMessage 實現相關的漏洞。我構建了一個Chrome 擴展程序來偵聽消息並簡化檢查每個選項卡中所有窗口的所有postMessage 偵聽器。雖然如今在這些偵聽器中很少發現簡單的XSS 問題，但來源檢查較弱或沒有來源檢查的問題仍然很常見。然而，在很多情況下，能夠繞過起源檢查並沒有任何真正的影響。

我們認為將會有帶有弱源檢查或沒有源檢查的postMessage偵聽器，它們會洩漏location.href，這是你當前訪問的網站的URL。它將直接或間接洩漏到我可能能夠捕獲它的其他地方。

例如，在常規起始頁上，這可能看起來並不重要，但是如果我可以嘗試讓OAuth 代碼或令牌登陸具有這些弱postMessage 偵聽器之一的網站頁面。然後，我將能夠通過從不同的選項卡發送消息並取回location.href 來從偵聽器獲取令牌，並且我將能夠竊取OAuth 令牌，而無需任何XSS。

這種竊取當前URL 的方法對於其他具有與OAuth-dance 無關的敏感URL 的地方當然很有趣，但感覺使URL 敏感的最常見方法是關注登錄流程。

為了開始調查，我決定：

1.瀏覽運行漏洞賞金的熱門網站上的所有登錄流程。

2.如果他們使用任何第三方OAuth-provider，請保存他們使用的登錄URL，其中包含所有提供程序的客戶端ID、響應類型/模式和重定向uri。

3.如果網站上加載了任何有趣的postMessage 偵聽器或任何其他第三方腳本，要注意。

4.嘗試將這個耗時的想法稱為“Project Dirty OAuth-Dancing”。

5.打開Bill Medley Jennifer Warnes 並開始使用。

在收集網站使用OAuth-provider的所有不同方式時，很明顯有一些可能的選擇和組合，不同的網站決定使用不同的回應類型和模式組合。完成後，我能夠將注意力集中在最流行的OAuth-provider上，然後看看我是否可以基於其他限定符過濾網站

使用OAuth-dance 時要注意的坑在成功使用OAuth-dance後，令牌會從網站的URL 中刪除。確保網站未正確使用代碼或令牌是使此攻擊起作用的第一步，因為我想自己竊取和使用代碼或令牌。

這可能會產生各種結果，但我們的想法是最終出現某種形式的錯誤頁面或類似的仍然加載第三方javascript 以便我們洩露令牌的頁面。

有多種方法可以打破OAuth-dance。這些使OAuth-dance無效的方法本身沒有任何影響，但如果受害者最終將代碼或令牌仍然放在URL中，並與location.href-leak 鏈接在一起，它們就變得很重要。

故意對“狀態”進行攻擊OAuth規范建議將狀態參數與response_type=code結合使用，以確保啟動流程的用戶也是在OAuth-dance 之後使用代碼來發布令牌的用戶。

但是，如果狀態值無效，代碼將不會被使用，因為驗證狀態是網站的責任。這意味著，如果攻擊者可以向具有有效攻擊狀態的受害者發送登錄流鏈接，那麼受害者的oaut -dance將失敗，代碼將永遠不會發送給OAuth-provider。如果攻擊者可以得到它，該代碼仍然可以使用。

1.攻擊者使用“使用X 登錄”在網站上啟動登錄流程。

2.攻擊者使用狀態值並為受害者構建一個鏈接，讓他們用OAuth-provider登錄，但使用攻擊者的狀態。

3.受害者使用該鏈接登錄並重定向回該網站。

4.網站驗證受害者的狀態並停止處理登錄流程，因為它不是一個有效狀態。受害者的錯誤頁面。

5.攻擊者找到了從錯誤頁面洩漏代碼的方法。

6.攻擊者現在可以使用自己的狀態和受害者洩露的代碼登錄。

響應類型/響應模式切換改變OAuth-dance的響應類型或響應模式將影響代碼或令牌返回網站的方式，這在大多數情況下會導致意想不到的行為。我還沒有看到任何OAuth-provider有限製網站想要支持的響應類型或模式的選項，所以根據OAuth-provider的不同，通常至少有兩種或更多的OAuth-provider可以在嘗試以不滿意的方式結束時進行更改。

還可以請求多個響應類型。有一個規範解釋了當請求多個響應類型時，如何向redirect-uri提供值：

如果在一個請求中，response_type只包含要求服務器返回在查詢字符串中完全編碼的數據的值，那麼這個多值response_type的響應中返回的數據必須在查詢字符串中完全編碼。此建議同時適用於成功響應和錯誤響應。

如果在一個請求中，response_type包含任何要求服務器返回在片段中完全編碼的數據的值，那麼響應中這個多值response_type返回的數據必須在片段中完全編碼。此建議同時適用於成功響應和錯誤響應。

如果正確地遵循了這個規範，這意味著你可以要求發送到網站的代碼參數，但如果你同時也要求id_token，代碼參數將在Fragment部分而不是在查詢字符串中發送。

對於Google 的登錄，這意味著：

將重定向到https://example.com/callback?code=xxxstate=yyy。但是：

將重定向到https://example.com/callback#code=xxxstate=yyyid_token=zzz。

如果你使用以下方法，同樣的想法也適用於Apple：

你將被重定向到https://example.com/callback?code=xxxstate=yyy，但是：

會將你重定向到https://example.com/callback#code=xxxstate=yyyid_token=zzz。

Redirect-uri大小寫轉換一些OAuth-provider允許在redirect_uri 的路徑中進行大小寫轉換，而不是真正遵循保護基於重定向的流程規範：

在將客戶端Redirect-uri與預註冊的URI 進行比較時，授權服務器必須使用精確的字符串匹配，本地應用程序的localhost Redirect-uri中的端口號除外。該措施有助於防止授權代碼和訪問令牌的洩漏，它還可以幫助檢測混淆攻擊。

這意味著，將https://example.com/callback 作為應用程序的配置重定向uri，以下流程仍然有效：

並將你重定向到：https://example.com/CaLlBaCk#id_token=xxx。我測試過的所有網站都沒有使用不區分大小寫的路徑，因此大小寫轉換觸發了不太順暢的路徑，顯示錯誤或重定向到仍然存在Fragment的登錄頁面。

另請注意，使用response_type=code 這個方法更難被利用。在一個正確的OAuth-dance使用代碼中，在從服務提供者獲取訪問令牌的最後一步中，還必須提供redirect_uri 以向服務提供者進行驗證。如果OAuth-dance中使用的redirect_uri 與網站發送給提供者的值不匹配，則不會發出訪問令牌。但是，使用任何其他響應類型，例如token 或id_token，都不需要最後一步的驗證，因為token是在重定向中直接提供的。

增加Redirect-uri路徑

一些OAuth-provider允許將其他數據添加到redirect_uri 的路徑中。這也以與“Redirect-uri case shift”相同的方式破壞了規範。例如，有一個https://example.com/callbackredirect uri，發送一下內容：

最終會重定向到https://example.com/callbackxxx#id_token。這已報告給受影響的供應商。此處適用與大小寫轉換相同的事情，對於response_type=code 這將不允許你發出令牌，因為在最後一步從提供者獲取令牌時會比較正確的redirect_uri。

增加Redirect-uri參數附加一些OAuth-provider允許向redirect_uri添加額外的查詢或Fragment參數。你可以通過提供將附加到URL的相同參數來觸發一個不太好用的路徑來使用它。例如，有一個https://example.com/callbackRedirect-uri，發送以下內容：

在這些情況下會被重定向到https://example.com/callback?code=xxxcode=real-code。根據網站接收多個相同名稱的參數，這也可能會觸發一個不太好用的路徑。同樣適用於token和id_token：

結果是https://example.com/callback#id_token=xxxid_token=real-id_token。根據javascript在有多個相同名稱的參數時獲取Fragment參數，這也可能會以一個不太好用的路徑結束。

Redirect-uri多餘內容或錯誤配置在收集所有包含redirect_uri值的登錄url時，我還可以測試其他重定向uri值是否也有效。在我測試的網站上保存的125個不同的谷歌登錄流程中，有5 個網站的起始頁也是有效的redirect_uri。例如，如果使用了redirect_uri=https://auth.example.com/callback，那麼在這5 種情況下，其中任何一種都是有效的：

redirect_uri=https://example.com/

redirect_uri=https://example.com

redirect_uri=https://www.example.com/

redirect_uri=https://www.example.com

這對於實際使用id_token或token的網站來說特別有趣，因為response_type=code仍然會讓OAuth-provider在獲取令牌時在OAuth-dance的最後一步驗證redirect_uri。

我最終找到了許多不太好用的路徑。怎麼辦？

我現在已經為所有網站收集了一堆不太好用的路徑。以下是我看到的不同案例：

1.最後出現在錯誤頁面上。

2.重定向到網站的起始頁。

3.重定向回登錄頁面。

4.重定向回已刪除參數的登錄頁面。

5.重定向回OAuth-provider，但具有正確的值，具有正確的響應類型和狀態，基本上識別流程無效並重試它。

我們計劃專注於1、2和3，因為它們的參數仍然保存在URL中。我還得出結論，避免不太好用路徑的最佳方案是第4條。

現在是時候真正開始尋找洩露信息的方法了。我仍然沒有發現真正的漏洞。

由於postMessage-listener擴展還記錄頁面上的任何iframe是否有偵聽器，所以我開始關注那些在URL中有令牌的窗口的任何框架中至少有一個postMessage-listener的網站。

URL 洩漏小工具

我會將洩漏URL 的不同方法歸類為不同的小工具，因為它們具有不同的屬性讓我們回顧一下我已經確定的不同類型的方法。

小工具1：洩漏URL 的弱或沒有源檢查postMessage-listeners

這是預期的。一個示例是加載到網站上的流行網站的分析SDK：

此SDK 公開了一個postMessage-listener，當消息類型匹配時，它會發送以下消息：

從不同的來源向它發送消息：

響應消息將顯示在發送包含網站location.href 消息的窗口中：

可用於攻擊的流程取決於代碼和令牌用於登錄流程的方式，但攻擊場景是：

1.攻擊者向受害者發送一個精心製作的鏈接，該鏈接已準備好導致OAuth-dance 中的一條不太好用的路徑。

2.受害者點擊鏈接。新選項卡將打開一個登錄流程，其中包含正在被利用的網站的一個OAuth-provider。

3.在被利用的網站上觸發了不太好用的路徑，易受攻擊的postMessage-listener 被加載到受害者登陸的頁面上，仍然在URL 中包含代碼或令牌。

4.攻擊者發送的原始tab 發送一堆postMessages-到帶有網站的新tab 以獲取postMessage-listener 以洩漏當前URL。

5.攻擊者發送的原始標籤，然後偵聽發送給它的消息。當URL在消息中返回時，代碼和令牌將被提取並發送給攻擊者。

6.攻擊者使用最終在不太好用路徑上的代碼或令牌以受害者身份登錄。

小工具2：獲取URL 的沙盒/第三方域上的XSS

我們會在下一篇文章種介紹小工具2、小工具3，以及洩露URL 的其他途徑。