今天分享的论文主题为一种新型的 Web 缓存投毒攻击技术，Cache-Poisoned Denial-of-Service Attack (CPDoS)。该工作由来自德国科隆应用科学大学的 Hoai Viet Nguyen 博士与 Luigi Lo Iacono 教授，以及汉堡大学的 Hannes Federrath 教授共同完成。作者发现并分析了 CPDoS 新型 Web 缓存投毒攻击技术，攻击者通过构造一个畸形HyperTextTransferProtocol (HTTP) 请求导致受害者网站报错，若错误页面能够被缓存服务器缓存，使用同一缓存服务器的合法用户将无法正常获取资源，实现拒绝服务的攻击效果，攻击的“代价小”、“成功率高”、“难以检测” 且 “危害较大” 。为了评估攻击方式的有效性及实际影响，作者对十数款Web 缓存解决方案进行了测量，发现 1 个缓存代理产品和 5 个 CDN 服务可被攻击，并得到了厂商的积极反馈，受影响的网站包括美国海军陆战队网站、以太坊官网以及 NASA 官网等。论文发表于网络安全领域顶级会议 ACM CCS 2019（录用率 149 / 934 = 15.95%）。

【背景介绍】

Web 缓存服务器通过缓存“常用但不常变化”的静态资源，可以减少对源站的资源消耗并优化客户端访问网站的速度。当客户端通过 Web 缓存服务器访问网站时，缓存服务器会根据客户端发出的请求来判断其是否已经存储在缓存空间中。若存在，则向客户端直接返回缓存空间中的内容；若不存在，其将首先作为代理替客户端请求对应资源，随后将响应的资源内容缓存并转发给客户端。之后当其他用户请求相同的资源时，缓存服务器即可从自己的缓存中返回内容，而无需向源站发起请求。

缓存服务器极大地提升了用户访问网站的体验，也降低了网站的流量费用。由于使用的广泛性，缓存服务器也成为了攻击者垂涎的目标。历史上已经出现过多种针对 Web 缓存的经典攻击，如 HTTP Request Smuggling [1], Host of Troubles [2], Response Splitting [3] 等。上述提到的攻击皆旨在向缓存服务器中存入恶意内容（如：存在恶意 JavaScript 脚本的页面），从而攻击使用相同缓存服务的用户。而本文中，CPDoS 的主要目的是向缓存服务器中存入错误页面，从而使用户无法通过缓存服务器获得受害者网站的合法内容。

作者认为，导致漏洞的根本原因是“两个消息处理组件对 HTTP 报文的解析处理逻辑不一致”，该问题通常被称为“Semantic Gap（语义鸿沟）” [4]。本文即利用了缓存服务器与源站之间的“语义鸿沟”，提出CPDoS攻击。

【用错误页面污染Web缓存】

为了利用缓存服务器与源站的“语义鸿沟”，攻击者可向 HTTP 请求头插入一些恶意头部，并且使其能够通过缓存服务器的安全校验。当缓存服务器收到此类请求时，通常会将头部“忠实地”（不做任何修改地）转发给源站。源站在处理畸形请求时将出现错误，向用户返回错误页面。当错误页面能被缓存服务器接受并缓存时，就产生了安全漏洞。此时若有正常用户通过缓存访问同一资源，将会得到攻击者先前触发的错误页面，影响了受害者服务器的可用性。

可是，缓存服务器真的会缓存错误页面吗？缓存服务器如何判断一个“错误”页面是否应该被缓存呢？作者带着这些问题阅读了大量 RFC，并对十数款 Web 缓存解决方案进行了测试。结果总结如图表 1 所示，其中红色背景表示“本不应该缓存的状态码却被缓存”。

图表 1：RFC 中规定的可缓存的状态码以及主流 Web 缓存解决方案的实现情况

尽管“如何判断 HTTP 响应是否可缓存？”的问题已经在 RFC 中有了明确的定义，但不同的 Web 缓存解决方案的实现还是不尽如人意。例如：CloudFront 会缓存 400、500 等在 RFC 中明确规定“不可缓存”的状态码。

【CPDoS攻击方式】

基于图表 1 的观察总结，作者最终发现了 3 种实现 CPDoS 的攻击思路，分别为 (1)HTTPHeaderOversize (HHO) Attack (2)HTTPMethodOverride (HMO) Attack (3)HTTPMetaCharacter (HMC) Attack。下面将对三种攻击方式进行逐一介绍。

HTTP Header Oversize (HHO) Attack

HTTP 协议标准并未对 HTTP 请求头的大小进行限制，但是，Web 服务器、Web 代理以及其他中间盒子通常会对 HTTP 请求头的大小进行限制。为了缓解“请求头缓冲区溢出攻击”以及 “ReDoS 攻击 [5]”，大部分 Web 服务器（如：Apache HTTPD）和 HTTP 代理服务器都会将其设置为约 8,192 字节。然而，某些中间盒子会将该限制设为大于 8,192字节 （如：Amazon CloudFront CDN 允许请求头最大约为 20,480 字节）。这种对“最大请求头大小”理解不一致的“语义鸿沟”将导致 CPDoS 攻击。

如图表 2 所示，攻击者发起向 http://example.org/index.html 的 GET 请求，并添加一些超长的请求头。该请求可以正常通过缓存服务器并被其转发到源站，但会触发 HTTP 请求大小限制使源站报错。源站服务器通常会向用户返回 400 Bad Request 页面。由于响应码符合 HTTP 协议标准 RFC 7231 中对“可缓存性”的定义，该响应经过缓存服务器时会被缓存。当其他用户通过 GET 方法请求 http://example.org/index.html 时，将会得到先前缓存的错误页面。

图表 2：HTTP Header Oversize (HHO) Attack 示意图

作者对主流的 Web 缓存解决方案在遇到“超长 HTTP 请求”时的处理逻辑进行了测量，结果如图表 3 所示，大部分实现都没有遵循 HTTP 协议标准中规定的“当遇到超大 HTTP 请求头时应返回 431 Request Header Fields Too Large”的规定，而是返回 400 Bad Request。因此，绝大部分解决方案都将受到 HHO 攻击影响，例如：当 IIS 与 CloudFront 的配合部署时易受到 HHO 攻击。

图表 3：多个 HTTP 实现中的 HTTP 请求头大小限制

HTTP Method Override (HMO) Attack

HTTP 协议标准中定义了一系列请求方法，用来向服务器表示要对某个资源进行的操作，例如，GET / POST / DELETE / PUT / PATCH ，这些请求方法被广泛应用于基于 RESTful 的 Web 框架中 。

而实际中，HTTP 请求路径中的某些中间节点（如：代理服务器）可能只支持 GET / POST 请求。为了解决该问题，这些 RESTful 框架通常都支持通过 HTTP 请求头对请求方法进行重写（如：X-HTTP-Method-Override、X-HTTP-Method 等），而原始请求中的请求方法将会被忽略。

如图表 4 所示，当攻击者发起向 http://example.org/index.html 的 GET 请求且添加 X-HTTP-Method-Override 请求头为 POST 时，缓存服务器会将其解析为 GET 请求并“忠实”转发。但源站会根据请求头中的 X-HTTP-Method-Override 头认为该请求实际上是一个 POST 请求，而 index.html 并未实现对 POST 请求的处理逻辑，因此源站服务器通常会向用户返回 404 Not Found 或 405 Method Not Allowed页面。由于响应码符合 HTTP 协议标准 RFC 7231 中对“可缓存性”的定义，该响应经过缓存服务器时将会被缓存。此时，当其他用户通过 GET 方法请求 http://example.org/index.html 时，将会得到先前缓存的错误页面。

图表4：HTTP Method Override (HMO) Attack 示意图

作者对主流的 Web 框架进行了测量，结果如图表 5 所示。其中 Symfony, Laravel 以及 Play 1 都默认支持通过请求头来覆盖请求方法；Django, Express.js 尽管没有默认支持该特性，但都提供了对应的扩展。

图表 5：主流 Web 框架对“HTTP 请求方法覆盖”头部的支持情况

HTTP Meta Character (HMC) Attack

作者还发现可以在 HTTP 请求中添加一些恶意元字符来实现类似的攻击效果。例如，在请求头中特定位置插入回车或换行等元字符。若该恶意请求可以正常通过缓存服务器发送给源站，且触发源站返回可被缓存服务器接收并缓存的异常响应，即可完成攻击。

如图表 6 所示，攻击者在 HTTP 请求中插入一个包含元字符的头部，该头部最终触发了服务器返回 400 Bad Request 异常且响应被缓存服务器缓存，之后正常用户请求时会得到错误页面。

图表 6：HTTP Meta Character (HMC) Attack 示意图

作者对主流 HTTP 实现进行了测试，结果如图表 7 所示。结果表明，大部分系统都会将元字符视作一种威胁，包含这些这些可疑的字符的请求通常会被阻断或净化，但是不同的系统的处理逻辑差别较大。例如：CloudFront 会阻断 \\u0000、净化 \\n \\v \\f \\r，但是会正常转发 \\a \\b，而 Apache HTTPD 在遇到 \\a \\b 时会返回 400 Bad Request 响应。两者配合使用时会导致 HMC 攻击。

图表 7：主流 HTTP 实现对请求头中出现“元字符”的处理逻辑

【攻击有效性及实际影响】

图表8展示了作者所发现的全部攻击向量，即当 Web 系统两两串联协同工作时可能受到的攻击。实验结果表明，使用 CloudFront 的 Web 服务器最易受 CPDoS 攻击影响，因为其默认缓存 400 Bad Request 响应码。

图表 8：CPDoS 攻击向量汇总

为了评估该攻击在现实中的影响，作者选取了 (1) 美国国防部所辖网站 (2) Alexa Top 500 网站 (3) HTTP Archive 三个数据集中的三千多万个网站进行测试。其中 8 个美国国防部所辖网站、23 个 Alexa Top 500 网站以及超过九百万个 HTTP Archive 中的网站部署在 CloudFront CDN 上，若这些网站使用 Apache HTTPD、Nginx、Varnish 等 Web 服务器，则都会受到 CPDoS 攻击影响。由于数据量太大，作者没有对这些网站进行全量测试，而是随机抽样了部分网站进行测试，最终，作者找到了 12 个存在漏洞的资源（包括脚本、样式表、图片甚至一些动态网页内容），其中包含一些关键网站，如以太坊官网 www.ethereum.org，NASA 官网 nasa.gov 以及美国海军陆战队网站 marines.com 等。作者分别对以太坊官网以及美国海军陆战队网站进行了测试，并都成功实施了攻击，结果如图表 9、图表 10 所示。

图表 9：攻击者通过 HHO 攻击逐渐使以太坊官网页面不可用：首先使图片资源不可用，其次使样式表不可用，最后使整个主页不可用

图表 10：攻击者通过 HHO 攻击使美国海军陆战队网站不可用，图为攻击前 a) 后 b) 对比

【结论】

在本文中，作者通过介绍其发现的新型攻击方式 CPDoS，对基于“语义差异”的攻击方式进行了扩展。作者系统梳理了该攻击的条件，即 “构造畸形 HTTP 请求使其在源站侧触发报错，且报错响应页面会被缓存系统接受并缓存”。作者发现了三种满足上述攻击条件的畸形 HTTP 请求构造方式，分别利用了 (1) “HTTP 方法覆盖” 头部 (2) 超长 HTTP 请求头 (3) 元字符解析这三个语义差异缺陷。经过测量，作者发现共有 11% 的美国国防部网站、30%的 Alexa Top 500 网站以及 16% 的 HTTP Archive URL受到该攻击的影响。此外，随着微服务与面向服务的架构Service-OrientedArchitecture (SOA) 的广泛应用，作者认为，未来将会有越来越多的“语义差异”出现，呼吁安全社区与开发者应该尽快对该问题予以重视。

原文链接

https://dl.acm.org/doi/10.1145/3319535.3354215

CPDoS项目官网

https://cpdos.org/

参考文献

[1] Heled, Ronen. "HTTP REQUEST SMUGGLING." (2005).

[2] Chen, Jianjun, et al. "Host of troubles: Multiple host ambiguities in http implementations." Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. 2016.

[3] Klein, Amid. "Divide and conquer." HTTP Response Splitting, Web Cache Poisoning Attacks and Related Topics, Sanctum whitepaper (2004).

[4] Jana, Suman, and Vitaly Shmatikov. "Abusing file processing in malware detectors for fun and profit." 2012 IEEE Symposium on Security and Privacy. IEEE, 2012.

[5] Crosby, Scott. Denial of Service through Regular Expressions. USENIX Association, 2003.

王一航，编辑&审校|张一铭、刘明烜

声明：本文来自NISL实验室，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。