几天前，Cloudflare和世界其他地区一起，得知了一起"实际的"缓存中毒攻击。在这篇文章中，我将详细介绍这次攻击，并解释Cloudflare是如何为我们的客户减轻攻击的。尽管任何web缓存都容易受到此攻击，但Cloudflare能够采取主动措施保护数百万客户。除了我们已经采取的步骤外，我们强烈建议客户更新他们的原始web服务器以减轻漏洞。一些流行的供应商已经应用了可以立即安装的补丁，包括Drupal、Symfony和Zend。共享web缓存的工作原理假设用户请求一个可缓存的文件，索引.html. 我们首先检查它是否在缓存中，如果不在缓存中，我们从源代码获取并存储它。后续用户可以从我们的缓存中请求该文件，直到它过期或被逐出。尽管响应的内容在请求之间可能略有不同，但客户可能希望缓存文件的单个版本以提高性能：（有关如何使用Cloudflare缓存HTML的更多信息，请参阅此支持页。）我们怎么知道是同一个文件？我们创建一个名为"缓存键"的东西，它包含几个字段，例如：HTTP方案HTTP主机路径查询字符串…一般来说，如果URL匹配，并且我们的客户告诉我们一个文件是可缓存的，我们将把缓存的文件提供给后续用户。缓存中毒攻击的工作原理在缓存中毒攻击中，恶意用户编写一个HTTP请求，诱使源代码生成索引.html使用与无害请求相同的缓存键。此文件可能会被缓存并提供给其他用户：我们非常重视此漏洞，因为没有权限的攻击者可能会将任意数据或资源注入客户网站。那么，如何诱使一个来源产生意想不到的输出呢？事实证明，某些源从HTTP报头发回的数据不是缓存键的一部分。举一个例子，我们可以观察原始行为，如：因为这些数据是从原始数据源返回的，未经转义，所以可能会以可怕的方式使用：游戏结束-攻击者现在可以在这个网页上执行任意的JavaScript。通知有风险的客户一旦我们了解到这个新的漏洞，我们就想看看我们的客户是否有漏洞。我们扫描了所有的企业客户网站，并检查它们是否有风险数据。我们立即通知这些客户该漏洞，并建议他们更新其来源。阻止最坏的罪犯下一步是阻止HTTP头中包含明显恶意内容（如JavaScript）的所有请求。例如，包含可疑字符的标头，如。我们能够立即为所有使用我们WAF的客户部署这些更改。但我们还没说完。更微妙的攻击下载其他版本的客户端可能会对我们造成有害的后果。许多在到达Cloudflare之前通过另一个代理传递的请求都包含X-Forwarded-Host头。一些来源可能依赖于这个值来服务于网页。例如：在本例中，无法仅阻止具有此X-Forwarded-Host头的请求，因为它可能有一个有效的用途。但是，我们需要确保不会将此内容返回给任何未请求它的用户！我们有几种方法可以抵御这种攻击。一个显而易见的第一个答案就是禁用缓存。不过，这并不是一个很好的解决方案，因为禁用缓存将导致客户源服务器上的大量通信量，这将破坏使用Cloudflare的目的。另一个选择是始终在缓存键中包含每个HTTP头及其值。但是，有许多头文件和许多不同的无害值（例如用户代理）。如果我们总是将它们包含在默认的缓存键中，性能就会下降，因为不同的用户请求相同的内容会得到不同的副本，而此时它们都可以有效地得到一个副本。解决方案：在缓存键中包含"有趣"的头值相反，我们决定只在我们认为可能会影响原始响应的情况下更改请求的缓存密钥。我们的默认缓存键有一堆新值：HTTP方案HTTP主机路径查询字符串X-Forwarded-Host标头X主机标头X-Forwarded-Scheme标头…为了防止不必要的缓存分片，我们只在这些头值与URL或主机头中的值不同时才包含它们。例如，如果HTTP主机是网站，而X-Forwarded-Host也是网站，我们不会将X-Forwarded-Host头添加到缓存键。当然，应用程序不从任何其他头发送回数据仍然至关重要！此更改的一个副作用是，使用这些头并依赖于按URL清除的客户可能需要在其purgeapi调用中指定更多的头。您可以在本支持页面中阅读更多详细信息。结论Cloudflare致力于保护我们的客户。如果您发现您的帐户有任何异常，或有更多问题，请联系Cloudflare支持人员。