导语：目前，随着安全意识的逐渐普及，越来越多的用户开始使用多种保管箱、管理器来帮助存储不同网站的不同密码。那么，这些密码存储软件是否足够安全呢？ 在研究过程中，我发现在与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对象以及与可用记录相关的其他信息。
没有网络安全，就没有国家安全
① 200多本网络安全系列电子书 ② 网络安全标准题库资料 ③ 项目源码 ④ 网络安全基础入门、linux、web安全、攻防视频 ⑤ 网络安全学习路线
免费领取私信”安全“
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。
对于第一种技术，需要通过注入的来加载外部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漏洞。
如若转载，请注明出处：https://www.dasum.com/4450.html