在登录 OAuth 流程中使用”OAuth-dance”方法进行帐户劫持（下）

我们在中介绍了响应类型，如何通过 postMessage 窃取令牌以及小工具1，本文接着讲小工具2、小工具3，以及泄露 URL 的其他途径。

我在 5 月 12 日报告了使用这个小工具在野外发现的第一条链：

巧合的是，两天后的 5 月 14 日，Youssef Sammouda 发表了一篇很棒的博文，解释了他接管使用 Gmail 的 Facebook 帐户的方法。这篇博文描述了我发现的类似流程。但是，该错误并不是要破坏 OAuth-dance，而是通过使用允许加载任意 javascript 的 iframe:d 沙盒域来泄露受害者最终访问的 URL。沙盒访问 URL 中的敏感数据的原因是它在加载 iframe 时附加到沙盒 URL。

不过，我发现的案例有点不同。

第一个是在OAuth-dance结束的页面上加载iframe。iframe是window.location-object的json字符串版本。这是一种旧的跨域传输数据的方法，因为iframe中的页面可以得到由父节点设置的自己的window.name：

在iframe中加载的域也有一个简单的XSS：

正如Youssef解释的那样，如果你在一个窗口的一个域上有一个XSS，那么如果窗口之间存在父/子/开启者关系，则该窗口可以到达同源的其他窗口。

在示例中，我做了以下操作：

1.创建了一个恶意页面，该页面嵌入了沙盒的 iframe，XSS 加载了我自己的脚本：

2.在沙盒中加载脚本时，我将内容替换为受害者使用的链接：

我还启动了一个脚本，以检查链接是否已打开，并且我想访问的 iframe 是否存在以获取 iframe 上设置的 window.name 与攻击者页面上的 iframe 相同的来源：

3.然后，攻击者页面可以只侦听我们刚刚发送的带有 window.name 的消息：

第二个示例是使用 postMessage 将 iframe 加载到具有 XSS 的不太好用的路径上，但仅允许来自加载它的父窗口的消息。当它在给父窗口的消息中请求 initConfig 时，location.href 被发送到 iframe。

主窗口像这样加载 iframe：

内容如下所示，这比实际情况要简单得多，只是为了更好地解释攻击：

在这种情况下，我可以执行与第一个示例类似的方法：

1.创建一个嵌入沙盒 iframe 的恶意页面，附加 onload 以在加载 iframe 时触发脚本。

2.由于恶意页面是 iframe 的父级，它可以向 iframe 发送消息以使用 postMessage 将我们的脚本加载到沙盒的来源：

3.在沙盒中加载脚本时，我将内容替换为受害者的链接：

我还启动了一个脚本，以检查链接是否已打开以及我想要访问的 iframe 是否存在，以便在其中运行 javascript 从我的 iframe 到主窗口。然后，我在恶意窗口中附加了一个 postMessage 侦听器，该侦听器将消息传递回我的 iframe：

4.加载了 iframe 的攻击者页面然后可以在主窗口的 iframe 中侦听我从注入的 postMessage-listener 代理发送的消息：

小工具 3：使用 API 获取越界 URL

这个小工具原来是最有趣的。把受害者送到某个地方然后从另一个地方获取敏感数据，这让人很满意。

第一个示例使用外部服务来跟踪数据。该服务添加了一个存储框架：

主窗口将使用 postMessage 与此 iframe 对话，以发送跟踪数据，这些跟踪数据将保存在 storage.html 所在的源的 localStorage 中：

主窗口也可以获取以下内容：

当 iframe 在初始化时加载时，使用 location.href 为用户的最后一个位置保存了一个项：

如果你能以某种方式与这个来源对话，并让它向你发送内容，那么 location.href 可以从这个存储中获取。该服务的 postMessage-listener 有一个阻止列表和一个来源的允许列表。分析服务似乎允许网站定义允许或拒绝的来源：

此外，如果你有一个基于 allowList 的有效来源，你还可以请求同步，这将在此窗口中向你发送对 localStorage 所做的任何更改。

在将这个存储加载到 OAuth-dance 的不太好用路径上的网站上，没有定义 allowList-origins；如果源是窗口的父级，这允许任何源与 postMessage-listener 对话。该方法类似于小工具2：

1.我创建了一个恶意页面，该页面嵌入了存储容器的 iframe，并附加了一个onload，以便在加载iframe时触发脚本。

2.由于恶意页面现在是iframe的父页面，并且在allowList中没有定义任何起源，因此恶意页面可以向iframe发送消息，告诉存储发送对存储的任何更新的消息。我还可以向恶意页面添加一个侦听器，以侦听存储中的任何同步更新：

3.恶意页面还包含一个供受害者点击的常规链接：

受害者会点击该链接，通过 OAuth-dance，最终进入加载跟踪脚本和存储 iframe 的不太好用路径。存储 iframe 获取 last-url 的更新。自从 localStorage 更新以来，window.storage-event 将在恶意页面的 iframe 中触发，并且每当存储更改时，当前正在获取更新的恶意页面将获得带有受害者当前 URL 的 postMessage：

由于分析服务本身有一个漏洞赏金，我也有兴趣看看我是否可以找到一种方法来泄露已经为 storage-iframe 配置正确来源的网站的 URL。

当我开始在线搜索没有客户部分的 cdn.analytics.example.com 域时，我注意到这个 CDN 还包含服务客户上传的图像：

我还注意到这个 CDN 上有 SVG 文件作为 Content-type: image/svg+xml 内联提供：

我在该服务上注册为试用用户，并上传了我自己的资产，该资产也出现在 CDN 上：

有趣的是，如果你随后将特定于客户的子域用于 CDN，则仍然会提供图像。URL如下：

这意味着 ID #94342 的客户可以在客户 #12345 的存储中呈现 SVG 文件。

我上传了一个带有简单 XSS 有效负载的 SVG 文件：

效果不是很好。CDN 为 img/ 下的所有内容添加了 Content-Security-Policy: default-src 'self'-header。你还可以看到提到 S3 的服务器标头，这表明内容已上传到 S3 存储桶：

S3 的一个有趣的事情是目录在 S3 中并不是真正的目录。项之前的路径称为“前缀”。这意味着 S3 不关心 / 是否经过 url 编码，如果你对 URL 中的每个斜杠进行 url 编码，它仍然会提供内容。如果我在 URL 中将 img/ 更改为 img%2f ，仍然可以解析图像。但是，在这种情况下，CSP-header 被删除并触发了 XSS：

然后我可以上传一个 SVG，该 SVG 将创建与常规 storage.html 相同形式的存储处理程序和 postMessage-listener，但允许列表为空。即使在正确定义了可以与存储通信的允许来源的网站上，这也使我能够进行相同类型的攻击。

我上传了一个看起来像这样的 SVG：

然后我可以使用与示例 #1 中相同的方法，但我可以使用 url 编码的斜杠 iframe 而不是 iframe 的 storage.html：

由于没有网站能够自行修补此问题，因此我向负责 CDN 的分析提供商发送了一份报告：

在第三方上查看错误配置产生漏洞的整个想法主要是确认有多种方法来实现令牌的泄漏，并且由于第三方有漏洞赏金，这只是同一种漏洞的不同接收者，不同之处在于影响是针对分析服务的所有客户。在这种情况下，第三方的客户实际上有能力正确配置该工具，使其不会将数据泄露给攻击者。然而，由于敏感数据仍被发送给第三方，所以看看是否有某种方法可以完全绕过客户对工具的正确配置是很有趣的。

最后一个例子是基于一个出现在网站所有页面上的聊天小工具，甚至是错误页面。有多个 postMessage 侦听器，其中一个没有适当的来源检查，只允许你启动聊天弹出窗口。另一个侦听器对聊天小工具进行了严格的来源检查，以接收初始化调用和当前用户使用的当前聊天 API 令牌。

聊天 iframe 加载时：

1.如果 chat-api-token 存在于 chat-widget 的 localStorage 中，它将使用 postMessage 将 api-token 发送给其父级。如果没有 chat-api-token 存在，它不会发送任何东西。

2.当 iframe 加载后，它会向其父级发送一个带有 {"type": "chat-widget", "key": "init"} 的 postMessage。

如果你点击主窗口中的聊天图标：

1.如果chat-api-令牌还没有被发送，那么chat-widget会创建一个令牌，并将其放在自己的源的localStorage中，并将其postMessage发送给父窗口。

2.然后父窗口将对聊天服务进行 API 调用。API 终端被 CORS 限制为为服务配置的特定网站。你必须使用 chat-api-token 为 API 调用提供有效的 Origin-header 以允许发送请求。

3.来自主窗口的 API 调用将包含 location.href 并使用 chat-api-token 将其注册为访问者的“当前页面”。然后，响应将包含一些令牌，以连接到一个websocket来启动聊天会话：

在这个例子中，我意识到 chat-api-token 的通知总是会通知给 chat-widget iframe 的父级，如果我得到了 chat-api-token，我可以使用令牌，然后将我自己的人工 Origin-header 添加到 API 调用中，因为 CORS-header 仅对浏览器很重要。这导致了以下进程：

1.创建了一个嵌入聊天小工具 iframe 的恶意页面，添加了一个 postMessage-listener 来侦听 chat-api-token。此外，如果在 2 秒内没有获得 api-token，则会触发重新加载 iframe 的事件。这是为了确保我也支持从未发起聊天的受害者，并且由于我可以触发远程打开聊天，我首先需要 chat-api-token 开始轮询聊天 API 中的数据服务器端。

2.添加了指向恶意页面的链接以打开登录流程，该流程最终将出现在带有 URL 中带有令牌的聊天小工具的页面上：

3.如果打开，launchChatWindowByPostMessage() 函数将持续向主窗口发送 postMessage 以启动聊天小工具：

4.当受害者点击链接并最终进入错误页面时，聊天将启动并创建一个 chat-api-token。我在恶意页面上重新加载聊天小工具 iframe 将通过 postMessage 获取 api-token，然后我可以开始在 API 中查找受害者的当前 url：

5.https://fetch-server-side.attacker.test/?token=xxx 的服务器端页面将使用添加的 Origin-header 进行 API 调用，以使 Chat-API 认为我将其用作合法起源：

6.当受害者点击链接并通过 OAuth-dance 并进入添加了令牌的错误页面时，聊天小工具会突然弹出，注册当前 URL，攻击者将获得受害者的访问令牌。

还有其他不同类型的小工具等着我们去发现，虽然我无法在野外找到的一个案例，但可能是使用任何可用的响应模式获取URL泄漏的一种潜在方法。

由于所有web_message响应类型都不能验证源的任何路径，所以有效域上的任何URL都可以接收到带有令牌的postMessage。如果在域上的任何页面上有某种形式的postMessage-listener代理，它接收发送给它的任何消息，并将所有内容发送到它的开启者，我可以创建一个double-window.open 链：

攻击者页面 1：

攻击者页面 2：

而 https://example.com/postmessage-proxy 将具有以下内容：

我可以使用任何 web_message-response 模式将令牌从 OAuth-provider提交到 https://example.com 的有效来源，但终端会将令牌进一步发送到攻击者页面的开启者。

此流程似乎不太可能，它需要两次点击：一次是在攻击者和网站之间创建一个开放关系，第二次是启动 OAuth 流程，将合法网站作为 OAuth 弹出窗口的开启者。

OAuth-provider将令牌发送到合法来源：

合法的来源有 postMessage-proxy 到它的开启者：

这导致攻击者获取令牌：

如上所述，目前仍有许多不同的方法可以窃取这些代币。

由于每个 OAuth-provider都允许许多不同的响应类型和模式，因此网站要涵盖所有不同的情况是不可能的。

至于具体的缓解措施，可以参考《OAuth 2.0 安全当前最佳实践》。比如，OAuth授权响应和授权终端呈现的页面不应该包括第三方资源或到外部站点的链接。

另外，我认为作为一个OAuth-client，能够只启用你从OAuth-provider中实际支持的响应类型和模式是一个解决方案。这样你就可以限制你知道你支持的流程。一些oauth -provider实际上只支持一种响应类型，比如GitHub。

当 SPA 请求 Access Tokens，通常的 Authorization Code Flow 无法安全的存储 Client Secret，因为源代码在浏览器中运行，无法保证安全。为了解决上面的问题，OAuth 2.0 提供了基于 Authorization Code Flow 的版本，称之为 Proof Key for Code Exchange (PKCE)。

PKCE 增强的授权码流引入了一个由调用应用程序（SPA）创建的密钥，该密钥可由授权服务器验证。这个密钥被称为 Code Verifier（代码验证器）。此外，调用应用程序为 Code Verifier 创建一个转换值，称为 Code Challenge ，并通过 HTTPS 发送该值（Code Challenge）去检索 Authorization Code。使用这种方法，恶意攻击者只能拦截到 Authorization Code，因为恶意攻击者没有 Code Verifier 因此无法从认证服务器获取 token。

PKCE不是很有效，如上所述，攻击者准备了一个到OAuth-provider的链接供受害者使用。该链接将成功地在OAuth-provider中发出代码，将其与攻击者提供的code_challenge连接起来，但有意地在OAuth-client的网站上结束一个不太好用的路径;例如使用“故意中断状态”方法。当带有代码的URL泄露给攻击者时(如果错误页面上有小工具)，攻击者可以使用该代码，因为用于code_challenge的是攻击者的代码验证器。

了解OAuth-dance时会出现什么样的页面，比如异常或错误页面，如果OAuth-dance预期的任何参数错误或缺失，这些页面将被触发并显示在流程中。

确保这些页面没有使用任何第三方脚本。你现在可能不使用任何易受攻击的第三方脚本，但是如果你的组织中有人通过谷歌标签管理器或类似的工具引入了任何新内容，或者如果第三方脚本发生了更改，你可以防止任何潜在令牌泄漏。

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