安全头条

综合

资讯

资料

【翻译】Web缓存投毒防御策略绕过

先知 2018-10-11

原文地址:https://portswigger.net/blog/bypassing-web-cache-poisoning-countermeasures

继上个月关于Web缓存投毒的演示文稿白皮书之后,各公司已部署防御措施以试图缓解缓存投毒攻击。在这篇文章中,我将介绍一些可以用来绕过它们的通用弱点。
这项研究引发了几家主要缓存供应商的响应。Akamai发布了一个简短的响应,令人迷惑地引用Web缓存欺骗的缓解措施,实际上它几乎没有阻止Web缓存投毒攻击。fastly发布安全公告,提供有关缓解的详细建议,Cloudflare更进一步,并采取全局性缓解措施,详见博客文章Cloudflare如何保护客户免受缓存投毒
让我们仔细看看Cloudflare部署的两个防御策略。第一个是向他们的WAF添加一个规则来阻止类似XSS的字符,比如我在研究中使用的某些请求头中的<,像在X-Forwarded-Host请求头中:

GET / HTTP/1.1
Host: waf.party
X-Forwarded-Host: xss<

HTTP/1.1 403 Forbidden

Attention Required!

这使得通过向这些请求头缓存投毒以直接获取XSS的方式变得更加困难,但正如他们所指出的那样,仍然会使一些应用程序容易受到攻击,因为漏洞并不总是需要这些字符。第二个更强大的缓解措施是将这些请求头添加到其默认缓存键中,理论上无法将这些请求头用于缓存投毒:

GET / HTTP/1.1
Host: waf.party
X-Forwarded-Host: evil.net

HTTP/1.1 200 OK

<a href="https://evil.net/"
修复前的缓存键https://waf.party/
修复后的缓存键:https://waf.party/|evil.net

不幸的是,这两种防御策略实际都存在严重的缺陷,这意味着它们可以被完全绕过。这种方法通过设置一个小优化级设置,这意味着如果Cloudflare匹配Host头,则不会将X-Forwarded-Host头添加到缓存键:

GET / HTTP/1.1
Host: waf.party
X-Forwarded-Host: waf.party
修复后的缓存键:https://waf.party/

致命的缺陷是Cloudflare只查看每个请求头的第一个实例,因此攻击者可以提供重复的请求头,第一个实例是无害的,第二个实例包含payload。当后端服务器处理此类请求时,它通常会使用逗号连接两个请求头的值。

GET / HTTP/1.1
Host: waf.party
X-Forwarded-Host: waf.party
X-Forwarded-Host: evil.net"/><script...

HTTP/1.1 200 OK

<a href="https://waft.party, evil.net"/><script...
修复后的缓存键:https://waf.party/

我上周向Cloudflare报告了这个问题,所以这个问题很快就会被修补,并且缓存键绕过现在已经修补了。虽然他们的修复最初并没有成功,但他们值得被赞扬作为唯一尝试技术修复的供应商,现在我的绕过已经修补了,我认为他们是具有最安全默认配置的供应商。也就是说,值得注意-通常来说Cloudflare的修复不会使Cloudflare托管的网站受缓存投毒的影响 - 因为它只能阻止使用常用的请求头攻击。
其他公司尝试修补也可能出错。一个常见的错误是发现缓存投毒攻击并使用已缓存的响应阻止它。这极有可能地造成了拒绝服务问题。这种危险也可能由WAF引起 - 例如www.tesla.com 使用WAF阻止任何请求头中包含字符串'burpcollaborator.net'的请求:

GET /en_GB/roadster HTTP/1.1
Host: www.tesla.com
Any-Header: burpcollaborator.net

HTTP/1.1 403 Forbidden

Access Denied. Please contact waf@tesla.com

在此次攻击之后,任何试图访问该页面的人都会发现自己被拒绝访问了:

GET /en_GB/roadster HTTP/1.1
Host: www.tesla.com

HTTP/1.1 403 Forbidden

Access Denied. Please contact waf@tesla.com

我见过的另一个错误发生在公司试图修补引入漏洞的框架,但低估了请求头的全部潜力。例如,一个站点将可接受的request.host变量值列入了白名单,该变量由X-Forwarded-Host请求头赋值。但是,他们没有注意到这个请求文件也可以向request.port变量赋值,从而导致持久的拒绝服务:

GET / HTTP/1.1
Host: redacted.com
X-Forwarded-Host: redacted.com:123

HTTP/1.1 301 Moved Permanently
Location: https://redacted.com:123/

最终,在特定的基础上修补Web缓存投毒可能很棘手,Web框架的作者是解决这些常见的问题的最好的人。像Django和Flask这样的框架近年来已经禁用了对这些请求头的支持,而像Ruby on Rails这样的其他框架已被反复警告,但最近才开始转向部署修复程序。
最后,我应该提一下,我将在周一发布的Param Miner中做出实质性更新,特别是包括默认禁用静态'fcbz'缓存爆破程序,因为它破坏了某些网站。这意味着当您使用浏览器或Repeater尝试缓存投毒时,您需要手动指定自己的缓存爆破值,否则可能会意外影响其他访问者。
祝你好运,保持安全!

全部评论()
邮箱
昵称
密码
确认密码
阅读并接受《用户协议》
使用其他方式登录
微信登陆 QQ登录