利用缓存欺骗获取他人敏感信息

大家好！

大约几天前，我在一个漏洞悬赏项目中利用Web缓存欺骗攻击成功获得他人敏感信息。这篇文章我将详细说明这次攻击流程。

在说明我的PoC之前，我想详细解释一下缓存欺骗攻击和其影响。

Web缓存欺骗攻击是由于Web应用未正确使用缓存功能而引起的，攻击者往往能获得缓存中的敏感数据。

在这种攻击场景下，后台的Web应用程序通常会利用代理、cdn和其他服务来实现缓存功能。一般来说，缓存功能可以有效减少服务器的工作负荷，缩短通信延迟，但很容易配置不当，形成漏洞。

假设有一个网址为www.example.com/home.php的网站，如果你在该URL的末尾附加一个额外的文件扩展，比如www.example.com/home.php/a.jpg，并且该网站具有缓存功能，那么它就会把这个请求的相关信息缓存到指定服务器的缓存目录下。当然，这个文件扩展名也可以是其他，例如.css，.jpg，.js等。

因此，一旦有用户访问了有漏洞的网站，并缓存了信息，那么攻击者就有机会通过访问同样的端点来获得受害者的信息。

main

上个星期，我参加了一个保密的渗透测试项目，遇到了三个不同的目标：

app.example.com

example.com

manage.example.com

测试者可以在example.com网站中注册并登录。

app.example.com网站主要涉及开发app；manage.example.com主要涉及其他服务的身份验证。

假设，example.com网站如下所示：

当如上页面加载时，我没有观察到有缓存控制的请求头。因此，我决定试一试。

我随意访问了一个端点https://example.com/welcome.css。

很正常，返回了404，但在这个404错误页面中，它仍然有一个“go to your workspace”（和session有关），这貌似是一个可利用标记。

接着，我以匿名模式访问了同一个端点。这时，它只显示了2到3秒的“Go to your Workspace”，然后就立马变成登录和注册界面。这些都在一瞬间完成。

我当时的表情：

也许，由于session没有被正确地缓存，所以有那么一瞬间，出现了“Go to your Workspace”，虽然立刻就变成了注册和登录页面，但这说明一些用户的敏感信息被缓存了。所以，让我们试试view-souce:https://example.com/welcome.css，看看能找到什么。

OK！我的敏感信息似乎已经完全被泄露了。

第1个网站完成

我立马试了试app.example.com，但这次运气不够好。

那么，试试最后一个manage.example.com

manage.example.com可让用户进入slack的工作区，同时还提供api来检索信息。

因此，当我尝试访问manage.example.com时，它会将我重定向到app.example.com，看起来服务器后端设置了路由规则。这意味着只能访问manage.example.com下的/api端点或/auth端点。

于是，我开始简单地尝试/a这样的路径，响应如下。

嗯，看样子好像是没什么希望了。

但是，我突然发现了HTTP请求中没有缓存控制头。那漏洞到底存在么？

我尝试访问像manage.example.com/hello.css这样的端点，结果响应与上面相同。

但是当我以匿名模式访问同一个端点时，它貌似缓存了信息，和正常模式下的页面视图相同。

最后，我尝试访问view-source://manage.example.com/hello.css端点，这一次，与example.com相比，更多的敏感信息被泄露。

时间线

2019年2月9日：提交报告。

2019年2月11日：审核报告。

2019年2月21日：报告通过，获得150美元+150美元的奖励。

总结

• HTTP请求头中缓存控制头的存在与否和是否有漏洞是两回事。还要考虑服务器后端路由的设置。

• 并不是404错误页面就代表漏洞存在，还和页面源码有关。

• 最后，仔细检查，一遍又一遍分析所有的发现，才是最重要的。

本文由白帽汇整理并翻译，不代表白帽汇任何观点和立场
来源：https://medium.com/@kunal94/web-cache-deception-attack-leads-to-user-info-disclosure-805318f7bb29