HTTP/1.1必须消亡：反同步攻击的终局之战

摘要

上游HTTP/1.1本质上不安全，经常使数百万网站面临恶意接管风险。六年的缓解尝试掩盖了问题，但未能修复它。

本文介绍了几个新型HTTP反同步攻击类别，能够大规模泄露用户凭证。这些技术通过详细的案例研究进行演示，包括通过颠覆Akamai、Cloudflare和Netlify核心基础设施暴露数千万网站的关键漏洞。

我还介绍了一个开源工具包，能够系统检测解析器差异和特定目标的弱点。该工具包与这些技术结合，在两周内产生了超过20万美元的漏洞赏金。

最终，我认为HTTP请求走私必须被认定为基本协议缺陷。过去六年证明，解决个别实现问题永远不会消除这种威胁。尽管我的发现已被报告和修补，但网站仍然默默面临未来变种的威胁。这些都源于HTTP/1.1中的一个致命缺陷，意味着微小的实现错误经常触发严重的安全后果。HTTP/2+解决了这个威胁。如果我们想要安全的网络，HTTP/1.1必须消亡。

反同步终局：HTTP/1.1的致命缺陷
掩盖但不修复的缓解措施
意外入侵2000万个网站
“HTTP/1很简单"和其他谎言
赢得反同步终局的策略
检测解析器差异
理解V-H和H-V差异
将V-H差异转化为CL.0反同步
在ALB后利用IIS的H-V差异
无Transfer-Encoding的H-V利用
0.CL反同步攻击
0.CL死锁
超越400错误请求
通过双反同步将0.CL转换为CL.0
更多反同步攻击即将到来
基于Expect的反同步攻击
绕过响应头移除
通过标准Expect的0.CL反同步 - T-Mobile
通过混淆Expect的0.CL反同步 - Gitlab
通过标准Expect的CL.0反同步 - Netlify CDN
通过混淆Expect的CL.0反同步 - Akamai CDN
防御HTTP反同步攻击
为什么修补HTTP/1.1不够
HTTP/2相比HTTP/1的安全性
如何在HTTP/1.1中生存
如何帮助消灭HTTP/1.1
结论

反同步终局

HTTP/1.1的致命缺陷

HTTP/1.1有一个致命、高度可利用的缺陷 - 各个HTTP请求之间的边界非常脆弱。请求只是在底层TCP/TLS套接字上简单连接，没有分隔符，并且有多种方式指定其长度。这意味着攻击者可以创建一个请求结束和下一个请求开始的极端歧义。

主要网站通常使用反向代理，将不同用户的请求通过共享连接池传输到后端服务器。这意味着攻击者如果在服务器链中找到最小的解析器差异，就可以导致反同步，将恶意前缀应用到其他用户的请求，通常实现完整的站点接管。

掩盖但不修复的缓解措施

在2025年，HTTP/1.1无处不在 - 但不一定显而易见。服务器和CDN通常声称支持HTTP/2，但实际上将传入的HTTP/2请求降级为HTTP/1.1传输到后端系统，从而失去大部分安全优势。

HTTP/1.1乍看安全，因为如果应用原始请求走私方法学和工具包，很难引起反同步。但为什么呢？让我们看看使用轻度混淆Transfer-Encoding头的经典CL.TE攻击。

意外入侵2000万个网站

HTTP/1.1根本不适应我们通过添加另一层来解决每个问题的世界。以下案例研究完美说明了这一点。

Wannes Verwimp发现影响托管在Heroku上、位于Cloudflare后面的站点的问题。他发现了H2.0反同步，并能够利用它将来访者重定向到自己的网站。

通过忽略攻击被缓存阻止的事实，Wannes发现了Cloudflare基础设施内部的HTTP/1.1反同步：这一发现暴露了超过24,000,000个网站面临完整站点接管风险！

“HTTP/1很简单"和其他谎言

这样的错误是如何发生的？部分原因是涉及系统的纯粹复杂性。然而，根本问题是基础。

存在广泛、危险的误解，认为HTTP/1.1是适合构建任何系统的稳健基础。特别是，未实现反向代理的人经常认为HTTP/1.1简单，因此安全。当你尝试代理HTTP/1.1时，它变得不那么简单。

赢得反同步终局的策略

检测解析器差异

在反同步终局中，由于缓解措施、复杂性和怪癖，检测漏洞很困难。为了在这种环境中蓬勃发展，我们需要一个检测策略，可靠识别使反同步攻击成为可能的根本缺陷。

理解V-H和H-V差异

让我们看看真实检测以及如何解释它：

HTTP Request Smuggler检测到发送部分隐藏的Host头会导致独特响应，无法通过发送正常Host头、完全省略头或发送任意掩码头来触发。这是目标使用的服务器链中存在解析器差异的有力证据。

将V-H差异转化为CL.0反同步

给定V-H差异，你可以尝试通过从后端隐藏Transfer-Encoding头来进行TE.CL利用，或通过隐藏Content-Length头尝试CL.0利用。我强烈建议尽可能使用CL.0，因为它被WAF阻止的可能性小得多。

0.CL反同步攻击

0.CL死锁

0.CL反同步攻击被广泛认为是不可利用的。要理解原因，考虑当你将以下攻击发送到具有H-V解析器差异的目标时会发生什么。

前端看不到Content-Length头，因此它将橙色负载视为第二个请求的开始。这意味着它缓冲橙色负载，只将头块转发到后端。

后端确实看到Content-Length头，因此它将等待主体到达。同时，前端将等待后端回复。最终，其中一个服务器将超时并重置连接，中断攻击。本质上，0.CL反同步攻击通常导致上游连接死锁。

打破0.CL死锁

在此研究之前，我花了两年时间探索竞争条件和定时攻击。在这个过程中，我偶然发现了0.CL死锁的解决方案。

逃离0.CL死锁的关键是找到早期响应小工具：使后端服务器响应请求而不等待主体到达的方法。

基于Expect的反同步攻击

Expect复杂性炸弹

Expect头是一个古老的优化，将发送单个HTTP请求拆分为两部分过程。客户端发送包含Expect: 100-continue的头块，服务器评估请求是否会被接受。如果服务器响应HTTP/1.1 100 Continue，客户端被允许发送请求主体。

这对客户端和服务器都很复杂，对反向代理更糟。

绕过响应头移除

所有HTTP/1.1响应都有一个头块 - 除非你发送Expect。因此，第二个头块经常让解析器措手不及，并打破前端服务器移除敏感响应头的尝试。

防御HTTP反同步攻击

为什么修补HTTP/1.1不够

本文中的所有攻击都在利用实现缺陷，因此结论是放弃整个协议可能显得奇怪。然而，所有这些攻击都有相同的根本原因。HTTP/1.1的致命缺陷 - 请求分离差 - 意味着微小错误经常产生关键影响。

HTTP/2相比HTTP/1的安全性如何？

HTTP/2并不完美 - 它比HTTP/1复杂得多，实现可能很痛苦。然而，上游HTTP/2+使反同步漏洞可能性大大降低。这是因为HTTP/2是二进制协议，就像TCP和TLS一样，对每条消息的长度零歧义。

如何在HTTP/1.1中生存

如果你目前被困在上游HTTP/1.1，可以使用一些策略帮助你的网站在能够开始使用HTTP/2之前，在不可避免的未来反同步攻击轮次中生存。

结论

过去六年我们看到，HTTP/1.1中的设计缺陷经常使网站面临关键攻击。热修复个别实现的尝试未能跟上威胁步伐，唯一可行的长期解决方案是上游HTTP/2。这不是快速修复，但通过传播上游HTTP/1.1真正危险性的认识，我们可以帮助消灭HTTP/1.1。

祝你好运！

James Kettle