Web 缓存欺骗攻击技术详解

在他发布的“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头，因此这是一个常用的功能。

IIS ARR

ARR（应用程序请求路由）为IIS提供负载均衡功能。

缓存是ARR提供的功能之一。 可以为负载均衡器支持的Web服务器设置缓存规则，以便将文件保存到缓存目录。 创建新的缓存规则时，我们使用通配符和所需的扩展名定义要缓存的文件类型。 当文件到达ARR时，它会在文件的URL中查找此模式。很明显，ARR根据URL末尾的扩展名来识别文件类型。

此外，IIS ARR还包含一个忽略文件缓存头的选项，导致在任何情况下可以应用规则。

在以下示例中，IIS ARR与两个Web服务器链接，并配置为缓存所有css和JavaScript文件。

对触发URL（http://www.sampleapp.com/welcome.php/test.css）的请求导致在缓存目录中创建一个名为welcome.php的新目录，并在其中包含一个名为 test.css的缓存文件，其中包含了用户的welcome.php页面的内容。

NGINX

用作负载均衡器的NGINX服务器提供了缓存功能来存储从Web服务器返回的页面。

可以在NGINX配置文件中配置缓存规则。 以下示例显示了一个配置，指示NGINX缓存特定类型的静态文件，并忽略其缓存头。

当页面从Web服务器到达NGINX时，NGINX将在URL的末尾搜索扩展名，并根据该标识识别文件类型。

首先，缓存目录中没有缓存。

经过身份验证的用户访问触发URL

http://www.sampleapp.com/app/welcome.php/test.css，用户的页面会缓存在缓存目录中。

然后，攻击者在未经身份验证的情况下访问触发URL，NGINX服务器就会返回包含用户隐私内容的缓存文件。

缓解措施

1.配置缓存机制只有在HTTP缓存头允许时才缓存文件。

2.将所有静态文件存储在指定的目录中，并仅缓存该目录。

3.如果缓存组件提供该选项，请将其配置为按其内容类型进行文件缓存。

4.配置Web服务器，针对

http://www.example.com/home.php/nonexistent.css这类页面，Web服务器不返回具有触发URL的home.php的内容; 相反，服务器应该返回404或302响应。

总结

Web缓存欺骗是一种不仅易于执行的攻击，而且可能会因为暴露用户的个人信息而遭受更严重的后果，而攻击者则可以控制用户的帐户。我发现一些知名的网站也很容易受到这种攻击;大多数这些网站由最常见的CDN提供缓存服务。可以肯定的是，仍有许多网站可能成为受害者。

虽然本白皮书仅涉及了可以满足Web缓存欺骗攻击条件的有限技术的范例，但还有各种其他Web框架和缓存机制，可以为攻击者提供类似的机会来执行攻击。

为这个漏洞创造利用条件的Web框架和缓存机制本身并不脆弱;主要问题还是不正确的配置所导致的。

为了防止网络缓存欺骗攻击，技术人员应首先了解可以执行此攻击所需要的条件。此外，建议供应商努力防止其产品满足这些攻击条件。这可以通过禁用一些功能，更改默认设置和行为以及提供警告来提高技术人员的意识来实现。