3.31 论文笔记 | Cached and Confused: Web Cache Deception in the Wild

Cached and Confused: Web Cache Deception in the Wild（Web 缓存欺骗）

• Seyed Ali Mirheidari （University of Trento）——是一个博士学生
• Sajjad Arshad Northeastern University（东北大学，是做一名网络安全研究员，发的顶会超多，锁住）
• Kaan OnarliogluAkamai Technologies (阿卡迈科技公司)
• Bruno Crispo University of Trento &KU Leuven（计算机科学与信息工程学院(DISI)教授
  特伦托大学国际信息通信技术博士学院院长，猜测是一作的导师，但是没二作论文多）
• Engin Kirda Northeastern University（东北大学 做的是系统统，软件和网络安全(重点是网络安全，二进制分析，恶意软件检测，也发了很多论文，锁住）
• William Robertson Northeastern University （一查google schoolar好强！“我的研究涉及广泛的系统、网络和软件安全问题，目标是使网络空间对每个人都更安全。”)

综上，东北大学的SECURITY好强！

扒到的LAB
iSecLab（网页不更新了，但18年的顶会质量较高）
LAB: THE NORTHEASTERN UNIVERSITY SYSTEMS SECURITY LAB （感觉和我自己在的实验室去年发的论文数差不多）
Cybersecurity and Privacy Institute

Abstract

1. 大规模的测试工作：作者提出了第一项大规模研究，该研究量化了340个高 AlexaTop 5K中的个人资料网站。作者发现表明，在**Web缓存欺骗 (WCD)**公开披露两年后，许多受欢迎的站点仍然脆弱。
2. 测试后的建议：我们对流行的CDN提供商的经验实验强调了这样一个事实:网络缓存不是即插即用技术。

Introduction

现状：在一般情况下，为了提高CDN缓存模式地效率，同时保护CDN缓存访问者的隐私性。缓存的最佳选择包括经常访问的图像，软件和文档下载，流媒体，样式表以及大型静态HTML和JavaScript文件。 最近的一项科学测量还估计，CDN提供者为Alexa Top 1K提供了超过74％的服务，这表明CDN和更一般的Web缓存在Internet中发挥着核心作用。
攻击：在2017年，Gil提出了Web缓存欺骗(WCD)攻击，该攻击可以诱使Web缓存错误地存储内容，并因此使攻击者在未经授权地情况下放访问该内容。其核心是源服务器和WEB缓存之间的路径混淆。在这两点上，对请求的URL的不同解释导致对给定对象的可缓存性存在分歧。
本文工作：

1. 在本文中，作者首先介绍了对Alexa Top 5K中295个站点的WCD的大规模测量和分析。结果显示，许多处理敏感数据和私人数据的高知名度网站都受到了WCD的影响，并且很容易受到网络攻击。然后，作者讨论了可最大化WCD潜在破坏力的其他路径混淆方法，并在对340个站点​​的扩展数据集进行的后续实验中证明了它们的影响。
2. 除此之外，作者提供了有关WCD严重性的新颖见解——利用WCD来窃取其他类型的敏感数据，包括安全令牌，解释将WCD漏洞提升为注入向量的先进攻击技术，以及通过对收集到的数据进行进一步分析来量化我们的发现。
3. 最后，作者对流行的CDNproviders进行了实证分析，记录了它们的默认缓存设置和自定义机制。

Background & Related Work

在本节中，作者概述了Web缓存欺骗（WCD）攻击的工作原理，并讨论了相关概念和技术，例如Web缓存，路径混淆和现有的WCD扫描程序。

Web Caches

对于Web服务器及其最终用户而言，在Internet上反复传输大量使用的大型Web对象是一个昂贵的过程，尤其是面对Internet基础结构和路由问题的常见技术问题时，可能导致网络延迟增加，并导致Web应用程序无响应。 为了解决这个问题，Internet设置了Web缓存机制，并且用于Internet通信的各个步骤（通常是多个步骤）。例如，浏览器和反向代理服务器。

特别是，Web缓存是Content Delivery Networks（CDN）的关键组成部分，它为用户提供Web性能和可用性服务。 通过在全球范围内部署大规模分布的共享缓存代理网络（也称为边缘服务器），CDN的目标是尽可能多地从其最接近客户端的缓存中满足请求，从而在此过程中卸载原始服务器。 由于涵盖了从简单的个人站点到大型企业等不同市场领域的多个受欢迎的CDN提供程序的结果，Web缓存已成为Internet基础结构的核心组成部分。

缓存的最常见目标是静态但经常访问的资源。 其中包括静态HTML页面，脚本和样式表，图像和其他媒体文件，以及大型文档和软件下载。（非静态对象的缓存并不常见，并且与WCD攻击无关。本文没讨论。）

HTTP / 1.1规范定义了可在服务器响应中包含的Cache-Control header，以向通信路径上的所有Web缓存发信号通知如何处理传输的对象。 例如，标题“ Cache-Control：no-store”指示不应存储响应。 虽然规范指出Web缓存必须尊重这些标头，但是Web缓存技术和CDN提供程序为用户提供了配置选项，以忽略和覆盖标头指令。 实际上，一种常见且简单的配置方法是基于资源路径和文件名创建简单的缓存规则，例如，指示Web缓存存储所有扩展名为jpg，ico，css或js的文件。

Path Confusion

随着Web应用程序的大小和复杂性的增长，Web服务器引入了复杂的URL重写机制，以实现高级应用程序路由结构以及提高可用性和可访问性。举个例子，http://www.somehost.com/Blogs/2006/12/，URL重写后变为
http://www.somehost.com/Blogs.aspx?year=2006&month=12 ¹

但可能存在Web服务器并没有告知外部其对复杂URL重写机制的结果，并以一种意想不到的（可能是不安全的）方式处理URL。 这称为路径混乱。

干净URL方案使用从Web服务器的内部资源组织中抽象出来的结构，从而提供了一种 面向API的更具可读性的表示形式。例如，对于一个给定的Web服务，可以选择example.com/index/v1/v2来代替URLexample.com/index.php?p1=v1&p2=v2。

当用户使用example.com/index/img/pic.jpg访问相同的Web服务的情况。用户和通信路径中的所有技术（例如，Web浏览器，缓存，代理，Web应用程序防火墙）可能会误解此请求期望返回一个图像文件，并相应地处理HTTP响应（例如，网络缓存可能选择存储响应有效负载）。 但是，实际上，Web服务将在内部将此URL映射到example.com/index.php?p1=img&p2=pic.jpg，并使用HTTP 200状态代码返回index.php的内容。请注意，即使img / pic.jpg是Web服务器上不存在的任意资源，HTTP 200状态代码将错误地指示请求已按预期成功处理。

基于路径混淆的著名攻击类别是相对路径覆盖（RPO）

• 挖个坑：相对路径覆盖（RPO）

Web Cache Deception

为了利用WCD漏洞，攻击者制定了满足以下两个属性的URL：

1. Web服务器必须将该URL解释为对带有私有信息的不可缓存页面的重新请求，并且它应该触发成功的响应。 2.同一URL必须由中间Web缓存解释为对匹配有效缓存规则的静态对象的请求。

接下来，攻击者使用社交工程渠道诱使受害者访问此URL，这将导致错误地缓存受害者的私人信息。 然后，攻击者将重复该请求并获得对缓存内容的访问权限。

攻击步骤：

1. 攻击者诱骗受害者访问请求/account.php/nonexistent.jpg的URL。 乍一看，它似乎引用了图像文件，但实际上并未指向服务器上的有效资源。
2. 请求到达了Web服务器并被处理。 此示例中的服务器应用重写规则来丢弃请求对象的不存在的部分，这是流行的Web服务器和应用框架工作的常见默认行为。 结果，服务器会发送回成功响应，但实际上是体内包含了account.php的内容，其中包含受害者帐户的私人详细信息。 Web缓存不知道服务器上发生的URL映射，因此将响应存储为响应，并将其解释为静态图像。
3. 攻击者访问相同的URL，导致缓存命中，并授予他未经授权的访问受害者的缓存帐户信息。

由于其安全性和高破坏力，WCD引起了媒体的广泛关注。 主要的Web缓存技术和CDN提供商也做出了回应，一些针对客户的已发布配置强化指南。 最近，Cloudflare宣布了对HTTP响应内容类型进行新检查的选项，以缓解攻击。
预防手段：
研究人员发布了用于扫描和检测WCD的工具，例如，作为Burp Suite扫描仪的扩展或作为独立工具。 作者注意到这些工具是针对渗透测试的，旨在直接在测试人员的控制下对Web属性进行针对性的扫描。 也就是说，通过设计，他们可以在不确定的前提下操作，通过简单的相似性进行信息公开测试并编辑距离检查，否则需要人工监督和解释结果。

3. Methodology

用到的工具

1. 子域名枚举工具：Sublist3r、aquatone、Amass
2. Google OAuth

3.1 Stage 1: Measurement Setup

仅当易受攻击的站点管理最终用户的私人信息并允许对该数据执行敏感操作时，WCD攻击才有意义。 因此，提供身份验证机制的站点是攻击的主要目标，因此也是我们进行测量的主要目标。第一阶段是识别此类站点并为其创建测试帐户。

1. 域发现。此阶段开始于访问初始测量池中的站点（例如Alexa Top n）。然后，我们通过使用开源智能工具执行子域发现来增加站点覆盖率。我们将这些新发现的主要站点的子域(过滤那些响应HTTP(s)请求的子域)添加到种子池。
2. 帐户创建。接下来，作者在每个站点上创建两个测试帐户：一个用于受害者，另一个用于攻击者。 作者为每个帐户填充唯一的虚拟值。 接下来，作者手动浏览每个受害者帐户，以发现应视为私人信息（例如，姓名，电子邮件，地址，付款帐户详细信息，安全问题和响应）或用户创建的内容（例如，评论，帖子，内部消息）的数据字段。 作者使用预定义的标记填充这些字段，随后可以在缓存的响应中搜索这些标记以检测成功的WCD攻击。 另一方面，攻击者帐户无需输入数据。
3. Cookie收集。成功登录种子池中的站点后，爬虫程序将为受害人帐户和攻击者帐户收集两组cookie。 这些被保存在一个饼干罐中，以在随后的测量步骤中重复使用。 请注意，作者采取了多种措施来确保我们的抓取工具在作者的实验过程中保持身份验证。 考虑到Cookie的过期时间戳记，作者的抓取工具会定期进行重新认证。 此外，搜寻器使用正则表达式和黑名单来避免访问页面上的常见注销链接。

3.2 Stage 2: Attack Surface Detection

域抓取：在第二阶段，我们的目标是从种子库中的域映射到一组页面（即completeURL），这些页面随后将进行WCD漏洞测试。 为此，我们在这些池中的每个域上运行一个递归搜寻器，以记录指向该站点页面的链接。
URL Grouping 作者通过按查询字符串参数名称或数字路径参数对这些URL进行分组，将发现的URL转换为抽象表示。 URL的这种过滤可显着加快测量速度，并在阶段3中通过冗余扫描来避免过度消耗目标站点的资源。出于类似原因，我们在每个域收集500个唯一页面后停止了攻击面检测爬虫。

3.3 Stage 3: WCD Detection

针对第2阶段中发现的每个URL发起WCD攻击，并分析响应以确定是否已成功利用WCD漏洞WCD攻击。

1. 作者设计了一个引用不存在的静态资源的攻击URL。 特别是，我们在原始页面“ /.css”后面附加。 作者使用随机字符串作为文件名，以防止站点的普通最终用户巧合地请求相同的资源。
2. 作者从受害者帐户发起对此攻击URL的请求并记录响应。
3. 作者从攻击者帐户发出相同的请求，并保存响应以进行比较。
4. 最后，我们通过省略保存在Attacker cookie jar中的所有会话标识符，以未经身份验证的用户身份来重复攻击。 我们稍后将分析对此步骤的响应，以确定没有身份验证凭据的攻击者（例如，当站点不提供开放或免费注册时）是否也可以利用WCD漏洞。

标记提取。 一旦执行了上述攻击方案，作者首先会在攻击者的响应中搜索在阶段1中输入到受害者帐户中的标记，以检查是否公开了私有信息。如果攻击者帐户所请求的URL中存在受害者标记， 攻击者必须已经收到受害者的错误缓存的内容，因此，目标URL包含一个可利用的WCD漏洞。 由于这些标记携带相对较高的熵，因此该方法不太可能产生假阳性。（这句话不是很理解，和香农熵有什么关系）

秘密提取。 作者扫描攻击者的响应，以发现通常用作Web应用程序安全机制一部分的秘密令牌。这些检查包括普通机密（例如CSRF令牌，会话标识符）以及任何其他特定于应用程序的身份验证和授权令牌（例如API凭据）。作者还检查与会话相关的资源，例如动态生成的JavaScript，这些资源中可能包含私有信息并包含秘密信息。

为了提取候选者泄漏的机密信息，作者扫描了攻击者的响应以获取名称和值对，其中（1）名称包含我们的一个关键字（例如，csrf，xsrf，token，state，client_id），或（2）值具有随机成分。作者在隐藏的HTMLform元素，从HTML锚点元素提取的查询字符串以及内联JavaScript变量和常量中检查这些名称和值对。 同样，我们提取HTMLscript元素中引用的随机文件名。我们首先通过从目标字符串中删除字典单词（即使用10,000个常见英语单词的列表），然后在其余部分计算Shannon熵，来执行所有随机性测试。（这里也不是很理解）

3.4 Verification and Limitations

研究人员反复报道，大规模的Internet测量，特别是那些使用自动搜寻器的测量，很容易被旨在阻止恶意机器人和内容抓取工具的安全解决方案阻止或提供假内容。 作者在方法中的大多数步骤中都使用了真正的浏览器（例如Google Chrome）。

请注意，本文有几个重要的限制……作者强调，本文的结果代表了一个下限。

3.5 Ethical Considerations

1. 性能方面的考虑。以最大程度地减少对扫描站点的性能影响以及对其操作员造成的不便。作者在每个方面都说了说
2. 安全方面的考虑。 作者的方法完全避免危害爬网站点或其最终用户的安全。
3. 负责任的披露。
4. 可重复性。

4 Web Cache Deception Measurement Study

（Q1）WCD漏洞的普遍程度是多少？ （§4.2）
（Q2）WCD漏洞是否会暴露PII？ （§4.3）
（Q3）可以使用WCD漏洞来抵抗针对Web应用程序攻击的防御吗？ （§4.3）
（Q4）未经身份验证的用户可以利用WCD漏洞吗？ （第4.3节）

4.1 Data Collection

作者配置了搜寻器以在实验时从Alexa Top 5K中识别出易受攻击的站点。 为了可扩展地创建测试帐户，我作者提供了通过Google OAuth进行用户身份验证选项的网站筛选了此初始衡量指标种子库。 此筛选过程将本次评估中考虑的网站范围缩小到295个。表2汇总了我们的爬网统计信息。

4.2 Measurement Overview（WCD漏洞的普遍程度是多少？）

**Alexa排名。**爬虫从包含收集到的数据集的295个站点中识别出16个站点（5.4％）包含WCD漏洞。 图3展示了Alexa Top 5K中所有站点和易受攻击站点的分布。 由此可见，脆弱站点的分布与爬网站点的数量大致成正比。 也就是说，作者的数据并不表明WCD漏洞的发生率与站点受欢迎程度相关。

内容交付网络（CDN）。 作者使用一组启发式方法在HTTP标头中搜索知名的供应商字符串，我们用相应的CDN标记了每个域和站点。 表3显示了此标记的结果。 请注意，许多站点使用多个CDN解决方案，因此前四行的值总和可能会超过我们在最后一行中报告的总数。

响应代码。 表4列出了针对易受攻击的站点观察到的HTTP响应代码的分布。 该分布由“ 404未找到”控制，虽然这可能不直观，但实际上确实是根据RFC 7234允许的行为。 另一方面，虽然只有12个站点泄漏了具有200 OK响应的资源，但是作者对这些漏洞进行手动检查时，作者注意到从此类资源中泄漏了更多的PII。

缓存标头。表5显示了从易受攻击的站点收集的与缓存相关的标头的细分。 在特定情况下，作者注意到尽管存在其语义禁止缓存的标头（例如“ Pragma：no-cache”，“ Cache-Control：no-store”），携带这些标题的页面无论如何都会被缓存，因为发现它们容易受到WCD的攻击。 这一发现表明，站点管理员确实利用了Web缓存提供的配置控件，这些控件允许站点覆盖标头指定的缓存策略。这种观察的结果是，用户代理无法使用缓存标头来确定资源是否实际上已经存在， 是否被缓存。 这对于依赖缓存头推断WCD漏洞存在的WCD检测工具具有重要意义。

4.3 Vulnerabilities

表6总结了在收集的数据中发现的漏洞类型，并通过手工检查进行了标记。
PII. 16个脆弱站点中的PII.14泄漏了各种PII，包括名称，用户名，电子邮件地址和电话号码。 除了这四个主要类别之外，还发现了其他多种PII类别被泄漏。 其他PII的广泛示例包括财务信息（例如帐户余额，购物历史记录）和健康信息（例如烧掉的卡路里，步数，重量）。 虽然很容易忽略此类信息，但作者注意到，上述PII可以用作高效的鱼叉式网络钓鱼攻击的基础（鱼叉式钓鱼网络网络

Security Tokens. 使用第3节中描述的基于熵的过程，我们还分析了数据的存在性，表明安全令牌泄漏了。然后，作者通过使用浏览器访问易受攻击的站点并检查怀疑是否存在泄漏的令牌的存在来手动验证作者的发现。最后，作者使用在测量过程中建立的测试帐户，手动验证了每类泄漏令牌的代表性示例是否具有可利用性。

在16个易受攻击的站点中，有6个泄漏了会话有效的CSRF令牌，尽管存在已部署的CSRF防御

• 挖个坑：CSRF防御

但攻击者仍可以使CSRF攻击。其中3个是在用于保护POST请求的隐藏表单元素中发现的，而其他4个是在嵌入式JavaScript中发现的，这些JavaScript主要用于发起HTTP请求。我们还发现2个站点泄漏了GET请求的URL查询参数中的CSRF令牌，这与GET请求应该是幂等的约定有些矛盾。

16个易受攻击的站点中有6个在嵌入式JavaScript中泄漏了会话标识符或特定于用户的API令牌。这些会话标识符可用于模拟易受攻击站点上的受害者用户，而API令牌可用于以受害者用户身份发出API请求

Authenticated vs. Unauthenticated Attackers. 作者在第3节中介绍的方法包括一个检测步骤，旨在通过访问缓存的页面而不在请求中发送任何已存储的会话标识符来发现未经身份验证的用户是否可以利用可疑的WCD漏洞。 这种自动检查仅在少数情况下失败。 更糟糕的是，手动检查故障案例显示，每个爬虫都产生了假阴性，实际上，所有剩余的漏洞也可以由未经身份验证的用户利用。 这意味着WCD作为一类漏洞，往往不要求攻击者对易受攻击的站点进行身份验证才能利用这些漏洞。

4.4 Study Summary

发现295个站点中有16个站点来自Alexa排名前5K的Web缓存欺骗（WCD）漏洞。

1. 我们注意到，虽然这不是所扫描站点的一大部分，但这些站点在Alexa排名中的位置可预见到大量用户。
2. 我们发现，缓存标头的存在是不可靠的，用于指示是否缓存资源的指示器，这意味着在扫描站点以查找WCD漏洞时，依赖于此信号的现有检测工具可能会无意中产生假阴性。
3. 我们发现易受攻击的站点泄漏了PII，这对于发动鱼叉式攻击或安全令牌很有用，这些令牌可用于模拟受害者用户或绕过重要的Web安全防护。
4. 最后，此处发现的WCD漏洞不需要攻击者对易受攻击的站点进行身份验证，这意味着具有限制性注册过程的站点无法不受WCD漏洞的影响

5 Variations on Path Confusion

从攻击者的外部角度来看，通常无法可靠地预测缓存规则，从而导致了制作攻击URL的猜测工作的过程。 基于此观察，作者假设：当探索路径混淆技术的变化时，可能会增加触发缓存规则和有效Web服务器响应的可能性，并有可能最初不受WCD漏洞的网站上有出现WCD漏洞。为了检验我们的假设，我们在2019年7月的第一次实验后14个月进行了第二轮测量。

具体来说，作者重复了我们的方法，但是尝试尝试使用不同的路径混淆技术制作的有效负载，以确定可以通过路径混淆变化利用多少页面。在本研究中，我们使用了扩展的种子池，其中包含来自原始集合的295个网站，以及从Alexa Top5K中随机选择的另外45个网站，总计340个。特别是，作者在不使用Google OAuth的网站中选择了这些新网站，以试图消除潜在的与之前的测量中存在偏差。 此决定的负面结果是，我们必须完全手动执行帐户创建步骤，从而限制了我们可以以此方式纳入研究的网站数量。最后，我们通过仅在前500个页面中选择和利用页面来修改URL分组方法，如果内容中至少有一个标记，则对于我们的目的而言，效率更高，对目标的资源消耗更少。 在下文中，我们描述了这个实验并提出了我们的发现。

5.1 Path Confusion Techniques

回顾一下我们的分析和表4，在大多数情况下，我们的WCD测试都导致404 Not Foundstatus代码的出现，这表明Web服务器返回的错误页面不太可能包含PII。 为了增加引发200 OK响应的机会，同时仍然触发缓存规则，我们在先前的工作的基础上提出了下面的其他路径混淆技术，如图4所示。图4中第一种是原始的方法。

编码换行符（\ n）。 Web服务器和代理通常以换行符作为停止解析URL的标志，而丢弃URL字符串的其余部分（请参见图4b）。 我们设计此URL的目的是为了利用Web服务器对这些服务器在换行符之后放置路径组件（即服务器seesexample.com/account.php），但是前面放置了缓存代理，而缓存代理却不能正确地解码换行符（代理则是seesexample.com/account.php% 0Anonexistent.css）。 结果，对该URL的请求将导致成功的响应，并且缓存将基于不存在的文件扩展名认为这是静态内容的情况下存储内容。

编码分号（;）。 某些Web服务器和Web应用程序框架接受URL中用分号分隔的参数列表。 但是，服务器前面的缓存代理可能未配置为识别此类列表。 我们在图4c中介绍的路径混淆技术通过在分号后附加不存在的静态文件名来利用这种情况。 在成功的攻击中，服务器将解码URL并返回例如example.com/account.php的响应，而代理将无法解码分号，将example.com/account.php%3Bnonexistent.css作为资源，尝试缓存不存在的样式表。

编码磅（＃）。 Web服务器通常将磅字符作为HTML片段标识符进行处理，因此，在首次出现URL时便停止对其进行解析。 但是，代理及其缓存规则可能未配置为对井号进行解码，从而导致它们处理整个URL字符串。 我们在图4d中呈现的路径混淆技术再次利用了Web服务器和Web缓存之间URL的这种不一致解释，并且以与上面编码的换行符类似的方式工作。 也就是说，在这种情况下，Web服务器将成功响应example.com/account.php，而代理将尝试缓存example.com/account.php%23nonexistent.css。

编码问号（？）。 此技术如图4e所示，其目标是具有未配置为解码和忽略以问号开头的标准URL查询字符串的缓存规则的代理。 因此，Web服务器将生成一个有效的响应，例如example.com/account.php，而代理将缓存该响应，并错误地将同URL解释为example / account.php％3Fname = valnonexistent.css。

5.2 Results

Pearson的χ2检验，

作者在第二项实验中针对“路径参数”技术呈现的结果与我们的第一次测量结果不同。这表明，在两次实验之间的14个月的间隔中，网站操作员在收到通知后解决了该问题，或者网站结构或缓存规则发生了变化，从而缓解了现有漏洞或暴露了新的易受攻击页面。特别是，作者在之前的实验中发现了16个易受攻击的站点，而在第二次研究中发现了25，而这两个站点之间的重叠只有4个。

在本次实验中，作者发现了25个易受攻击的网站，其中有20个属于先前使用295个使用Google OAuth的网站，而5个是新选择的不使用GoogleOAuth的网站。为了测试这两组网站之间的漏洞发生率分布是否显示出统计学上的显着差异，我们应用了Pearson的χ2检验，其中漏洞发生率被视为分类结果变量，OAuth /非OAuth网站集为比较组。作者获得了1.07的检验统计量和0.30的p值，表明结果独立于对照组，并且发病率分布在典型选择的显着性水平上没有显着差异（即p> 0.05）。也就是说，我们对种子库的选择并没有偏见我们的发现。

• 挖个坑：Pearson的χ2检验 泊松检验

响应代码。 我们在表7中提供了针对易受攻击页面观察到的服务器响应代码。请注意，与原始路径相比，观察到的200条OK响应的数量与某些新的路径混乱版本形成了鲜明的对比。两种新的路径混淆技术确实能够引起成功服务器响应的数量显着增加，这与返回私有用户信息的机会更高相关。 其余两个变体的表现更接近原始技术。

漏洞。 在此实验中，我们总共确定了25个漏洞站点。表8显示了使用不同路径混淆变化检测到的易受攻击的页面，域和站点的细分。总体而言，原始的路径混淆技术导致相当成功的攻击，利用了68.9％的页面和14个站点。尽管如此，这些新技术组合仍然可以利用98.0％的页面，以及25个易受攻击站点中的23个，表明它们显着增加了成功攻击的可能性。

表9中的结果证实，每个路径混淆的变化都能够攻击一组不易受其他技术攻击的独特页面/域/站点，证明使用多种技术会增加成功利用的机会。 实际上，在25个易受攻击的站点中，只有11个只能使用我们在此处介绍的一种变体来开发，而不能使用路径参数技术。

总而言之，我们在本节中提出的结果证实了我们的假设，即与仅使用最初提出的路径参数技术相反，使用路径混乱的变化来发起WCD攻击会增加成功利用漏洞的可能性。 此外，在此过程中，有两个探索出的变体会引起更多的“ 200 OK”服务器响应，从而增加了Web服务器返回有效私人信息的可能性。

6 Empirical Experiments

在本节中，我们将提供两个实验性经验，以演示不同的缓存设置对WCD的影响，并讨论我们对流行CDN提供商默认设置的探索。

6.1 Cache Location 位置

成功的WCD攻击可能要求攻击者正确地将受害者与其连接到的同一边缘服务器作为目标，该边缘服务器存储了缓存的敏感信息。
我们通过从一台计算机上执行我们方法的受害者互动来测试此实际约束的影响美国马萨诸塞州波士顿市，并从意大利特伦托的另一台服务器发动攻击。我们对第5节中所述的第二种措施中确认容易受到攻击的25个站点中的每一个进行了重复测试，结果表明我们的攻击未能如我们所预测的那样对19个站点失败，因此需要进行调整以将目标对准正确的缓存服务器。令人惊讶的是，其余6个站点尽管标头表明它们是通过CDN（3个Akamai，1个Cloudflare，1个CloudFront和1个Fastly）提供的，但仍然可以利用。
在仔细检查流量后，我们在“快速”示例中发现标头，表明在其意大利区域记录了缓存未命中，然后在波士顿地区进行重试，导致缓存命中，从而导致了成功的攻击。我们无法利用暴露给我们的数据服务器来探索剩余的情况。
众所周知，许多CDN提供程序都使用分层缓存模型，其中内容即使从孩子驱逐[3，20]，也可以从父缓存中获得。上面的“快速”示例说明了这种情况，并且对于其余情况也是一个合理的解释。另一个可能性是，易受攻击的站点使用的是由其CDN提供程序开头的单独的集中式服务器端缓存。不幸的是，如果没有清楚地了解专有CDN的内部结构以及对站点所有者基础结构的可见性，就无法确定确切的缓存交互。
我们的实验证实，缓存位置是成功的WCD攻击的实际限制，在这种攻击中，分布式缓存服务器是分布式的。不仅如此，而且还表明在某些情况下攻击是可行的，而无需进行其他流量操纵。

6.2 Cache Expiration 过期

Web缓存通常会存储对象很短的时间，然后在对象过期后将其逐出。当Web缓存负载沉重时，驱逐也可能过早发生。因此，攻击者可能只有有限的机会才可发起成功的WCD攻击，直到Web缓存删除缓存的敏感信息为止。
为了衡量缓存过期对WCD的影响，我们以1小时，6小时和1天的延迟重复了我们的方法的攻击交互。3我们发现在每种情况下分别可利用16、10和9个站点。
这些结果表明：在现实攻击情形中，利用是可行的，因为受害者和攻击者与Web缓存的交互之间存在延迟。话虽这么说，缓存最终将逐出敏感数据，这意味着具有**较短延迟的攻击更有可能成功。**我们还注意到，我们对每个站点使用随机选择的易受攻击页面进行了此测试，因为这足以满足我们的目的。实际上，给定站点上的不同资源可能具有不同的缓存过期时间，从而对可能的攻击施加了额外的限制。

6.3 CDN Configurations 配置

作者对CDN缓存配置进行了实验。作者与四个主要CDN提供商创建了免费或试用帐户：Akamai，Cloudflare，Cloud-Front和Fastly。我们仅测试了每个供应商提供的基本内容交付解决方案，并未启用诸如Web应用程序防火墙之类的附加功能。我们强调，主要的CDN提供商提供了丰富的配置选项，包括站点所有者以编程方式与其流量进行交互的机制。对CDN功能和相应的WCD向量进行系统，详尽的分析是一项非常艰巨的任务，超出了本文的范围。我们在本节中提出的结果仅旨在提供高层次的见解，以了解在建立安全可靠的系统方面必须投入多少精力CDN环境以及默认设置的行为。

配置。 这里讲了一下每个缓存配置都需要了哪些内容。

6.4 Lessons Learned

我们在本节中提供的经验证据表明，正确配置Web缓存不是一件容易的事，此外，与发动攻击相比，检测和修复WCD漏洞的复杂性高得不成比例。如上所述，许多主要的CDN供应商不要在其默认配置中做出符合RFC的缓存决策[21]。即使基于文件扩展名的限制性更强的默认缓存规则也容易出现安全问题；例如，如果配置错误，Akamai和Cloudflare都可以缓存包含税款报表的动态生成的PDF文件。

---

1. URL重写 ↩︎