Web 缓存欺骗攻击技术详解 Secer's Blog - 记录互联网安全历程与个人成长经历

导语：Omer Gil早在今年年初就在他的博客上发表了有关于Web缓存欺骗攻击技术的博文，随后他在BlackHat USA 2017 和 BSides Tel-Aviv 2017 上对这种攻击技术进行了演示，并做了更深入的研究。

前言

Omer Gil早在今年年初就在他的博客上发表了有关于Web缓存欺骗攻击技术的博文，随后他在BlackHat USA 2017 和 BSides Tel-Aviv 2017 上对这种攻击技术进行了演示，并做了更深入的研究。

在他发布的“Web 缓存欺骗技术白皮书”中，详细的介绍了这种攻击技术。这份白皮书大致包含了如下内容：

·攻击原理概述

·实施攻击的方法

·攻击所需的条件

·已知的几个主流的Web 框架及缓存机制

·缓解措施

Web缓存欺骗这种攻击技术比较新颖危害也比较大，利用这种攻击技术攻击者可以泄露服务器上存储的用户敏感信息，甚至拿到用户的账户权限。当然，这种攻击技术与目标网站所使用的框架，缓存机制等因素有关。

介绍

关于缓存机制

大多数网站为了使网页加载速度变快从而为用户提供更好的用户体验，都使用了网页缓存，这些缓存的机制是将应用程序的文件存储在缓存服务上，在用户发起请求时进行频繁的检索。

最常见的一些需要缓存的文件都是静态文件，比如.css,.js,.txt以及图片文件。实现缓存的方式也有很多，比如浏览器自身就会进行缓存，但是这种缓存并不能进行Web缓存欺骗攻击。但是另外一些在浏览器与web服务器之间实现缓存的方式则可能存在这种安全漏洞。这种缓存实现机制有多种形式：

· CND（内容分发网络）：这是一种代理的分布式网络，其目的是快速地提供内容。客户端将由一组离它最近的代理服务器提供服务。

·负载均衡：除了平衡多个服务器之间的通信量外，负载均衡还可以缓存内容，以减少服务器的延迟。

· 反向代理：代理服务器代表客户端从web服务器检索资源，同时可以缓存web应用程序的一些内容。

缓存是如何工作的？

回顾了不同形式的缓存机制后，现在，我们来看看Web缓存实际上是如何工作的。在以下示例中，http://www.example.com网站由反向代理提供缓存服务。像其他任何网站一样，这个网站使用了图片，CSS文件和脚本作为公开使用的资源。这些文件网站中所有或许多用户所使用的静态文件，并且对所有用户返回了完全相同的内容。它们不包含任何用户信息，因此不会被认为是敏感的文件。

第一次访问静态文件时，请求会通过代理服务。缓存机制并不熟悉这个文件，于是它会询问Web服务器，Web服务器返回了该文件。现在，缓存机制需要识别接收到的文件的类型。每个缓存机制的工作方式不同，但是在大多数情况下，服务器是从URL的尾端来获取文件的扩展名，然后根据该缓存机制的缓存规则来决定是否缓存这个文件。

如果文件被缓存了，那么下一次当有任何一个客户端请求该文件时，缓存机制由于已经存储了这个文件，所以它会把缓存的文件内容发送给客户端而不需要去请求Web服务器。

服务器的反应

Web缓存欺骗攻击与RPO攻击相同。（在这两个博文中有说明：Spanner1和XSS Jigsaw2）依赖于类似浏览器和Web服务器的反应，。

当用户访问下面的URL时会发生什么？

http://www.example.com/home.php/nonexistent.css

home.php 是一个真实的网页，nonexistent.css是一个并不存在的文件。

在这种情况下，浏览器向该URL发送GET请求。有趣的是，Web服务器如何解释这个请求呢。根据服务器的技术选型和配置，Web服务器可能会返回一个200 OK的响应以及home.php页面的内容，这意味着URL保持不变。

HTTP响应头将匹配home.php的页面：相同的缓存头和相同的内容类型（在这种情况下为text / html）。

攻击原理概述

未经过身份验证的攻击者可以轻松的利用此漏洞，攻击步骤如下面所示：

1.攻击者诱使已经登录的用户访问https://www.bank.com/account.do/logo.png。

2.受害者的浏览器请求https://www.bank.com/account.do/logo.png。

3.请求到达代理，代理服务并不熟悉该文件，因此会请求Web服务器。

4. Web服务器返回受害者的帐户页面的内容，并显示200 OK响应，这意味着URL保持不变。

5.缓存机制接收到文件同时发现URL以静态文件的扩展名（.png）结尾。因为该缓存机制被配置为缓存所有静态文件并忽略任何缓存头，所以imposter.png文件会被缓存。名为account.do的新目录是在缓存目录中创建的，被缓存的文件名称为logo.png。

6.用户接收到他的帐户页面。

7.攻击者访问https://www.bank.com/account.do/logo.png。请求到达代理服务器，代理服务器直接将受害者的缓存帐户页面返回给了攻击者的浏览器。

漏洞危害

成功利用该漏洞将导致易受攻击的页面（包含用户的个人隐私内容）被缓存，从而可以被公开访问。这里的演示是缓存了静态类型的文件; 攻击者不能模仿受害者。所以，该文件不能被覆盖，并能保持一直有效，直到缓存到期。

如果响应的主体中包含了用户的会话标识符，账户安全问题，CSRF令牌等，则该漏洞的影响可能会明显提升。这可以用于额外的攻击，并导致受害者的帐户被攻击者完全接管。

实现攻击的条件

必须满足下面三个条件才能使攻击者发起网页缓存欺骗攻击：

1.访问http://www.example.com/home.php/nonexistent.css页面时，Web服务器返回了该URL的home.php的内容。

2. Web缓存功能被设置为通过Web应用程序的URL的扩展名来判断是否进行缓存文件，并且忽略任何缓存头。

3.访问恶意URL时，受害者必须已经经过了身份验证。

该漏洞在几个已知的WEB框架中的利用

实现攻击的一个条件是应用程序对现有的URL请求的解释，在最后添加一个不存在的文件的名称，如http://www.example.com/home.php/nonexistent.css。

以下示例显示了如何在几个已知的Web框架中执行这个漏洞的利用，包括其默认行为的概述，以及配置和工作流程的说明。

PHP

通过在不使用框架的情况下创建“纯”PHP应用程序，应用程序将忽略URL尾部的任何添加，并返回200 OK响应以及实际页面的内容。

例如，当访问http://www.example.com/login.php/nonexistent.gif时，应用程序返回login.php的内容，这意味着它符合第一个攻击条件。

Django

Django中的请求通过使用urls文件实现程序调度。在这些文件中，可以设置正则表达式来识别URI中请求的资源并返回相关的内容。

这是一个常见的配置方式，它可以返回诸如http://www.sampleapp.com/inbox/之类的请求的“inbox”页面的内容。

此正则表达式也会匹配到添加了一个不存在的文件的相同的URL，如

http://www.sampleapp.com/inbox/test.css。这个正则表达式的匹配结果表明Django应用程序是满足攻击条件的。

开发人员可能使用的脆弱正则表达式的另一个例子是在“inbox”之后省略了尾部的斜杠。

使用此正则表达式，除了在标准的http://www.sampleapp.com/inbox网址中找到匹配之外，它还会在http://www.sampleapp.com/inbox.css中找到匹配项。

当把$符号附加到正则表达式后面时，应用程序将不会在触发的URL中找到匹配项。

ASP.NET

在ASP.NET框架中有一个称为FriendlyURLs的内置功能，其主要目的是使URL更简洁，更友好。要访问https://www.example.com/home.aspx，应用程序将会删除该URL的扩展名，并将用户重定向到https://www.example.com/home。

此功能可以在Route.config文件中进行配置，并且在任何ASP.NET应用程序中都默认启用了此功能。

当FriendlyURLs功能打开后，用户通过请求：

http://localhost:39790/Account/Manage.aspx访问现有的Manage.aspx页面时，应用程序将删除.aspx扩展名，并显示页面内容。

使用此配置访问触发URL :

http://localhost:39790/Account/Manage.aspx/test.css时将导致.aspx扩展名被忽略; 该用户将被重定向到

http://localhost:39790/Account/Manage/test.css

，这会导致404错误。这意味着当FriendlyURL打开时，应用程序不符合攻击条件。

虽然FriendlyURL默认是启用的，但有许多网站并不使用此功能。它可以在Route.config中轻松关闭。

关闭该功能后，访问相同的触发URL会导致200 OK响应，并返回Manage.aspx页面的实际内容。

该漏洞在几个已知的缓存机制中的利用

攻击的第二个条件是，Web缓存功能可以根据网址末尾的扩展名判断是否将Web应用程序的文件设置为缓存文件，而忽略任何缓存头。以下是几个已知的缓存机制的示例，其中说明了它们的缓存过程以及它们如何识别接收到的文件的类型。

Cloudflare

当文件从Web服务器到达Cloudflare服务器时，它经历两个阶段。第一阶段称为资格阶段，Cloudflare将在该阶段中检查缓存功能是应用在网站上还是文件所在的目录。如果答案是yes（这可能就是为什么网站从一开始就使用Cloudflare的服务的原因），Cloudflare服务器会检查URL是否是以下面的这些静态文件扩展之一结尾的：

class, css, jar, js, jpg, jpeg, gif, ico, png, bmp, pict, csv, doc, docx, xls, xlsx, ps, pdf, pls, ppt, pptx, tif, tiff, ttf, otf, webp, woff, woff2, svg, svgz, eot, eps, ejs, swf, torrent, midi, mid

如果文件的后缀是上述之一，文件将进入第二阶段 – 取消资格阶段，Cloudflare服务器将检查HTTP缓存头是否存在。

不幸的是，通过访问触发URL，Web服务器返回了当前的动态页面的缓存头，这意味着该文件可能会返回一个无缓存的指令。

不过幸运的是，Cloudflare有一个名为“边缘缓存超时TTL”的功能，它提供了覆盖任何现有HTTP头的选项。通过将此功能设置为“启用”，将从高速缓存中缓存从Web服务器返回的文件。由于各种原因Cloudflare建议使用此HTTP头，因此这是一个常用的功能。