大约一个月前，安全研究人员奥马尔·吉尔（Omer Gil）公布了一次他称之为Web缓存欺骗攻击的攻击细节。它适用于位于反向代理（如Cloudflare）后面并且以特定方式配置错误的站点。不幸的是，此攻击中"配置错误"的定义根据缓存的工作方式而改变。在这篇文章中，我们将解释这种攻击，然后描述我们的缓存用来决定是否缓存给定内容的算法，这样客户就可以确定他们对该攻击是安全的。攻击首先，我们将解释Web缓存欺骗攻击的基本原理。对于那些想要更深入解释的人来说，Omer的原始帖子是一个很好的资源。CC BY-SA 2.0-图片由shelleygibb提供想象一下你在经营社交媒体网站example.com网站，并且每个用户在example.com/newsfeed. 当用户导航到其新闻源时，其浏览器生成的HTTP请求可能如下所示：获取/newsfeed HTTP/1.1主持人：示例.com...如果您使用Cloudflare，您不希望我们缓存此请求，因为如果我们这样做了，您的一些用户可能会开始看到其他用户的新闻源，而不是他们自己的，这将是非常糟糕的。幸运的是，正如我们将在下面解释的那样，这个请求不会被缓存，因为请求中的路径（newsfeed部分）没有"可缓存的文件扩展名"（一个文件扩展名，如.jpg或.css，它指示Cloudflare可以缓存请求）。如果你的网站被配置成可以灵活处理哪种路径，麻烦就开始了。特别是，当对不存在的路径的请求（例如，/x/y/z）被视为对存在的父路径的请求（比如/x）的请求时，就会出现这个问题。例如，如果收到对不存在的路径/newsfeed/foo的请求，会发生什么情况？根据您的网站的配置方式，它可能只将此类请求视为对/newsfeed的请求。例如，如果运行的是Django web框架，下面的配置就可以做到这一点，因为正则表达式^newsfeed/同时匹配newsfeed/和newsfeed/foo（Django路由省略了前导/）：从django.conf.url导入urlpatterns=[url（r'^newsfeed/'，…）]问题就在这里。如果您的网站执行此操作，则向/newsfeed发出请求/食品.jpg将被视为对/newsfeed的请求。但是Cloudflare看到了.jpg文件扩展名，会认为缓存这个请求是可以的。现在，你可能会想，"那又怎样？我的网站从来没有链接到/newsfeed/食品.jpg这是真的，但这并不能阻止其他人试图说服你的用户访问这样的路径。例如，攻击者可以将此消息发送给某人：嘿，看看这个很酷的链接！https://example.com/newsfeed/foo.jpg如果消息的接收者单击链接，他们将被带到他们的新闻源。但是当请求通过Cloudflare时，由于路径以".jpg"结尾，所以我们会缓存它。然后攻击者可以自己访问同一个URL，他们的请求将从我们的缓存中得到服务，从而暴露用户的敏感内容。防御Web缓存欺骗攻击防御此攻击的最佳方法是确保您的网站不具有如此的权限，并且决不会将对不存在路径（例如，/x/y/z）的请求视为对有效父路径（例如，/x）的请求。在上面的示例中，这意味着对/newsfeed/foo或/newsfeed的请求/食品.jpg不会被视为等同于对/newsfeed的请求，而是会导致某种错误或重定向到合法页面。如果我们想从上面修改Django示例，我们可以在正则表达式的末尾添加一个$，以确保只精确匹配（在本例中，对/newsfeed/foo的请求将导致404）：我们提供了许多设置，允许您自定义我们的缓存处理对您网站的请求的方式。例如，如果您为/newsfeed启用了页面规则，并且启用了"缓存所有内容"设置（默认情况下是关闭的），那么我们将把请求缓存到/newsfeed，这可能是错误的。所以要知道缓存是不是我们网站最好的方式来保证缓存的安全。我们的缓存是如何工作的当一个请求进入我们的网络时，我们将执行两个处理阶段，以确定是否缓存源站对该请求的响应：在合格性阶段（在请求首次到达边缘时执行）中，我们检查请求以确定它是否符合缓存条件。如果我们确定它不符合条件，那么我们将不会缓存它。如果我们确定它是合格的，那么我们将进入第二个取消资格阶段。在从原始web服务器接收到响应后执行的取消资格阶段中，我们检查响应以确定是否有任何特征使响应无法被缓存。如果没有什么可以取消它的资格，那么响应将被缓存。_通过页面规则配置缓存_请注意，站点范围的设置或页面规则可能会影响此逻辑。下面，当我们说"应用设置"或"设置是"时，我们的意思是要么存在一个适用于所有请求的全局设置，要么存在一个应用于给定请求的设置的页面规则（例如，/foo/*的页面规则适用于对/foo/bar、/foo/baz、/foo/bar/baz等的请求）。如果页面规则和全局规则都适用于给定的请求，则页面规则会覆盖全局规则。资格阶段在合格性阶段，我们使用来自客户端的请求的特征来确定请求是否符合缓存的条件。如果请求不符合条件，则不会缓存该请求。如果申请符合条件，我们将在取消资格阶段进行更多处理。资格规则如下：如果设置为"标准"、"忽略查询字符串"或"无查询字符串"，则：如果请求的路径以下面图1中列出的某个文件扩展名结尾，则请求有资格被缓存如果请求的路径以下面图2中列出的某个文件扩展名结束，则请求可能有资格被缓存（取决于我们的边缘所做的与性能相关的决定）如果请求路径为/机器人.txt如果设置为"缓存所有内容"，则所有请求都符合缓存条件。除上述规则外，如果以下两个条件之一成立，则到目前为止关于资格的任何决定都将被覆盖，并且请求将没有资格被缓存：如果启用了"缓存到Cookie"设置，并且Cookie标头中不存在配置的Cookie，则请求不符合缓存的条件。如果启用了绕过Cookie缓存设置，并且Cookie标头中存在配置的Cookie，则请求不符合缓存的条件。取消资格阶段在取消资格阶段（只有在请求被标记为合格时才会发生），来自原始web服务器的响应特性可以取消请求的资格。如果请求被取消资格，则不会缓存响应。如果请求没有被取消资格，那么响应将被缓存。取消资格的规则如下：如果设置为"标准"、"忽略查询字符串"或"无查询字符串"，或者设置为"缓存所有内容"且不存在边缘缓存TTL，则：来自源站的响应中的缓存控制标头具有以下任何值，将取消请求的资格，从而导致该请求不被缓存：无缓存最大年龄=0私有的没有商店来自源站的响应中的Expires头将取消请求的资格，从而导致请求不被缓存。如果设置为"缓存所有内容"并且存在边缘缓存TTL，则在任何情况下都不会取消请求资格，并且始终会被缓存。还有一组与set Cookie头相关的规则。以下规则仅适用于存在Set Cookie头的情况：如果设置为"标准"、"忽略查询字符串"或"无查询字符串"，或者如果设置为"缓存所有内容"并且存在边缘缓存TTL，则请求将不会被取消资格，但将从缓存中存储的响应版本中剥离Set Cookie头。如果设置为Cache Everything并且不存在边缘缓存TTL，则请求将被取消资格，并且不会被缓存。Set Cookie头将从发送到发出请求的客户端的响应中剥离。班css罐子js公司jpg公司jpeg格式gif公司ico公司巴布亚新几内亚骨形态发生蛋白皮克特csv公司医生docx公司xls公司xlsx公司ps公司pdf格式请幻灯片演示文件pptx公司畅通节能法蒂芙ttf公司光学传递函数韦伯粗纱织物2svgsvgz公司eot每股收益ejs公司swf公司激流迷笛中间_图1：总是可缓存的文件扩展名_mp3mp4型mp4v英里/加仑mpeg压敏电阻mkv公司flv公司韦伯wmv公司阿维ogg公司m4a型波浪aac公司ogv公司拉链坐焦油7z型rar公司每分钟转数德布dmg公司国际标准化组织图像微星msp公司msm公司箱子可执行文件动态链接库拉mka公司ts公司m4v型asf公司mk3d公司林吉特swf公司_图2：有时可缓存的文件扩展名_所以你有了它。只要你确保遵循上面的建议，并确保你的网站能很好地使用我们的缓存，你就应该能够抵御Web缓存欺骗攻击。