HTTP/3连接污染会成为下一个威胁么？

声明：文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由用户承担全部法律及连带责任，文章作者不承担任何法律及连带责任。

正文

我最近记录了称为第一个请求路由的危险反向代理行为(见参考1),这种行为可以对后端系统进行主机头攻击,在这篇文章中，我将展示第一次请求路由是如何启用基于浏览器的客户端攻击，这里我称之为 HTTP 连接污染.

这种技术适用于运行 HTTP/2 的系统，并且随着 HTTP/3 的出现可能会成为更大的威胁。

Web浏览器有一个叫做HTTP连接合并(见2)的特性，它允许它们重用一个HTTP/2+连接，用于访问不同网站的请求，前提是站点解析到相同的IP地址，并使用对这两个主机名都有效的TLS证书。

第一个请求路由是一种危险的反向代理行为，其中代理分析出连接上的第一个请求，以确定将其路由到哪个后端，然后将该连接上的所有后续请求发送到同一后端。

连接合并和首次请求路由可能不能很好地一起使用。例如，假设secure.example.com和wordpress.example.com都位于反向代理的后面，使用的是*.example.com的有效证书:

$ nslookup wordpress.example.com
52.16.179.7 // reverse proxy that supports HTTP/2 and does first-request routing

$ nslookup secure.example.com
52.16.179.7  // same reverse proxy

$ openssl s_client -connect x.portswigger-labs.net:443
subject=/CN=*.example.com // wildcard TLS certificate

如果浏览器试图将一个请求发送到wordpress.example.com和secure.example.com,那么浏览器连接合并将迫使这两个请求通过一个连接连接到前端

第一个请求路由将导致对secure.example.com的请求被错误地路由到WordPress后端。这意味着如果您在wordpress.example.com上找到XSS，您可以使用它来破坏secure.example.com!

// create HTTP/2+ connection
fetch('https://wordpress.example.com/', {credentials: 'include'}) 

// connection coalescing will force this down the same connection...
// ...leading to the front-end misrouting it to WordPress 
// the browser thinks our injected JS is coming from secure.example.com
// exposing saved passwords, cookies, etc.
location='https://secure.example.com/plugin/x?q=<script>stealPasswords()'

你可以使用Chrome的开发者工具中的网络选项卡下的时间图来探索连接合并(你也可以使用WireShark)。使用fetch()发出请求对，并查看图中是否显示了第二个请求在“初始连接”上花费的时间，以及connection ID列是否匹配:

fetch('//sub1.hackxor.net/', {mode: 'no-cors', credentials: 'include'}).then(()=>{ fetch('//sub2.hackxor.net/', {mode: 'no-cors', credentials: 'include'}) })

我没有投入足够的时间去深入探索这种威胁，因为我认为它目前很罕见，有两个原因。首先，第一个请求路由相对不常见，而且相对于HTTP/1.1，HTTP/2的实现相对复杂, HTTP/2服务器的数量很少。其次，连接合并意味着执行第一个请求路由的HTTP/2服务器可能会间歇性地中断真正的访问者，因此所有者最终可能会在没有攻击者鼓励的情况下去修复漏洞。

话虽如此，对攻击者来说也不全是坏消息。HTTP/3提议取消IP地址匹配的要求，这将使每个人都拥有一个使用第一请求路由的前端，并拥有对多台主机有效的证书。

这也产生了第二个与第一次请求路由无关的风险——这意味着一个带有通配符证书的受损害服务器不再需要MITM来利用。实际上，这大大增加了恶意行为的概率。

为了在这些风险成为现实之前避免它们，请确保反向代理不执行第一个请求路由。您可以在Repeater中通过启用HTTP/1和HTTP/2连接重用手动测试它，也可以在HTTP请求走私器中使用“连接状态”攻击扫描它。

另外，要注意的是，虽然通配符TLS证书从来都不是理想的，但HTTP/3意味着一个有通配符证书的受损服务器现在可以被用来攻击兄弟域，而不需要主动的MITM。