Web Cache Deception（Web缓存欺骗）

Web缓存欺骗是一种常见漏洞，攻击者可以利用它欺骗Web缓存服务器存储敏感的动态内容。这种漏洞是由于缓存服务器和源服务器在处理请求时存在差异而产生的。

在Web缓存欺骗攻击中，攻击者诱导受害者访问一个恶意URL，诱使受害者的浏览器发出一个模糊的请求，获取敏感内容。缓存服务器错误地将其解释为对静态资源的请求并存储响应。攻击者随后可以请求相同的URL以访问缓存的响应，从而未经授权获取私密信息。

Web缓存欺骗与Web缓存投毒的区别

Web缓存欺骗和Web缓存投毒都利用了缓存机制，但方式不同：

• Web缓存投毒：通过操纵缓存键，将恶意内容注入缓存响应中，然后将这些响应提供给其他用户。

• Web缓存欺骗：利用缓存规则，诱使缓存服务器存储敏感或私密内容，攻击者随后可以访问这些内容。

Web缓存

Web缓存是一个位于源服务器和用户之间的系统。当客户端请求静态资源时，请求首先被发送到缓存服务器。如果缓存中没有资源副本（称为缓存未命中），请求将被转发到源服务器，源服务器处理并响应请求。响应首先发送到缓存服务器，然后再发送给用户。缓存服务器根据预配置的规则决定是否存储响应。

当未来再次请求相同的静态资源时，缓存服务器直接将存储的响应副本提供给用户（称为缓存命中）。

缓存已成为交付Web内容的常见且关键部分，尤其是随着内容分发网络（CDN）的广泛使用。CDN通过缓存将内容副本存储在世界各地的分布式服务器上，通过从离用户最近的服务器提供内容，减少数据传输距离，从而加快内容交付速度。

缓存键

当缓存服务器接收到HTTP请求时，它必须决定是否有可以使用的缓存响应，或者是否需要将请求转发到源服务器。缓存服务器通过从HTTP请求的元素生成“缓存键”来做出这一决定。通常，这包括URL路径和查询参数，但也可能包括其他元素，如头信息和内容类型。

如果传入请求的缓存键与之前的请求匹配，缓存服务器认为它们是等效的，并提供缓存响应的副本。

缓存规则

缓存规则决定了哪些内容可以被缓存以及缓存多长时间。缓存规则通常被设置为存储静态资源，因为这些资源通常不会频繁更改，并且会在多个页面中重复使用。动态内容通常不会被缓存，因为它更可能包含敏感信息，确保用户从服务器直接获取最新数据。

Web缓存欺骗攻击利用了缓存规则的应用方式，因此了解不同类型的规则非常重要，尤其是基于请求URL路径中定义字符串的规则。例如：

• 静态文件扩展名规则：这些规则匹配请求资源的文件扩展名，例如.css用于样式表或.js用于JavaScript文件。

• 静态目录规则：这些规则匹配以特定前缀开头的所有URL路径。这些规则通常用于仅包含静态资源的特定目录，例如/static或/assets。

• 文件名规则：这些规则匹配特定的文件名，以定位那些对Web操作普遍需要且很少更改的文件，例如robots.txt和favicon.ico。

缓存服务器还可能根据其他标准（如URL参数或动态分析）实现自定义规则。

构造Web缓存欺骗攻击

一般来说，构造基本的Web缓存欺骗攻击涉及以下步骤：

1. 识别目标端点：找到一个返回包含敏感信息的动态响应的目标端点。在Burp中查看响应，因为某些敏感信息可能不会在渲染页面中显示。专注于支持GET、HEAD或OPTIONS方法的端点，因为会改变源服务器状态的请求通常不会被缓存。

2. 识别缓存和源服务器解析URL路径的差异：这可能是它们在以下方面的差异：

   • 如何将URL映射到资源。

   • 如何处理分隔符字符。

   • 如何规范化路径。

3. 构造恶意URL：利用差异欺骗缓存服务器存储动态响应。当受害者访问该URL时，其响应被存储在缓存中。使用Burp，您可以发送请求到相同的URL以获取包含受害者数据的缓存响应。避免直接在浏览器中进行此操作，因为某些应用程序可能会重定向没有会话的用户或使本地数据失效，这可能会隐藏漏洞。

我们将探讨一些构造Web缓存欺骗攻击的不同方法。

使用缓存破坏器

在测试差异和构造Web缓存欺骗漏洞利用时，确保您发送的每个请求都有不同的缓存键。否则，您可能会收到缓存响应，这会影响您的测试结果。

由于URL路径和任何查询参数通常都包含在缓存键中，您可以通过在路径中添加查询字符串并每次发送请求时更改它来更改键。您可以使用Param Miner扩展程序自动化此过程。安装扩展程序后，点击顶级菜单Param miner > Settings，然后选择Add dynamic cachebuster。Burp现在会为您的每个请求添加一个唯一的查询字符串。您可以在Logger标签中查看添加的查询字符串。

检测缓存响应

在测试过程中，能够识别缓存响应至关重要。为此，请查看响应头和响应时间。

以下响应头可能表明响应已被缓存：

• X-Cache头：提供有关响应是否从缓存中提供信息。典型值包括：

  • X-Cache: hit- 响应来自缓存。

  • X-Cache: miss- 缓存中没有该请求的响应，因此从源服务器获取。在大多数情况下，响应随后会被缓存。要确认这一点，请再次发送请求，查看值是否更新为hit。

  • X-Cache: dynamic- 源服务器动态生成内容。通常这意味着响应不适合缓存。

  • X-Cache: refresh- 缓存内容已过时，需要刷新或重新验证。

• Cache-Control头：可能包含指示缓存的指令，如public且max-age大于0。注意，这仅表明资源可以被缓存。它并不总是表明缓存，因为缓存有时可能会覆盖此头。

如果您注意到相同请求的响应时间存在显著差异，这也可能表明较快的响应来自缓存。

利用静态扩展名缓存规则

缓存规则通常通过匹配常见的文件扩展名（如.css或.js）来定位静态资源。这是大多数CDN的默认行为。

如果缓存和源服务器在将URL路径映射到资源或使用分隔符方面存在差异，攻击者可能能够构造一个带有静态扩展名的动态资源请求，该请求被源服务器忽略，但被缓存服务器视为静态资源。

路径映射差异

URL路径映射是将URL路径与服务器上的资源（如文件、脚本或命令执行）关联起来的过程。不同的框架和技术使用了多种不同的映射风格。两种常见的风格是传统URL映射和RESTful URL映射。

传统URL映射直接表示文件系统中的资源路径。例如：

http://example.com/path/in/filesystem/resource.html

• http://example.com指向服务器。

• /path/in/filesystem/表示服务器文件系统中的目录路径。

• resource.html是要访问的特定文件。

相比之下，REST风格的URL不会直接匹配物理文件结构。它们将文件路径抽象为API的逻辑部分：

http://example.com/path/resource/param1/param2

• http://example.com指向服务器。

• /path/resource/是一个表示资源的端点。

• param1和param2是服务器用于处理请求的路径参数。

缓存和源服务器在将URL路径映射到资源方面存在差异，可能导致Web缓存欺骗漏洞。考虑以下示例：

http://example.com/user/123/profile/wcd.css

• 使用REST风格URL映射的源服务器可能将此请求解释为对/user/123/profile端点的请求，并返回用户123的个人资料信息，忽略wcd.css作为非重要参数。

• 使用传统URL映射的缓存服务器可能将此请求视为对/user/123/profile目录下名为wcd.css的文件的请求。它将URL路径解释为/user/123/profile/wcd.css。如果缓存配置为存储以.css结尾

利用路径映射差异

为了测试源服务器如何将URL路径映射到资源，可以在目标端点的URL中添加一个任意的路径段。如果响应仍然包含与基础响应相同的敏感数据，这表明源服务器对URL路径进行了抽象处理，并忽略了添加的路径段。例如，如果将/api/orders/123修改为/api/orders/123/foo后，仍然返回订单信息，就属于这种情况。

为了测试缓存服务器如何将URL路径映射到资源，需要修改路径以尝试匹配缓存规则，例如通过添加静态扩展名。例如，将/api/orders/123/foo修改为/api/orders/123/foo.js。如果响应被缓存，这表明：

• 缓存服务器将完整的URL路径（包括静态扩展名）解释为资源路径。

• 存在一个缓存规则，用于存储以.js结尾的请求的响应。

缓存服务器可能基于特定的静态扩展名制定了规则。可以尝试多种扩展名，包括.css、.ico