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

41yf1sh Web安全 2019年3月18日发布
Favorite收藏

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

概述

几天前,通过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是这样的:

1.png

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

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

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

2.png

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

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

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

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

3.png

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

我们的第一部分就已经完成。在尝试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这样的路径,最终向我显示了如下的响应。

4.png

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

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

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

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

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

5.png

时间节点

2019年2月9日 提交报告;

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

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

关键点

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

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

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

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

本文翻译自:https://medium.com/@kunal94/web-cache-deception-attack-leads-to-user-info-disclosure-805318f7bb29如若转载,请注明原文地址: https://www.4hou.com/web/16506.html
点赞 0
web
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论