"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=xxx&state=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=redirect&login_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=xxx&state=yyy。但是：

将重定向到 https://example.com/callback#code=xxx&state=yyy&id_token=zzz。

如果你使用以下方法，同样的想法也适用于 Apple：

你将被重定向到 https://example.com/callback?code=xxx&state=yyy，但是：

会将你重定向到 https://example.com/callback#code=xxx&state=yyy&id_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/callback redirect uri，发送一下内容：

最终会重定向到 https://example.com/callbackxxx#id_token。这已报告给受影响的供应商。此处适用与大小写转换相同的事情，对于 response_type=code 这将不允许你发出令牌，因为在最后一步从提供者获取令牌时会比较正确的 redirect_uri。

增加Redirect-uri参数附加

一些OAuth-provider允许向redirect_uri添加额外的查询或Fragment参数。你可以通过提供将附加到URL的相同参数来触发一个不太好用的路径来使用它。例如，有一个https://example.com/callback Redirect-uri，发送以下内容：

在这些情况下会被重定向到https://example.com/callback?code=xxx&code=real-code。根据网站接收多个相同名称的参数，这也可能会触发一个不太好用的路径。同样适用于token和id_token：

结果是https://example.com/callback#id_token=xxx&id_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 的其他途径。

参考及来源：https://labs.detectify.com/2022/07/06/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/