通过Web缓存欺骗攻击实现用户信息泄漏

Posted 2021-04-15 嘶吼专业版

概述

几天前，通过Web缓存欺骗攻击，我发现了一些用户信息泄漏的漏洞。在我们深入研究PoC之前，我想首先解释一下这些攻击方法及其影响。

Web缓存欺骗攻击是一种攻击方式，原因在于Web应用程序在使用缓存的过程中没有正确验证，从而允许攻击者实现缓存泄漏攻击。

在这样的场景中，后台的Web应用程序通常倾向于使用代理、CDN和其他服务来使用缓存功能。借助于这样的功能，可以减少服务器的响应时间，或者减少延迟，但在这一功能中并没有进行正确的验证。

我们假设有一个类似于www.example.com/home.php的网站，攻击者在这个URL的末尾尝试了一个额外的扩展，例如www.example.com/home.php/a.jpg。如果网站有缓存功能，那么它基本上会缓存网站内部信息，并将其存储在其缓存目录的上述端点上，扩展名可以是.css、.jpg、.js等任何类型。

一旦用户访问该URL，他们的信息将会被缓存，攻击者只需访问同样的端点，用户信息即可通过访问源代码的方式实现泄漏。

接下来，让我们跳到本文的重要部分。

初步尝试

在我参与一个漏洞挖掘计划中，我在其中发现了三个不同的木笔啊，分别是：app.example.com、example.com和manage.example.com。因此，大家也可以在example.com中注册并登录。

app.example.com主要用于开发APP，manage.example.com则是另一个Web应用程序，主要用于对Slack工作区域和其他服务进行身份验证。

因此，我们示例中的example.com是这样的：

所以，它是作为example.com加载的，但后来我看到没有缓存控制标头或任何内容，然后我决定进一步尝试验证。

需要注意的是，即使没有缓存控制，也并不意味着所有时间都会受到漏洞影响，具体的时间请参见本文末尾的关键点。

因此，我决定访问一个端点，例如：https://example.com/welcome.css

请注意，在这个404错误页面中，它仍然显示在我们的工作区域中，这意味着我们可以从中获取到一些信息。

在访问上面的URL之后，我们发现，只是以隐身模式访问了同一个端点。

但是在这里，出现了值得注意的一个地方，当我以隐身模式访问此端点时，会显示2-3秒“Go to your Workspace”提示，然后自动跳转到注册和登录界面。这一过程只有短短几秒。

由此我们推断，可能会话没有被正确缓存，所以它会弹出这样的提示并跳转到了注册和登录界面，但实际上它已经缓存了信息。所以，我们只需要访问view-source:https://example.com/welcome.css，看看是否有一些信息已经被缓存了。

答案是肯定的，信息已经被缓存，并且在这里面提供了所有的个人信息。

我们的第一部分就已经完成。在尝试example.com之后，我们尝试过访问app.example.com，但没有成功。

继续尝试

那么，我们接下来看看manage.example.com。

Manage.example.com是另一个Web应用程序，它允许用户连接他们的Slack工作区域，并且还可以用于使用API端点检索信息。

因此，当我尝试访问manage.example.com时，它会将我重定向到app.example.com。所以可以证明，在后端放置了一些路由规则。这也意味着，manage.example.com只能用于/api端点或/auth端点。

所以，我只是尝试简单地注入例如/a这样的路径，最终向我显示了如下的响应。

因此，这也意味着该网站在前端交互上存在着问题。

随后，我突然看到了响应标头，并且发现其中没有缓存控制标头。但我仍然感到困惑，并不清楚这一次是否会起作用。

因此，我尝试访问manage.example.com/hello.css等端点，得到了与之前相同的响应结果。

但是，当我以隐身模式访问同一个端点时，它会缓存信息，并使用活动会话模式向我显示相同的视图。

于是，我尝试通过view-source://manage.example.com/hello.css访问端点。这一次，与本文的第一部分（example.com）相比，已经能够缓存大量的信息。   

时间节点

2019年2月9日 提交报告；

2019年2月11日 安全团队对报告进行了分类；

2019年2月21日 得到300美元的奖励，并获得了安全团队积极的反馈。

关键点

在实际中，如果缺少缓存标头，并不意味着我们一定能实现缓存信息攻击。该攻击是否能够成功实现，还取决于后端路由实际上是如何工作的。

其次，即使添加了额外的参数，有时也可以登录那一页面，有时则会跳转到404错误页面。但是，如果在404错误页面的源代码中没有信息，那么就无法进一步利用。

在大多数情况下，企业都会使用API或Graphql端点来检索数据。因此，如果我们在隐身模式下看到会话但无法查看该页面源代码中的信息，就无法利用这一漏洞。只有我们的帐户名称会被泄漏，没有其它内容。

最后，我们要检查所有可能的地方，并反复分析，并考虑是否可以获得令牌（Token）或其它内容。如果可以获得，那么就可以与其它漏洞组合利用，从而实现更大程度的利用。