Web缓存投毒实战（三）

　　路由投毒

　　有些应用程序不仅愚蠢地使用协议头生成URL，而且无知地将它们用于内部的请求路由：

　　

　　Goodhire显然托管在HubSpot上，而HubSpot给予X-Forwarded-Server比主机优先级高的请求头，并使请求的目标客户端感到困惑。虽然我们的输入反映在页面中，但它是HTML编码的，所以直接的XSS攻击在这里不起作用。要利用这一点，我们需要转到hubspot，将自己注册为HubSpot客户端，在HubSpot页面上放置一个有效Payload，然后欺骗HubSpot在goodhire上发送此响应：

　　

　　Cloudflare愉快地缓存了此响应，并将其提供给后续访问者。在将此报告传递给HubSpot后，HubSpot通过永久封禁我的IP地址来解决这个问题。经过一番劝说，他们最终修补了漏洞。

　　像这样的内部错误路由漏洞在SaaS应用程序中特别常见，在这些应用程序中，单个系统处理针对许多不同客户的请求。

　　隐蔽的路由投毒

　　路由投毒漏洞并不总是那么明显：

　　

　　Cloudflare的博客由Ghost托管，显然他们正在使用X-Forwarded-Host协议头。您可以通过指定另一个可识别的主机名（例如blog.binary）来避免重定向“失败”，但这只会导致奇怪的10秒延迟，然后是标准的blog.cloudflare响应。乍一看，并没有明确的方法来利用这一点。

　　当用户首次使用Ghost注册博客时，它会在ghost.io下使用唯一的子域发布它们。一旦博客启动并运行，用户就可以定义像blog.cloudflare这样的任意自定义域。如果用户定义了自定义域，则其ghost.io子域将只重定向到它：

　　

　　至关重要的是，也可以使用X-Forwarded-Host协议头触发此重定向：

　　

　　通过注册我的ghost帐户并设置自定义域名，我可以将发送到blog.cloudflare的请求重定向到我自己的网站：waf.party。这意味着我可以劫持类似图像资源的加载：

　　

　　重定向JavaScript加载以获得对blog.cloudflare的完全控制的逻辑步骤被一个问题阻挠 - 如果你仔细观察重定向，你会看到它使用HTTP但博客是通过HTTPS加载的。这意味着浏览器的混合内容保护启动并阻止script/stylesheet重定向。

　　我找不到任何技术方法让Ghost发出HTTPS重定向，因此很想放弃我的顾虑并向Ghost报告使用HTTP而不是HTTPS作为漏洞的，希望他们能为我修复它。最终，我决定通过将问题放上hackxor并附上现金奖励来众筹解决方案。第一个解决方案是Sajjad Hashemian发现的，他发现在Safari中如果waf.party在浏览器的HSTS缓存中，重定向将自动升级到HTTPS而不是被阻止。根据Manuel Caballero的工作，Sam Thomas跟进了Edge的解决方案- 发布302重定向到HTTPS URL，完全绕过了Edge的混合内容保护。

　　总而言之，对于Safari和Edge用户，我可以完全控制blog.cloudflare，blog.binary和其他所有ghost客户端上的每个页面。对于Chrome/Firefox用户，我只能劫持图像。虽然我使用Cloudflare作为上面的截图，因为这是第三方系统中的一个问题，我选择通过Binary报告它，因为他们的bug赏金计划支付现金，不像Cloudflare。

　　串联使用非缓存键输入

　　有时，非缓存键输入只会混淆应用程序堆栈的一部分，并且您需要串联其他非缓存键输入以实现可利用的结果。以以下网站为例：

　　

　　X-Forwarded-Host协议头覆盖到cookie上的域，但在响应的其余部分中没有生成任何URL。这本身就没用了。但是，还有另一个非缓存键输入：

　　

　　此输入本身也是无用的，但如果我们将两者结合在一起，我们可以将响应转换为重定向到任意网址：

　　

　　使用此技术，可以通过从自定义HTTP请求头中重定向POST请求来窃取CSRF token。我还可以植入存储型DOM的XSS，其中包含对JSON加载的恶意响应，类似于前面提到的data.gov漏洞。