文章来源：EDI安全

当缓存被攻击者诱骗向请求资源的其他所有用户提供更改后的响应时，就会出现缓存中毒漏洞。这是缓存中毒拒绝服务攻击的样子：

当缓存被攻击者诱骗向请求资源的其他所有用户提供更改后的响应时，就会出现缓存中毒漏洞。这是缓存中毒拒绝服务攻击的样子：

我在Cache Poisoning DoS上找到了它assets.redacted.com，该子域托管着一个私有程序中使用的每个js＆css文件。该漏洞是由Fastify的Accept-Version标头引起的，该标头允许客户端描述要发送回的资源版本。我能像这样使用该功能：

  由于高速缓存密钥中不包含Accept-version标头，因此任何请求js文件的用户都将收到高速缓存的404响应。这获得了2000美元的奖励，因为fastify无法禁用该Accept-Version标头，因此还分配了CVE-2020-7764。

  但是，在测试了更多主机之后，越来越明显的是，我无法使用该技术找到其他易受攻击的目标。我决定对其他可能的缓存中毒DoS小工具进行其他研究。

我读过的很多研究都讨论了非密钥输入（例如上面的示例标头）如何导致DoS，但他们大多忽略了诸如主机头或路径之类的密钥输入。我能够提出以下两个新的攻击，并成功地在漏洞赏金计划中重现了它们。

根据RFC 4343的规定，FQDN（完全合格的域名）应始终不区分大小写，但是由于某些原因，框架并不总是遵循此原则。由于主机值应该不区分大小写，因此一些开发人员认为将主机头值引入到cachekey中时可以安全地将其转换为小写字母，而无需更改发送给后端服务器的实际请求。

将这两种行为配对时，我能使用自定义配置的Varnish作为缓存解决方案在主机上实现以下DoS攻击。

大写的主机头值会导致404错误，Varnish会使用缓存键中主机头的规范化值将其缓存。

该程序告诉我，他们的payload平衡器（HAProxy）是提供大写头时响应404错误的程序。

除了主机头之外，在注入高速缓存键之前，参数和路径也可以是小写的，因此始终值得检查高速缓存。

在使用缓存标识子域时，我发现了一个特定的子域托管用于构建地图的图像。请求图像看起来像这样：

GET /maps/1.0.5/map/4/151/16.png  Host: maps.redacted.com

就像以前一样，Param Miner无法找到任何隐藏的标头，所以我决定更深入地研究。据我所知，路径中的最后三个数字是范围，用于告诉服务器应返回映射的哪一部分。

最初，我以为1.0.5只是版本，所以我并没有给予太多关注，但是，当我尝试使用时1.0.4，我发现我得到了一个缓存HIT。我认为其他一些API可能正在使用旧版本，因此我测试了1.0.0，它还返回了缓存HIT。我花了很长时间才意识到我要替换的目录1.0.5正在返回200 OK和一个X-Cache Hitrepsonse标头。我提出了以下DoS POC：

在尝试提高缓存命中率时，开发人员没有考虑潜在的DoS攻击，这使我可以注入%2e%2e（URL编码..）并将请求重定向到/map/4/77/16.png服务器上不存在的，因此导致404这是经过分类的，并且团队正在研究解决方法。

当寻找缓存中毒的DoS漏洞时，通过标准化uri的部分来确定缓存是否正在运行旨在提高命中率的自定义配置很简单。我还没有研究过在路径/参数上实现小写规范化的频率，因此关于uri规范化和缓存可能还有更多的余地。