基于缓存毒害的拒绝服务攻击

前言

本篇论文翻译自2019年 ACM CCS的《Your Cache Has Fallen: Cache-Poisoned Denial-of-Service Attack》

ABSTRACT

​ Web缓存通过重用HTTP响应,以减少到达原始服务器的请求数量、减少因为资源请求而导致的网络流量以及减少资源的访问延迟。由于这些原因,高速缓存是现代分布式系统中的关键组件,因为它使应用程序能够大规模扩展。除了优化性能指标外,缓存还可以增强针对拒绝服务(DoS)攻击的保护。

​ 在本文中,我们介绍并分析了一类新的Web缓存中毒攻击。通过在原始服务器上触发一个中间缓存系统未检测到的错误,缓存将被原始服务器生成的错误页面所“毒化”,毒化之后缓存会提供这种无用的内容而不是预期的内容,从而使受害者服务不可用。在对15种Web缓存解决方案的广泛研究中,我们分析了缓存中毒的DoS(Cache-Poisoned DoS,下文简称为CPDoS)攻击的负面影响。通过确定一种容易受到CPDoS攻击的代理缓存产品和五种CDN服务,我们展示了实际的相关性。其中有一些解决方案用于缓存高价值的网站。研究结果表明,现实很严重,因为一个简单的请求足以使一个较大地理区域内的受害者网站瘫痪。我们对CPDoS攻击的认识,对于研究人员分析这种攻击的起因以及对于分布式系统的从业人员来更好的部署他们的网站而言,具有非常重要的价值。

1. INTRODUCTION

​ 现代分布式软件系统需要大规模扩展,以便有效地处理全球用户的请求或者是分散在环境中的传感器等庞大的请求。通用体系结构方法是将系统设计为由不同中介组成的分层。应用程序级别的消息在客户端和服务器之间的路径上通过此类中间系统传递。常见的中介包括缓存,防火墙,负载平衡器,文档路由器和过滤器。

​ 通过缓存常用的资源以减少网络流量并优化应用程序的性能,这是Web成功的主要支柱之一。缓存的利用,旨在将其用于重复出现的客户端请求。原始服务器通常会规定资源是否可被缓存以及在什么条件下可以由缓存中间件提供缓存资源。缓存资源由缓存键(cache key)明确标识,该缓存键最常见的是包含在请求中的HTTP方法和URL中。如果请求的资源包含在中间缓存中,则客户端直接从缓存中接收缓存的副本。这样一来,Web缓存系统就可以为客户端请求提供服务,即使原始服务器处于脱机状态也可以提高可用性。此外,诸如内容分发网络(CDN)之类的分布式缓存系统可以提供针对分布式DoS(DDoS)攻击的其他保护措施。

​ 分层系统中的一个普遍问题是,当顺序处理同一条消息时,会有不同的结果。正如我们将在第3节中详细讨论的那样,这是属于“语义鸿沟”(semantic gap)攻击的根本原因[18](译者注:即对于同一个请求,缓存系统和原始服务器做出了不同的响应)。这些攻击利用了两个或更多实体解释对象的差异。在本文的上下文中,当攻击者可以为可缓存资源生成HTTP请求时,就会出现问题,比如在请求中带有不正确的字段,这个字段会被缓存系统忽略,但是在原始服务器则会引发错误。在这种设置下,中间缓存将从原始服务器接收错误页面,而不是请求的资源。换句话说,缓存可能会被原始服务器所生成的错误页面所毒化,并被配置为服务于这种无用的内容而不是预期的内容,从而使受害者服务不可用。这就是为什么我们将这类新型攻击称为“缓存中毒的拒绝服务(CPDoS)”。

​ 我们对此进行了深入的研究,以了解在缓存系统和原始服务器中HTTP请求的不一致解释如何在触发CPDoS。我们分析了十五种Web缓存解决方案的错误页面的缓存行为,并将它们与HTTP规范进行了对比[13]。我们确定了一种容易受CPDoS攻击的代理缓存产品和五种CDN服务。我们发现这种语义上的不一致会导致严重的安全后果,因为一个简单的请求就足以瘫痪一个非常广阔地理区域内的网站。最后,我们证明了CPDoS攻击引起了自相矛盾的局面,在这种情况下,缓存服务宣称可以提高可用性并适当防御DoS攻击,同时可以利用缓存服务来同时影响这两者。(译者注:CDN可以防御DOS攻击,同时又因为不正当的配置,从而使CDN成为了DOS攻击的起因)

​ 我们的三大主要贡献:

  1. 我们提出了一种新的威胁“缓存中毒的拒绝服务(CPDoS)”攻击,它威胁着Web的可用性。我们系统地研究了错误页面由原始服务器生成然后由缓存系统存储和分发的情况。我们介绍了三种具体的攻击变体,这些变体是由X-HTTP-Method-Override标头,标头大小限制和元字符解析不一致引起的。
  2. 我们根据经验研究了15种可用的Web缓存解决方案在处理HTTP请求中的行为,这些解决方案包含不正确的字段和缓存错误页面。我们发现了一种容易受CPDoS攻击的代理缓存产品和五种CDN服务。我们已将我们的发现披露给了受影响的解决方案供应商,并将其报告给了CERT/CC(CERT协调中心)。
  3. 我们讨论了可能的CPDoS对策,范围从忽略缓存的即时保护到保留缓存的保障。

2. FOUNDATIONS

​ 网络被认为是世界上最大的分布式系统。随着数据在Web上的不断增长,缓存系统成为Web可扩展性的重要支柱[3]。Web缓存系统可以出现在客户端和原始服务器之间的各种路径内的位置(参见图1)。另一个区别点是专用缓存和共享缓存。专用缓存仅为一个特定用户存储和重用内容。Web浏览器的客户端内部缓存是专用缓存的一个典型示例,因为它们仅存储专用用户的缓存。另一方面,客户端和服务器端缓存(也称为代理缓存)以及部署在Web骨干网中的CDN属于共享缓存,因为它们为多个客户端提供内容。某些Web应用程序可能还包括服务器内部缓存。这些缓存系统通常支持两种访问策略,即它们能够将缓存的资源提供给多个用户或一个用户。

图1 按位置和资源访问策略分类的不同类型的Web缓存系统

图1 按位置和资源访问策略分类的不同类型的Web缓存系统
​ 缓存策略由内容提供者通过在`RFC 7234`[11]中定义的缓存声明来控制。Web缓存标准定义了一组控制指令,用于指示缓存如何存储和重用可循环使用的响应。`Cache-Control`响应标头中的`max-age`和`s-maxage`属性定义了允许目标内容驻留在缓存中的最大持续时间(以秒为单位)。关键字`max-age`适用于专用缓存和共享缓存,而`s-maxage`仅适用于共享Web缓存系统。内容提供商还可以使用带有绝对日期的`Expires`标头来定义更新期限。与`max-age`一样,`Expires`适用于专用缓存和共享缓存。如果缓存中存储的响应未超过`max-age`,`s-maxage`和`Expires`标头指定的时间,则将其视为**新鲜**的。如果内容提供者希望仅允许通过专用缓存保存某些内容,则将专用指令添加到`Cache-Control`标头中。如果不希望某个响应被任何缓存存储和重用,则内容提供者必须在`Cache-Control`标头中包含关键字`no-store`。`Cache-Control`标头中的控制指令`must-revalidate`,`proxy-revalidate`和`no-cache`指示如何验证响应的新鲜度,以防内容过期或没有新鲜度生存期信息可用。所有提到的控制指令使内容提供者可以显式定义缓存策略。

​ 如果响应中没有显式的缓存指令,则Web缓存系统可以在满足某些条件时隐式地进行存储和重用响应。允许缓存隐式存储内容的一项要求是对GET请求的响应。不允许缓存对不安全方法(包括POSTDELETEPUT)的响应。此外,对GET方法的响应必须包含已定义的状态代码,例如200 OK204 No Content301 Moved Permanently。在这里,允许缓存通过使用启发式方法来获得缓存的过期时间。许多Web应用程序指示Web缓存系统为图像,脚本和样式表定义隐式的生存期,因为这些文件类型被视为静态内容。静态内容是指不经常更改的数据。因此,存储和重用此类资源被视为优化性能的最佳实践。

​ 在某些情况下,对于内容提供商而言,缓存某些错误消息也非常有用。例如,允许隐式缓存状态代码404未找到,该状态代码说明原始服务器对请求的资源没有合适的表示形式。405方法不允许声明目标资源不支持请求操作也可以隐式缓存。

3. SECURITY THREATS IN WEB CACHING SYSTEMS

​ 使用Web缓存系统在优化通信和应用程序性能方面具有许多优势。但是,许多工作表明,也可以利用Web缓存来影响应用程序的隐私和可靠性。例如,Web缓存中毒攻击是过去几年中出现的严重威胁。其中之一是请求走私(request smuggling)[24]攻击,这种攻击当Web缓存系统和原始服务器不严格遵循RFC 7234指定的策略时发生。在这种特殊攻击中,攻击者可以发送带有两个Content-Length标头的请求来攻击共享缓存。即使根据RFC 7234禁止存在两个Content-Length标头,缓存和原始服务器中的某些HTTP引擎仍会解析该请求。由于重复的标头,格式错误的请求将混淆原始服务器和缓存,以便将精心设计的有害的响应注入到Web缓存系统中。然后,此恶意响应将再次用于重复请求。

host of troubles[7]攻击是另一个针对共享缓存的漏洞。与以前的攻击一样,它利用了所涉及的系统层对Web缓存标准的解释不同。在这种攻击方法中,攻击者使用两个Host标头构造一个请求。 这些重复的标头在缓存和原始服务器中引起与请求走私攻击类似的行为异常。同样,将注入恶意响应以毒害缓存。

​ 另一个旨在毒害Web缓存的攻击是响应拆分(response splitting)[23]攻击。与上述两个漏洞不同(共享缓存本身的漏洞是攻击成功的原因之一),响应拆分攻击利用原始服务器中的解析问题。在这种攻击方法中,攻击者利用了以下事实:在相应的响应头中重播请求头值时,原始服务器的HTTP引擎不会对逃脱符或者换行符进行处理。恶意客户端可以通过将响应分为两个响应来利用此漏洞。这种攻击的目的是利用第二响应中包含的恶意内容来毒化中间缓存。

​ James Kettle[22]提出了一组缓存度化的攻击,分别是由于Web应用程序框架和内容管理系统的不当行为引起的。借助引入的技术,James Kettle能够破坏知名公司的共享Web缓存系统。

​ 所有引入的攻击旨在利用恶意内容来毒害共享缓存,这些恶意内容由受害者缓存针对良性客户端的重复请求提供服务。诸如Web浏览器缓存之类的专用缓存不受上述攻击的影响。但是,浏览器缓存无法抵抗此类攻击。Jia提出了浏览器缓存中毒(Browser cache poisoning,BCP)攻击。在他们的研究中,他们发现许多桌面Web浏览器都容易受到BCP攻击。

​ Web缓存欺骗(web cache deception)[15]攻击的目标是利用敏感内容来毒害共享缓存。在这种攻击中,攻击者利用了共享缓存违反了RFC 7234行为,即使该缓存被禁止,该缓存仍然存储响应。结合原始服务器的请求路由中的问题,作者能够从缓存中检索第三方的帐户信息。

​ Triukose等人[39]显示了另一种利用Web缓存系统使Web应用程序瘫痪的攻击媒介。与之前的威胁不同,这种攻击不打算使用恶意的内容来毒害缓存或者是窃取敏感信息。Triukose等人的目标旨在借助已部署的CDN发起DoS攻击。作者利用了CDN的基础架构,该基础架构由许多协作的边缘缓存服务器组成。Triukose等人在URL查询中附加了随机字符串,这能够绕过任何边缘缓存服务器,以便CDN将每个请求都转发到原始服务器。为了发起DoS攻击,作者将带有不同随机查询字符串的多个请求发送到CDN中的所有边缘缓存服务器。随着边缘缓存服务器将所有这些请求转发到原始服务器,到达原始服务器的大量请求会使其瘫痪,结果Web应用程序无法处理任何其他合法请求。

​ 几乎所有提出的攻击的根本原因在于两个或更多个不同的消息处理实体对HTTP消息的不同解释,这被称为语义鸿沟(semantic gap)[18]。源于语义鸿沟的漏洞是多方面的[7,23,37]。 关于Web缓存,请求走私host of troubles响应拆分攻击利用了缓存和原始服务器之间的这种差别。在这里,解析重复的标题或换行符时的差异会导致缓存中毒。

​ 在下一节中,我们将介绍针对Web缓存的新型攻击,即Cache-Poisoned Denial-of-Service(CPDoS)攻击。它利用了共享缓存和源服务器之间的语义鸿沟,使用错误页面来毒害缓存。当缓存中毒后,缓存将分发错误页面而不是正确的页面。正常的用户就会认为页面出现了错误。与Triukose等人介绍的DDoS攻击相反,CPDoS仅需要非常基本的攻击技能和资源。

4. POISONING WEB CACHES WITH ERROR PAGES

​ 一般的攻击思路是利用两个不同的HTTP引擎中的语义鸿沟——一个包含在共享缓存中,另一个包含在源服务器中。更具体地说,新引入的Web缓存中毒变体基本上利用了这样一种情况,即与原始服务器相比,已部署的缓存系统在处理请求方面更为宽松或集中(参见图2)。攻击者可以通过在请求中包含自定义的恶意标头或多个有害标头来利用此差异。此类标头通常在不进行任何更改的情况下转发到原始服务器。结果,攻击者精心制作的请求毫无问题地通过了缓存,而服务器端处理导致了错误。此后,服务器的响应是一个相应的错误,该错误将被缓存存储并重新用于重复的请求。对受感染的URL进行后续GET请求的每个良性客户端将收到存储的错误消息,而不是从缓存中获取真正的资源。

缓存中毒的拒绝服务(CPDoS)攻击的一般构造

图2 缓存中毒的拒绝服务(CPDoS)攻击的一般构造
​ 值得注意的是,一个简单的请求就足以用错误页面替换缓存中的真实内容。这意味着这样的请求特别是在Web应用程序防火墙(WAF)和DDoS保护工具的检测阈值以下,因为它们是通过扫描大量的不规则网络流量来进行工作的,而CPDoS无法触发它们。

​ Web应用程序的结果取决于内容被错误页面非法替换。它总是会影响服务的部分可用性或者全部可用性。最无害的CPDoS会使图像或样式资源不可用。这会影响应用程序各部分的视觉外观,但是不影响正常效果。针对起始页或重要脚本资源的更严重的攻击可能导致整个Web应用程序无法访问。此外,可以利用CPDoS来阻止经由高速缓存分发的补丁或固件更新,从而防止修复设备和软件中的漏洞。攻击者还可以在关键任务网站(例如,在线银行或官方政府网站)上禁用重要的安全警报或消息。想象一下,CPDoS攻击可能会阻止有关网络钓鱼电子邮件或自然灾难的警报。

​ 考虑到攻击者的工作量少,成功的可能性高,被检测到的机会低以及DoS带来的后果相对较高,所以CPDoS攻击构成了高风险。因此,值得研究在什么条件下CPDoS攻击可以在自然情况下发生。因此,我们首先分析了相关RFC [16],[25],[32],[9],[8],[34],[13],[11], [4]和[5](见表1)。此外,我们分析了流行的代理缓存和CDN是否确实存储和重用了原始服务器返回的错误代码。这项探索性研究是通过Nguyen等人[30,31]的方法进行的。它们提供了可免费使用的缓存测试工具,用于系统地分析Web浏览器缓存,代理缓存和CDN。缓存测试工具还提供了一个包含397个测试用例的测试套件,可以通过测试用例的规范语言对其进行自定义。我们通过添加新的测试来扩展套件,以评估包含错误状态代码的响应的缓存。在我们的研究中,我们分析了五个著名的代理缓存,分别是Apache HTTP Server(Apache HTTPD)v2.4.18Nginx v1.10.3Varnish v6.0.1Apache Traffic Server(Apache TS)v8.0.2Squid v3.5.12,以及著名的CDN厂商:AkamaiCloudFrontCloudflareStackpathAzureCDN77CDNSunFastlyKeyCDNG-Core Labs

表1 可缓存错误状态代码概述以及表明状态代码是否由分析的Web缓存系统缓存的经验研究结果
![可缓存错误状态代码概述以及表明状态代码是否由分析的Web缓存系统缓存的经验研究结果](https://clppicturebed.oss-cn-beijing.aliyuncs.com/markdown/1577703076979.png)

​ 即使错误代码的可缓存性由上面给出的一系列RFC规范明确定义,我们的分析也显示出某些Web缓存系统违反了其中一些策略。例如,尽管不允许,但CloudFrontCloudflare确实存储并重复使用错误消息,例如400 Bad Request403 Forbidden500 Internal Server Error。违反Web缓存策略是一个严重的问题,内容提供商和Web缓存系统供应商需要考虑这些问题。最近的出版物表明,不遵守相同的策略可能导致缓存漏洞[7、15、24]。根据这些观察结果,我们进行了进一步调查,以发现其中脆弱的组合。我们能够识别出以下各节中介绍的一般CPDoS攻击的三个具体实例。

4.1 HTTP Method Override (HMO) Attack

​ HTTP标准[13]为客户端定义了一组请求方法,以指示要对给定资源执行的所需操作。GETPOSTDELETEPUTPATCH可以说是Web应用程序和基于REST的Web服务中最常用的HTTP方法[36]。但是,某些中间系统(例如代理,负载平衡器,缓存或防火墙)仅支持GETPOST。这意味着DELETEPUTPATCH请求无法使用。为了规避此限制,许多基于REST的API或Web框架提供了辅助标头,例如X-HTTP-Method-OverrideX-HTTP-MethodX-Method-Override,用于通过无法识别的HTTP方法进行传递。 这些标头通常将由任何中间系统转发。一旦请求到达服务器,方法覆盖标头将指示Web应用程序用方法覆盖标头值中的方法替换请求行中的方法。

​ 当中间系统阻止不同的HTTP方法时,这些方法覆盖标头非常有用。但是,如果Web应用程序支持此类标头并且还使用共享的Web缓存系统,则恶意客户端可以利用此语义鸿沟来执行CPDoS攻击。在典型的HTTP方法覆盖(HMO)攻击流程中,恶意客户端精心制作GET请求,该请求包括HTTP方法覆盖标头,如图3所示。

HTTP方法覆盖(HMO)攻击的流程和示例构造

图3 HTTP方法覆盖(HMO)攻击的流程和示例构造
​ CDN或反向代理缓存将图3中的请求解释为针对 `http://example.org/index.html` 的良性`GET`请求。因此,它将带有`X-HTTP-Method-Override`标头的请求转发到原始服务器。但是,端点将此请求解释为`POST`请求,因为`X-HTTP-Method-Override`标头指示服务器将请求行中的HTTP方法替换为标头中包含的方法。因此,Web应用程序基于`POST`返回响应。假设目标Web应用程序未针对`/index.html`实现任何`POST`相关的方法。在这种情况下,Web框架通常会返回错误消息,例如状态码`404 Not Found`或`405 Method Not Allowed`。共享缓存将返回的响应和错误代码分配给针对`http://example.org/index.html`的`GET`请求。如表1所示,由于状态代码`404 Not Found`和`405 Method Not Allowed`可以根据HTTP缓存`RFC 7231`进行缓存,因此缓存将此错误响应存储并重用于重复的请求。每个对`http://example.org/index.html`进行后续`GET`请求的良性客户端都会收到缓存的错误消息,而不是合法的Web应用程序的起始页。

4.2 HTTP Header Oversize (HHO) Attack

​ HTTP标准没有为请求标头定义任何大小限制。因此,中间系统,Web服务器和Web框架指定了自己的限制。大多数Web服务器和代理缓存均提供8000个字节的请求标头限制,以避免诸如请求标头溢出[26]或ReDoS [38]攻击等安全威胁。但是,也有中间系统,其指定的限制大于8000个字节。例如,Amazon CloudFront CDN最多允许24713字节。在一项探索性研究中,我们收集了由各种HTTP引擎和缓存系统部署的默认HTTP请求标头限制(请参见表3)。

表3 HTTP实现的请求标头大小限制
![HTTP实现的请求标头大小限制](https://clppicturebed.oss-cn-beijing.aliyuncs.com/markdown/1577704232442.png)

​ 就不同的请求标头大小限制而言,这种语义上的差距可以被利用来进行CPDoS攻击。要执行HTTP Header Oversize(HHO)攻击,恶意客户端需要发送GET请求,该请求包含的标头要大于原始服务器的限制,但要小于路径上缓存系统中最小的那个。 为此,攻击者有两个选择。 首先,他设计了带有许多恶意标头的请求标头。 另一种选择是包括一个带有超大键或值的单个标头,如图4所示。

HTTP标头超大(HHO)攻击的流程和示例构造

图4 HTTP标头超大(HHO)攻击的流程和示例构造
​ Web缓存系统将包括超大标头的此请求转发到端点,因为标头大小在缓存系统的限制内。但是,Web服务器将阻止此请求并返回错误页面,因为该请求超出了标头大小限制。此返回的错误页面已存储,将被重新用于其他重复请求。

4.3 HTTP Meta Character (HMC) Attack

​ HTTP元字符(HMC)的工作方式类似于HHO攻击。此攻击不是发送过大的标头,而是尝试通过包含有害元字符的请求标头绕过缓存。元字符可以是控制字符,例如回车符(\n),换行符(\r)或任何其他Unicode控制字符。由于响应拆分攻击使用\n\r字符来毒害缓存,因此某些HTTP实现会阻止包含这些符号的请求。

​ 丢弃此类字符的HTTP实现通常会返回一条错误消息,表明它们不解析此请求。但是,有些缓存中介并不关心某些控制字符。他们只是将包含元字符的请求转发到原始服务器,原始服务器返回错误代码。然后将生成的错误页面存储并由高速缓存重新使用。恶意客户端可以利用此来进行另一种形式的CPDoS攻击。我们将此漏洞声明为HTTP Meta Character(HMC)攻击。为此,攻击者会使用元字符(例如\n,如图5所示。此示例攻击的目的是欺骗原始服务器,使其认为它受到响应拆分请求的攻击。与以前介绍的漏洞一样,HMO请求可以绕过缓存,而不会出现任何问题。一旦请求到达端点,该请求将被阻止,并返回相应的错误页面,因为Web服务器知道与\n等可疑字符有关的含义。然后,此错误消息将由相应的Web缓存系统存储和回收。

HTTP Meta Character(HMC)攻击的流程和示例构造

图5 HTTP Meta Character(HMC)攻击的流程和示例构造
### 5. PRACTICABILITY OF CPDOSATTACKS ​ 为了探索自然环境中存在的CPDoS攻击点,我们进行了一系列实验。潜在的CPDoS漏洞的关键先决条件是Web缓存系统,该系统存储和重用原始服务器生成的错误页面。表1突出显示了`Varnish`,`Apache TS`,`Akamai`,`Azure`,`CDN77`,`Cloudflare`,`CloudFront`和`Fastly`。基于这些发现,我们进行了三个实验(每个引入的CPDoS变体一个),以检查这些中间系统是否易受CPDoS攻击。

5.1 Experiments Setup

​ 分析实际环境中是否存在CPDoS漏洞的第一步是找出用作原始服务器的、且易受攻击的HTTP实现。原始服务器上的HTTP实现可以是多种系统,包括例如反向代理,Web服务器,Web框架,云服务或其他中间系统以及另一个缓存。

​ 在我们的第一个实验中,我们分析了Web框架中方法覆盖标头的支持。此外,我们还评估了在发送方法覆盖标头时所返回的错误页面,该方法覆盖标头包含未由相应资源端点实现的HTTP方法。根据表1中的发现,我们知道哪些Web缓存系统存储了哪些错误页面,我们推断出将哪些Web框架与哪些Web缓存系统结合使用可能会受到HMO攻击。对于此经验分析,我们根据IEEE Spectrum[17],基于最流行的编程语言选择了13个Web框架。分析的Web框架集合包括ASP.NET v2.2BeeGo v1.10.0Django v2.1.7Express.js v.4.16.4Flask v1.0.2Gin v1.3.0Laravel v5.7Meteor.js v1.8Rails v5.2.2Play Framework 1(Play 1)v1.5.1Play Framework 2(Play 2)v2.7Spring Boot v2.1.2Symfony v4.2

​ 第二个实验调查了表1中的Web缓存系统以及13个Web框架的请求标头大小限制。由于Web框架ASP.NETSpring Boot需要在生产模式下部署基础Web服务器,因此我们还评估了Microsoft Internet信息服务(IIS)v10.0.17763.1Tomcat v9.0.14的请求标头限制。此外,我们还评估了流行的云服务,包括Amazon S3Github PagesGitlab PagesGoogle StorageHeroku。与第一个实验一样,我们还测试了超出请求标头大小限制时返回的错误代码。通过这些发现,我们找出了哪些HTTP实现以及哪些Web缓存系统可能容易受到HHO攻击。

​ 最后一个实验评估了HMC攻击的可行性。在这里,我们评估了所有提到的Web缓存系统,Web框架,Web服务器和云服务中元字符的处理。为了测试尽可能多的元字符,我们收集了520个可能令人讨厌的字符串作为列表。此集合包含控制、特殊、国际和其他Unicode字符,以及包含攻击向量的字符串,包括跨站点脚本(XSS),SQL注入和远程执行攻击。这项研究的目的是分析什么字符和字符串被阻塞,“消毒”,处理或转发而没有任何问题。此外,我们还评估了阻止字符或字符串时触发了什么错误页面。根据我们的发现,我们能够得出结论,哪些字符和哪些符号需要发送到HTTP引擎和Web缓存系统的哪个组合中,以引发HMC攻击。

5.2 Feasibility of HMO attacks

​ 表2显示了第一个实验的结果。 它强调了默认情况下,SymfonyLaravelPlay 1支持方法覆盖标头DjangoExpress.js缺省情况下不考虑方法覆盖标头,但是提供插件来添加此功能。Flask没有提供任何插件来集成方法覆盖标头,但是提供了一个官方教程来启用它[14]。表2还指出了当Web框架接收到方法覆盖标头时,返回的错误代码,该标头并不是由寻址的资源端点来实现的。

表2 已测试的Web框架的HTTP方法覆盖标头支持
![已测试的Web框架的HTTP方法覆盖标头支持](https://clppicturebed.oss-cn-beijing.aliyuncs.com/markdown/1577757398202.png)

​ 即使具有方法覆盖标头的Web框架支持返回可缓存的错误代码,我们也观察到只有Play 1Flask容易受到HMO CPDoS攻击。但是,只有将FastlyAkamaiCloudflareCloudFrontCDN77Varnish用作中间缓存时,两个Web框架才会受到影响。这些Web框架易受攻击的原因在于,在存在HTTP方法覆盖标头的情况下,Play 1Flask确实会对GETPOST请求执行HTTP方法更改。LaravelSymfony以及DjangoExpress.js的插件不受HMO CPDoS的攻击,因为它们忽略GET请求中的HTTP方法覆盖标头,并限制自己仅对POST请求进行转换。攻击者无法使用POST请求来毒害经过测试的Web缓存系统,因为它们中的任何一个都不存储对POST请求的响应。

​ 恶意客户端可以通过发送带有方法覆盖标头(包括使用POST作为值)的GET请求来攻击用Play 1实现的Web应用程序。如果相应的资源端点未实现POST的任何功能,则Web框架将返回错误代码404 Not Found。默认情况下,AkamaiFastlyCDN77CloudflareCloudFrontVarnish会缓存此状态代码(请参见表1)。如果HTTP方法覆盖标头的支持是通过Web框架网站的官方教程实现的,则Flask也容易受到HMO CPDoS攻击。但是,只有当AkamaiCloudFront被用作CDN时,HMO攻击才有可能,因为Flask返回状态码405 Method Not AllowedAkamaiCloudFront是仅有的分析过的Web缓存系统,它们使用此代码存储和重用错误页面。

5.3 Feasibility of HHO attacks

​ 表3描述了我们对请求标头大小限制的研究结果。此外,它还列出相应HTTP实现的文档中指定的请求标头大小限制。请注意,此表中省略了Web框架ASP.NETDjangoFlaskLaravelRailsSymfonySpring Boot,因为我们发现请求标头限制取决于所使用的Web服务器和部署环境。

​ 我们获得的结果揭示了HTTP实现中请求标头大小限制方面的多种变化。评估显示,CloudFront提供了请求标头大小限制,该限制比我们测试的任何一个其他的HTTP实现都要高得多。此外在默认情况下,Amazon的CDN还缓存错误代码400 Bad Request(请参见表1),该错误代码在超出请求标头大小限制时由大多数HTTP实现触发。因此,在我们的实验中,我们发现,当将CloudFront用作CDN时,任何请求标头大小限制低于CloudFront并返回状态代码400 Bad Request(如果超过此限制)的HTTP实现都容易受到HHO CPDoS攻击。例如,Web缓存系统Apache HTTPDNginx(也可用作Web服务器或反向代理)提供的请求标头大小限制比CloudFront低。

​ 根据Netcraft的调查[28],Apache HTTPDNginx是最常用的Web服务器,而且这两个系统还经常与其他中间系统一起部署。当将这两个HTTP实现之一与CloudFront结合使用时,这些系统可能会受到HHO CPDoS攻击的影响。这也意味着,如果将Apache HTTPDNginx配置为其他Web应用程序之前的中间反向代理,则这些系统也容易受到HHO CPDoS的攻击。此外,Apache HTTPDNginx通常用作Web服务器和Web框架(如RailsDjangoFlaskSymfonyLavarel)的部署环境。如果将所有这些Web框架与Apache HTTPDNginx一起部署,则同样容易受到HHO CPDoS的攻击。Spring BootASP.NET也可能受到HHO CPDoS攻击的影响,因为这两个Web框架都需要生产模式下的Web服务器。Spring Boot可以与Tomcat一起部署,而ASP.NET可以将IIS用作基础部署环境。TomcatIIS的请求标头大小限制低于CloudFront。两台Web服务器同样针对超过大小限制的标题返回错误代码400 Bad Request。云服务Heroku是Web框架的另一个部署平台。它支持例如DjangoFlaskLaravelRailsLaravelSymfony。由于Heroku提供的请求标头大小限制低于CloudFront,因此将云服务与CDN结合使用的Web应用程序也容易受到攻击。将CloudFront用作CDN时,可能受HHO CPDoS攻击影响的其他HTTP实现是Play 2以及云服务Amazon S3Github PagesHerokuPlay 1也容易受到HHO CPDoS攻击,即使在超出请求标头大小限制时它不返回错误页面。如果Web框架接收到过大的标头,则不返回任何响应。在此,TCP socket保持打开状态,直到Web应用程序关闭。如果CloudFront注意到这样的空闲通信通道,则CDN返回错误代码502 Bad Gateway。该错误消息同样被存储并用于重复请求。根据我们的实验,尽管云服务的请求标头大小限制低于CDN,但结合了CloudFront的Google存储不易受到HHO CPDoS的攻击。对于超大标头,Google存储返回错误代码413 Payload Too Large,并且任何分析的Web缓存系统都不会缓存此错误消息。表3还包含将Nginx与WAF插件ModSecurity一起使用时获得的结果。在这种配置下,成功进行HHO CPDoS攻击甚至没有安全性扩展都更加容易。Nginx的经过测试的请求标头限制约为20000个字节,但是当将ModSecurity添加到两个系统时,它将限制减少到8190个字节。即使ModSecurity的使用实际上应避免Web应用程序攻击(例如DoS),但在这种情况下,仍易于进行HHO CPDoS攻击。

​ 如前所述,在将CloudFront用作CDN时,在此Web服务器上运行的IIS和Web框架(例如APS.NET)容易受到HHO CPDoS攻击。但是,在某些情况下,当使用AkamaiFastlyCDN77CloudflareVarnish时,它们也可能很脆弱。IIS Web服务器提供了为不同的请求标头设置大小限制的选项。某些Web应用程序需要这样的配置选项来阻止过大的Cookie标头等情况。如果为请求标头定义了此限制,并且超出了此限制,则Web服务器将返回错误代码404 Not FoundAkamaiFastlyCDN77CloudFrontCloudflareVarnish会缓存此错误消息。

5.4 Feasibility of HMC attacks

​ 表4显示了我们第三次实验的结果,其中我们分析了包含元字符的字符串的处理。为了便于阅读,我们只列出了至少被实际阻止过一次的字符和字符串。此外,此表中省略了Web框架ASP.NETDjangoFlaskLaravelSpring BootSymfony,因为元字符的处理取决于所使用的Web服务器和部署环境而不是这些框架。

表4 HTTP实现的请求标头中的元字符串处理
![HTTP实现的请求标头中的元字符串处理](./1577758484237.png)

​ 评估突出表明,我们分析过的许多系统都将控制字符视为威胁。可疑字符或字符串被指示的错误代码阻止或从请求标头中清除。但是,元字符串和字符的处理非常不同。例如,CloudFront阻止字符\u0000并清除\n\v\f\r,但转发其他控制字符(例如\a\b\e)而无需对其进行修改。如果将Apache HTTPDIISVarnishCloudFront一起使用,则相应的系统会阻止转发的标头包含状态码为400 Bad Request的禁止字符。CloudFront会存储此类错误消息。这意味着,当将CloudFront用作CDN时,所有经过测试的HTTP实现(即那些阻止了CloudFront不去阻止的有害字符串和字符的那些实现)都容易受到HMC CPDoS攻击。除了Apache HTTPDIISVarnish,它还包括Github PagesGitlab PagesBeeGoGinMeteor.jsPlay2Express.js也容易受到HMC CPDoS攻击,即使它使用错误代码。这里的问题类似于Play 1中标头过大的问题。当发送带有多个控制字符的请求标头时,Express.js根本不会答复。因此,CloudFront将错误消息502 Bad Gateway返回给客户端。此错误代码也将被存储并重新用于后续请求。

5.5 Consolidated Review of Analysis Results

​ 根据我们对所有三个实验的发现,我们在Web缓存系统和HTTP实现的各种不同组合中检测到许多CPDoS攻击媒介。如表5所示,大多数攻击都可以在CloudFront上执行。这张表格概述了哪些Web缓存系统和HTTP实现对易受CPDoS攻击。实验结果表明,使用CloudFront的Web应用程序极易受到CPDoS攻击,因为CDN默认情况下会缓存错误代码400 Bad Request。当发送带有超大标头或元字符的请求时,许多服务器端HTTP实现都会返回此错误消息。当利用其他分析的缓存(包括VarnishAkamaiCDN77CloudflareFastly)时,受CPDoS攻击影响的可能性要低得多。这些Web缓存系统确实存储错误代码404 Not Found但未存储400 Bad Request。缓存状态代码为404的错误页面是优化网站性能的正确且合规的方法。在这种情况下,VarnishAkamaiCDN77CloudflareFastly均不会出现故障。成功进行CPDoS攻击的原因在于,Play 1Microsoft IIS允许在资源端点上引发404 Not Found错误页面,这些页面在发送良性请求时不会返回错误消息。

表5 CPDoS危害性概览
![CPDoS危害性概览](./1577759396397.png)

5.6 Practical Impact

​ 在评估CPDoS攻击的实际影响的第一步中,我们确定了使用表5中列出的易受攻击的Web缓存系统和HTTP实现之一的网站数量。寻找易受攻击的真实网站的方法是检查响应标头。

​ 许多HTTP实现将信息标头附加到响应中,以声明此实体正在处理消息。例如,CloudFront“Hit from CloudFront ”“Miss from CloudFront”添加到x-cache头中,Microsoft IIS将字符串Microsoft-IIS添加到Server头中。借助此信息,攻击者可以明确检测目标Web应用程序分别使用了什么缓存或服务器端HTTP实现。基于这种方法,我们分析了美国国防部(DoD)的网站和Alexa 500强网站。除此之外,我们还使用Google Big Query服务调查了HTTP存档数据集httparchive.summary_requests.2018_12_15_-desktop中存储的超过3.65亿个URL。表6显示了DoD,Alexa Top 500和HTTP Archive的网站和URL的数量,其中响应标头指示内容是由易受攻击的HTTP实现处理的。

表6 使用不同CDN的网站/URL数
![使用不同CDN的网站/URL数](./1577759788512.png)

​ 结果表明,CloudFront提供了八个DoD网站,Alexa 500强中的23个网站以及在上面的数据集中提到的1200万个URL。此外,国防部的所有八个网站,Alexa Top 500的16个网站以及HTTP存档的超过900万个URL都指出,CloudFront结合使用了Apache HTTPDNginxAmazon S3Microsoft IISVarnish。我们的实验表明,这些组合很容易受到CPDoS攻击(请参阅表5)。但是,如果不逐一检查每个漏洞网站,则很难估计出它们的确切数量。而且,实验是在默认配置下完成的,没有考虑任何其他中间系统。但是,内容提供者更改缓存的默认配置以使缓存策略适应各自的需求是非常普遍的。此外,现实世界的Web应用程序还利用其他中间系统,例如负载平衡器或WAF。所有这些设置都会在任何情况下影响CPDoS攻击的实用性。为了更清楚地了解CPDoS攻击对现实生活的影响,我们基于Alexa Top 500,DoD和HTTP Archive数据集的URL进行了一些采样。总体而言,我们在几天内发现了十二个易受攻击的资源。包括了将CloudFront用作CDN的网站,例如ethereum.orgmarines.comnasa.gov。在所有这些网站上,我们都能够阻止多种资源,包括脚本,样式表,图像,甚至是动态内容,例如起始页。附录A中的图6和图7显示了CPDoS攻击的视觉损害。在图6中,首先将CPDoS攻击应用于受害者网站ethereum.org起始页中引用的图像。然后,样式表文件被拒绝,最后,错误页面替换了整个开始页面。图7说明了marines.com受影响的开始页面,该页面向用户显示错误页面而不是真实的内容。此外,我们还能够对宜家智能家居设备的更新文件进行成功的CPDoS攻击。宜家将CloudFrontS3结合使用,用来替无线灯泡分发远程控制固件和驱动程序更新。由于CloudFrontS3结合使用时容易受到HHO CPDoS攻击,因此攻击者可以阻止IKEA的远程控制设备获取安全补丁。这些证据表明,CPDoS攻击可以影响静态和动态资源。大多数易受攻击的网站都将CloudFront用作CDN。但是,CPDoS攻击对现实世界的影响不仅限于CloudFront。我们还在样本中发现了易受攻击的网站,这些网站与Play 1结合使用了其他CDN,例如AkamaiCloudflare。我们仅在几天内就发现了这些示例。具有政治和经济动机的高级攻击者很容易就能够收集更多易受攻击的资源,因为他们只需要调查响应标头即可估计目标网站或资源是否可能受到CPDoS攻击。此外,通过Google Big Query免费提供的HTTP存档数据集包括数百万个URL,攻击者可以对其进行调查。例如,HTTP存档数据集httparchive.summary_requests.2018_12_15_desktop包含超过900万个URL,我们将其视为高度脆弱,因为这些资源的响应标头表明CloudFrontApache HTTPDNginxAmazon S3Microsoft IISVarnish一起结合使用。其中还包括许多重要的网站和资源,包括亚马逊本身,网站dowjones.com以及通过CloudFront分发固件的Logitech

5.7 Practical Considerations

​ 缓存仅在cdn存储和重用错误页面时才容易受到CPDoS攻击。Web缓存系统(例如StackpathCDNSunKeyCDNG-Core实验室)不会受到CPDoS攻击的影响,因为这些CDN根本不缓存错误消息。 当Apache HTTPDNginxSquid用作中间缓存而不涉及任何其他易受攻击的Web缓存系统时,也是如此。

​ 与其他缓存中毒漏洞一样,仅当易受攻击的Web缓存系统不包含要攻击的资源的新副本时,才可能进行CPDoS攻击。也就是说,如果共享缓存仍保持并为重复的请求重用存储的新响应,则恶意请求将不会毒害中间的缓存系统。Web缓存系统将所有请求提供给目标资源。在新鲜度生存期到期之前,不会将任何请求转发到原始服务器,因此不会触发任何错误页面。这意味着,如果缓存仍然拥有新的响应,则攻击者必须等待,直到缓存的内容过期。找出到期时间的最直接信息是Expires标头,它指示绝对到期日期。如果响应中不包含Expires标头,或者此标头的到期时间被max-ages-maxage指令覆盖,则攻击者可以使用Age标头。Age标头声明了保留在缓存中的秒数。从max-ages-maxage指令的值中减去的Age标头的值是缓存的响应的相对到期时间。如果缓存的响应已过期,则攻击者的请求必须是第一个请求,这样它才能到达原始服务器以触发错误页面。为了增加成为第一个请求的可能性,当响应即将到期时,我们以一秒钟的间隔发送自动请求。使用这种技术,我们能够成功地攻击我们抽查实验的所有十二个易受攻击的网站。以一秒的时间间隔发送定期执行的请求也是一种用于缓存的响应的有用方法,该缓存的确包含任何到期时间信息,即隐式缓存的资源。这样的响应通常不包含任何max-ages-maxage指令以及Expire标头。在这里,攻击者需要发送自动请求,直到其中一个请求转发到原始服务器为止。此外,间隔一秒钟的自动请求即使长时间发送也不会被认为是有害的,因为运行状况检查请求也可以具有相同的间隔。我们在多个CDN(包括WAF和DDoS保护)上测试了此技术。由于我们仅使用一个客户端进行攻击,因此CDN均未检测到恶意请求。

​ 许多Web应用程序将代理缓存或CDN配置为服务整个网站。这意味着所有资源(包括动态页面和静态文件)都将由缓存转发和处理。为了避免动态页面被隐式缓存,内容提供者在响应头中包括no-storemax-age = 0,因此必须将每个请求转发到原始服务器。如果将易受攻击的缓存与易受攻击的服务器端HTTP实现结合使用,则可以对这些资源进行攻击,而无需等待,也不会自动发送请求。一个恶意请求足以使目标资源瘫痪,因为每个请求都被转发到原始服务器。将CDN配置为可使用所有资源的脆弱网站,这些网站包含marines.comethereum.orgnasa.gov

​ 还有许多Web应用程序仅将缓存配置为存储和重用某些URL路径的响应,例如javascriptimages目录中的静态文件。因此,其他URL路径根本不会被缓存。许多内容提供商还维护子域(例如static.example.org)或通过缓存提供服务的静态文件的特定域。在这些情况下,仅影响缓存的URL路径或特定域内的资源。为了找出不同的响应是否遍历缓存,攻击者可以检查响应标头。例如,Age响应标头指示使用了高速缓存。宜家的主要网站(ikea.com)没有使用CloudFront或任何其他易受攻击的HTTP实施,这表明此主页最有可能不受CPDoS攻击。但是,宜家将特定域(fw.ota.homesmart.ikea.net)与CloudFront结合使用来托管其物联网设备的更新文件。

​ CPDoS攻击的另一个重要限制是Web缓存系统(除Fastly之外)仅将错误页面缓存几分钟或几秒钟。快速存储并重复使用错误页面一小时。如果该时间段结束,则对目标资源的第一个良性请求将转发到原始服务器并再次刷新。尽管如此,为了延长CPDoS攻击的持续时间,恶意客户端仍可以按照固定间隔重新发送有害请求。

6. RESPONSIBLE DISCLOSURE

​ 所有发现的漏洞已于2019年2月19日报告给HTTP实现的供应商和缓存提供商。我们与这些组织紧密合作,以支持他们消除检测到的威胁。我们没有直接通知网站所有者,而是将其留给了联系实体以通知其客户。

​ 亚马逊网络服务(AWS)。我们已将此问题报告给AWS-Security团队。他们确认了CloudFront上的漏洞。默认情况下,AWS-Security团队已停止缓存状态代码为400 Bad Request的错误页面。但是,他们花了三个月的时间来修复我们的CPDoS报告。不幸的是,整个公开过程的特点是单向沟通。我们定期询问当前状态,而没有从AWS-Security团队那里获得很多信息。他们从未与我们联系以使我们及时了解当前流程。例如,仅通过查看Github中托管的各自文档的修订历史记录,我们才注意到更改后的默认缓存策略。因此,尽管明确提出了要求,但我们对于解决报告的CPDoS漏洞所需的可观时间没有太多信息。我们只能假设此延迟与他们在实施对策后必须测试的大量受影响用户有关。此外,Amazon建议用户在相应的CloudFront实例之前部署AWS WAF。 AWS WAF允许定义规则,以在恶意请求到达原始服务器之前将其删除。

​ 微软。Microsoft能够重现报告的问题,并发布了更新来缓解此漏洞。他们将此案分配给CVE-2019-0941[27],该案于2019年6月发布。

Play 1Play 1的开发人员确认了所报告的问题,并提供了安全补丁程序,此安全补丁程序限制了X-HTTP-Method-Override标头的影响[6]。该安全补丁包含在1.5.31.4.6版本中。此安全修补程序不维护较旧的版本。因此,使用Play 1的较旧版本的Web应用程序应该更新为最新版本,以减轻CPDoS攻击。

Flask。我们多次向Flask的开发人员小组报告了HMO攻击。不幸的是,到目前为止我们还没有收到任何答复,因此我们不得不假设基于Flask的Web应用程序仍然容易受到CPDoS的攻击。

7. DISCUSSION

​ 使用格式错误的请求来破坏Web应用程序是众所周知的威胁。因此,请求标头大小限制和阻止元字符是避免已知的缓存中毒攻击以及其他DoS攻击(例如请求标头缓冲区流[26]和ReDoS[38])的重要保护手段。同样,许多安全准则,例如Apache HTTPD[2],OWASP[35]和HTTP标准[12]的文档,建议阻止超大的标头和标头中的元字符。但是,CPDoS攻击旨在用自己的武器击败这些安全机制。HHO和HMC CPDoS攻击故意发送带有超大标头或有害元字符的请求,目的是被将被缓存的错误页面阻止。我们发现CDN服务声称是抵御DoS(尤其是DDoS攻击)的有效措施,但在遇到CPDoS时却失败了。

​ 根据我们的实验结果,大多数提出的攻击向量仅在将CloudFront作为基础CDN时才可行,因为它是唯一分析出的非法存储错误代码400 Bad Request的缓存。这种不相称是HHO和HMC攻击的主要原因。两种攻击的另一个主要问题是,高速缓存转发超大的标头和带有有害元字符的请求。违反HTTP标准和实现问题也是导致许多其他与缓存相关的漏洞的主要原因,这些漏洞包括请求走私host of troubles响应拆分Web欺骗攻击。但是,HMO CPDoS攻击是一个漏洞,不会利用任何实现问题和违反HTTP标准的漏洞。X-HTTP-Method-Override标头或类似标头是用于隧道化WAF或Web浏览器不支持的HTTP方法的合法辅助工具。Play 1Flask当收到X-HTTP-Method-Override标头中的不受支持的操作时,会返回错误代码404 Not Found405 Method Not Allowed。两种错误消息都可以根据RFC 7231进行缓存。AkamaiCDN77FastlyCloudflareCloudFrontVarnish遵循此策略并缓存此类错误代码。如果将这些Web缓存系统与上述Web框架之一结合使用,则即使它们符合HTTP标准并且没有任何实现问题,这些组合也有遭受CDPoS攻击的实际风险。因此,HMO CPDoS攻击可以视为一种新型的缓存中毒攻击,它不会利用任何实现问题或违反RFC的漏洞。这表明CPDoS攻击并非总是由于编程错误或无意违反规范策略而引起的,还可能是通过利用两个合法概念之间冲突而产生的。在发生HMO CPDoS攻击的情况下,此冲突是指使用方法覆盖标头和缓存允许的错误消息。

​ 即使我们没有在其他Web缓存系统和HTTP实现中检测到攻击向量,也并不意味着其他组合不容易受到CPDoS攻击。如表1所示,在15个经过测试的Web缓存系统中,有8个确实存储错误页面,其中一些甚至缓存了不允许的错误页面。如果攻击者能够在目标URL上启动其他错误页面,甚至是可缓存的错误代码,那么他可能还会通过CPDoS攻击影响其他Web缓存系统和HTTP实现。例如,詹姆斯·凯特尔(James Kettle)发现了另外两种形式的CPDoS攻击,幸运的是,由于相应Web应用程序的特定实现问题,这种攻击才勉强成功。第一个CPDoS攻击利用了X-Forwarded-Port标头[21]。该标头通常通知端点有关客户端用于连接到中间系统的端口的信息,该中间系统在源服务器的前面运行。在发现的攻击中,缓存的响应包含重定向。拒绝服务是由用户的浏览器尝试遵循缓存的重定向并超时导致的。由于WAF配置错误[20],第二次攻击能够在www.tesla.com上创建DoS。这个网站将WAF配置为阻止某些其他缓存毒害攻击已使用的字符串。不幸的是,带有此类字符串的请求被403禁止错误页面阻止,该页面也已缓存。这表明HMO,HHO和HMC并不是CPDoS攻击的唯一变体。当然,还有许多其他方法可以在原始服务器上引发错误页面。据我们所知,并根据我们在开发Web应用程序方面的经验,在现实世界的Web应用程序和服务中不太可能引发500 Internal Server Error状态代码或其他5xx错误。AkamaiCloudflare确实会缓存5xx错误代码。在这一点上,我们在实验中没有找到引发此类错误消息的方法。

​ 此外,我们需要考虑到当代Web应用程序,尤其是分布式系统通常是分层的。也就是说,它们经常利用其他中间组件,例如负载平衡器,WAF或位于缓存和端点之间的其他安全网关。这样的中间盒或中间件可以提供其他请求标头大小限制,元字符处理或标头覆盖功能。此类系统还可能对恶意请求做出反应,并带有可能被缓存的错误代码。

8. COUNTERMEASURES

​ 对抗CPDoS攻击最直观、最有效的对策是从缓存错误页面中排除错误页面。但是,排除了诸如404未找到之类的可缓存错误代码的内容提供者,需要考虑此设置可能会损害性能和可伸缩性。有两种方法可以从缓存中排除错误页面。第一种方法是将Web缓存系统配置为省略错误响应的存储。AkamaiCDN77CloudFrontCloudFrontFastlyVarnish提供了这样做的选项。内容提供者还可以将no-store指令添加到Cache-Control响应标头中,该标头禁止所有缓存存储内容。根据我们自己的评估,除CloudFront之外,所有经过测试的Web缓存系统都在错误页面中使用了关键字no-store。在2019年2月进行实验时,CloudFront默认将错误页面缓存五分钟,甚至在错误响应标头中没有存储时也是如此。避免在CloudFront中存储错误页面的唯一方法是通过CDN的配置界面禁用每个错误代码的缓存。幸运的是,在我们执行CPDoS报告后,AWS更改了缓存错误页面的行为。一个重要的更改是默认情况下不再缓存400个“错误请求”错误页面。如果CloudFront包含max-ages-maxage控制指令[1],则它们仅缓存400个Bad Request错误消息。

​ 如前所述,在忽略控制指令方面违反HTTP标准是导致许多与缓存相关的漏洞的主要原因。因此,除了考虑与缓存相关的控制指令外,Web缓存系统还必须仅存储HTTP标准所允许的错误代码。不允许缓存诸如400 Bad Request之类的状态代码,因为此错误消息仅专用于格式错误或无效的请求。可以缓存其他错误代码,例如404未找到405方法不允许410消失,因为它们提供了对所有客户端有效的错误信息。同样,HTTP实现必须针对相应的错误情况使用适当的状态代码。表3显示了几乎所有测试过的系统针对超大请求头返回状态代码400 Bad Request。当超出特定请求标头的限制时,IIS甚至以状态答复可缓存的404 Not Found错误代码。对于超过标题大小限制的请求,两种错误消息都不适合。根据HTTP标准,适当的错误代码是431请求标头字段太大。此类错误信息不会被任何经过测试的Web缓存系统存储和重用。为了测试缓存的一致性和行为,我们建议使用Nguyen等人的缓存测试工具[31]或Mark Nottingham[33]的工具。

​ 对抗CPDoS攻击的另一种非常有效的对策是使用WAF。许多CDN提供了启用WAF的选项,以保护Web应用程序免遭恶意请求。为了避免CPDoS攻击,内容提供商可以将WAF配置为显式阻止超大请求,以及阻止带有元字符或恶意标头的请求。但是,只有在缓存中或缓存的前面实现了WAF时,使用WAF才有效,因为可以消除有害请求,然后再将它们转发到原始服务器。第5节中的实验以及www.tesla.com[20]上的James Kettle的CPDoS攻击表明,集成在原始服务器(如ModSecurity)上的WAF不能帮助抵御CPDoS攻击。在原点被WAF阻止的请求仍然可以触发由缓存存储的错误页面。

​ 此外,我们建议在RFC 7230[12]的“安全注意事项”部分添加一个小节,用来讨论不符合协议规范的后果,以避免HHO,HMC和其他Web缓存中毒攻击。RFC 7230的“安全注意事项”部分提到了缓存中毒攻击,包括响应拆分和请求冒名顶替。但是,该标准仅提出与这两种特定攻击有关的建议。该规范并未提及许多与缓存相关的攻击的根源在于违反该标准。这样的附加描述将提高开发人员对符合规范的意识。另一方面,不能通过遵循标准来避免HMO攻击,因为它们基于非标准手段,在这种情况下,该手段是X-HTTP-Method-Override标头。为了在保持可伸缩性的同时避免HMO攻击,内容提供商不需要从缓存中排除404 Not Found405 Method Not Allowed错误代码。在这里,易受攻击的Web框架必须遵循SymfonyLavarel以及DjangoExpress.js的插件的方法。这些HTTP实现支持方法重写标头,但仅在请求行中的方法为POST时考虑更改操作。这样,恶意GET请求无法触发404 Not Found错误页面,因为方法覆盖标头会被忽略。当尝试通过带有包含GET的方法覆盖标头的POST请求对缓存进行缓存时,返回的响应不会被任何经过测试的缓存存储。而且,使用非标准标头是进行詹姆斯·凯特尔[22]描述的其他缓存中毒攻击的通用方法。HTTP实现的责任是仔细集成非标准标头以避免此类攻击。为了分析标准化或非标准标题对缓存的影响,开发人员和软件测试人员可以使用例如Nguyen等人[31]和Mark Nottingham[33]的测试工具。

9. CONCLUSION AND OUTLOOK

​ 源于语义鸿沟的漏洞会导致严重的安全威胁。由于分布式系统由不同的层组成,因此特别容易受到此类攻击。 它们的存在是对对象进行不同解释的一个主要前提,在这种情况下,应用程序消息将通过缓存浮动。

​ 在本文中,我们通过引入一类新的攻击——“缓存中毒的拒绝服务(CPDoS)”,扩展了源于语义鸿沟的已知漏洞。我们系统地研究了如何在原始服务器上的请求处理过程中引发错误,以及通过缓存系统存储和分发错误响应的情况。我们介绍了三种具体的CPDoS攻击变体,这些变体是由HTTP方法覆盖标头,标头大小限制和元字符解析的不一致处理引起的。通过确定易受CPDoS攻击的可用Web缓存系统的数量,我们展示了实际的实用性。 结果很严重,因为一个简单的请求足以瘫痪一个较大地理区域内的受害者网站(请参阅附录B中的图8)。根据错误页面阻止的资源,可以逐步禁用网页或Web服务(请参阅附录A中的图6)。

​ 根据我们的实验,在分析的HTTP存档数据集中,有11%的DoD网站,30%的Alexa 500强网站和16%的URL可能受到CPDoS攻击。这些缓存的内容还包括关键任务固件和更新文件。考虑到以下事实:现代分布式应用程序通常遵循Mircoservices[29]和面向服务的体系结构(SOA)[10]的设计原则,其中服务使用不同的编程语言实现并由不同的实体进行操作,因此未来在语义上可能会出现更多的语义漏洞。因此,在需要收集对此类漏洞的更深入了解,以便开发不依赖于系统层的特定实现和连接的强大防护措施。

ACKNOWLEDGMENT

​ 首先,我们要感谢所有审稿人的详细评论。此外,我们还要特别感谢Shuo Chen和James Kettle的反馈和建议。 最后,我们赞赏AWS安全团队,微软安全响应中心和Play框架开发团队的披露流程。

​ 这项工作是由德国联邦教育和研究部在“ Forschung a Fachhochschulen”(合同号13FH016IX6)的资助计划下提供的。

REFERENCES

[1] Amazon. 2019. How CloudFront Processes and Caches HTTP 4xx and 5xx Status Codes from Your Origin. https://docs.aws.amazon.com/AmazonCloudFront/ latest/DeveloperGuide/HTTPStatusCodes.html
[2] Apache HTTP Server Project. 2019. Security Tips. https://httpd.apache.org/ docs/trunk/misc/security_tips.html
[3] G. Barish and K. Obraczke. 2000. World Wide Web caching: trends and techniques. IEEE Communications Magazine 38, 5 (2000), 178–184. https://doi.org/10.1109/ 35.841844
[4] M. Belshe, R. Peon, and M. Thomson. 2015. Hypertext Transfer Protocol Version 2 (HTTP/2). RFC 7540. IETF. https://tools.ietf.org/html/rfc7540
[5] T. Bray. 2016. An HTTP Status Code to Report Legal Obstacles. RFC 7725. IETF. https://tools.ietf.org/html/rfc7725
[6] A. Chatiron. 2019. Define allowed methods used in ’X-HTTP-Method-Override’. https://github.com/playframework/play1/issues/1300
[7] J. Chen, J. Jiang, H. Duan, N. Weaver, T. Wan, and V. Paxson. 2016. Host of Troubles: Multiple Host Ambiguities in HTTP Implementations. In 23th ACM SIGSAC Conference on Computer and Communications Security (CCS). https://doi.org/10.1145/2976749.2978394
[8] G. Clemm and J. Whitehead J. Crawford, J. Reschke. 2010. Binding Extensions to Web Distributed Authoring and Versioning (WebDAV). RFC 5842. IETF. https://tools.ietf.org/html/rfc5842
[9] L. Dusseault. 2007. HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV). RFC 4918. IETF. https://tools.ietf.org/html/rfc4918
[10] T. Erl. 2007. SOA Principles of Service Design. Prentice Hall PTR.
[11] R. Fielding, M. Nottingham, and J. Reschke. 2014. Hypertext Transfer Protocol (HTTP/1.1): Caching. RFC 7234. IETF. https://tools.ietf.org/html/rfc7234
[12] R. Fielding and J. Reschke. 2014. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. RFC 7230. IETF. https://tools.ietf.org/html/rfc7230
[13] R. Fielding and J. Reschke. 2014. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. RFC 7231. IETF. https://tools.ietf.org/html/rfc7231
[14] Flask. 2010. Adding HTTP Method Overrides. http://flask.pocoo.org/docs/1.0/ patterns/methodoverrides/
[15] O. Gil. 2017. WEB CACHE DECEPTION ATTACK. In Blackhat USA. https://blogs.akamai.com/2017/03/on-web-cache-deception-attacks.html
[16] K. Holtman and A. Mutz. 1998. Transparent Content Negotiation in HTTP. RFC 2295. IETF. https://tools.ietf.org/html/rfc2295
[17] IEEE Spectrum. 2018. Interactive: The Top Programming Languages 2018. https://spectrum.ieee.org/static/interactive-the-top-programming-languages-2018
[18] Suman Jana and Vitaly Shmatikov. 2012. Abusing File Processing in Malware Detectors for Fun and Profit. In 33rd IEEE Symposium on Security and Privacy. 80–94. https://doi.org/10.1109/SP.2012.15
[19] Y. Jia, Y. Chen, X. Dong, P. Saxena, J. Mao, and Z. Liang. 2015. Man-in-the- browser-cache. Computers and Security 55, C (2015), 62–80. https://doi.org/10. 1016/j.cose.2015.07.004
[20] J. Kettle. 2018. Bypassing Web Cache Poisoning Countermeasures. https://portswigger.net/blog/practical-web-cache-poisoning
[21] J. Kettle. 2018. Denial of service via cache poisoning . https://hackerone.com/ reports/409370
[22] J. Kettle. 2018. Practical Web Cache Poisoning. In Blackhat USA. https://portswigger.net/blog/practical-web-cache-poisoning
[23] A. Klein. 2004. Divide and Conquer - HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics. White Paper. Sanctum, Inc. https://dl.packetstormsecurity.net/papers/general/whitepaper_httpresponse.pdf
[24] C. Linhart, A. Klein, R. Heled, and S. Orrin. 2005. HTTP REQUEST SMUGGLING. http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf
[25] L. Masinter. 1998. Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0). RFC 2324.IETF. https://tools.ietf.org/html/rfc2324
[26] NATIONAL VULNERABILITY DATABASE. 2010. CVE-2010-2730 Detail. CVE 2010-2730. Nist. https://nvd.nist.gov/vuln/detail/CVE-2010-2730
[27] NATIONAL VULNERABILITY DATABASE. 2019. CVE-2019-0941 Detail. CVE 2019-0941. Nist. https://nvd.nist.gov/vuln/detail/CVE-2019-0941
[28] Netcraft. 2019. January 2019 Web Server Survey. https://news.netcraft.com/ archives/2019/01/24/january-2019-web-server-survey.html
[29] S. Newman. 2015. Building microservices: designing fine-grained systems. O’Reilly.
[30] H. V. Nguyen, L. Lo Iacono, and H. Federrath. 2018. Systematic Analysis of Web Browser Caches. In 2nd International Conference on Web Studies (WS). https://doi.org/10.1145/3240431.3240443
[31] H. V. Nguyen, L. Lo Iacono, and H. Federrath. 2019. Mind the Cache: Large-Scale Analysis of Web Caching. In 34rd ACM/SIGAPP Symposium on Applied Computing (SAC). https://doi.org/10.1145/3297280.3297526
[32] H. Nielsen and S. Lawrence. 2000. An HTTP Extension Framework. RFC 2774.IETF. https://tools.ietf.org/html/rfc2774
[33] M. Nottingham. 2019. HTTP Caching Tests. https://cache-tests.fyi/
[34] M. Nottingham and R. Fielding. 2012. Additional HTTP Status Codes. RFC 6585.IETF. https://tools.ietf.org/html/rfc6585
[35] OWASP. 2017. Denial of Service Cheat Sheet. https://www.owasp.org/index. php/Denial_of_Service_Cheat_Sheet#Mitigation_3:_Limit_length_and_size
[36] L. Richardson and S. Ruby. 2008. RESTful web services. O’Reilly Media, Inc.
[37] J. Somorovsky, M. Heiderich, M. Jensen, J. Schwenk, N. Gruschka, and L. Lo Iacono. 2011. All Your Clouds Are Belong to Us: Security Analysis of Cloud Management Interfaces. In 3rd ACM Workshop on Cloud Computing Security Workshop. ACM, New York, NY, USA, 3–14. https://doi.org/10.1145/2046660.2046664 http://doi. acm.org/10.1145/2046660.2046664.
[38] C.-A. Staicu and M.l Pradel. 2018. Freezing the Web: A Study of ReDoS Vulnera- bilities in Javascript-based Web Servers. In 27th USENIX Conference on Security Symposium (USENIX Security). USENIX Association, Berkeley, CA, USA, 361–376. http://dl.acm.org/citation.cfm?id=3277203.3277231
[39] S. Triukosea, Z. Al-Qudad, and M. Rabinovich. 2009. Content Delivery Networks: Protection or Threat?. In 14th European Symposium on Research in Computer Security (ESORICS). https://doi.org/10.1007/978-3-642-04444-1_23

APPENDIX A: ILLUSTRATIVE EXAMPLES OF CPDOS ATTACK

A.1 Ethereum-website

1577773947870

图6 这些屏幕快照显示了ethereum.org网站的起始页,以及由于成功进行CPDoS攻击而导致部分以及整个页面无法访问的情况。更具体地说,此网站容易受到HHO CPDoS的攻击。
#### A.2 Marines-website

1577774067414

图7 这两个屏幕截图显示了a)和b)成功CPDoS攻击之前,网站marines.com的起始页面。更具体地说,此网站容易受到HHO CPDoS的攻击。
### APPENDIX B: CPDOS ATTACK SPREAD

1577774223219

图8 从a)德国法兰克福和b)美国北弗吉尼亚州向德国科隆的受害源服务器发送CPDoS攻击时,受影响的CDN地区。
至此全文结束。