HTTP/1.1必须消亡：反同步攻击的终极博弈

摘要

上游HTTP/1.1协议存在固有安全缺陷，定期使数百万网站面临恶意接管风险。六年的缓解尝试只是掩盖问题而非真正解决。本文介绍多类新型HTTP反同步攻击技术，能够大规模窃取用户凭证。通过详细案例分析（包括Akamai、Cloudflare和Netlify核心基础设施的关键漏洞），展示这些技术如何暴露数千万网站风险。同时发布开源工具包，可系统检测解析器差异和目标弱点。该工具包与技术在两周内产生超过20万美元漏洞赏金。最终论证HTTP请求走私必须被认定为协议根本缺陷。过去六年证明修补单个实现无法消除此威胁。尽管发现已报告并修补，网站仍默默面临未来变种攻击风险。这些都源于HTTP/1.1的致命缺陷——微小实现错误常触发严重安全后果。HTTP/2+可解决此威胁。若要安全网络，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/2消息比端到端使用HTTP/1.1更危险，因其引入第四种指定消息长度的方式。

0.CL反同步攻击

0.CL死锁

0.CL反同步攻击被广泛认为不可利用。考虑将以下攻击发送至具有H-V解析器差异的目标时的情况：

前端看不到Content-Length头，因此将橙色负载视为第二个请求的开始
后端看到Content-Length头，因此等待主体到达
最终服务器超时并重置连接，破坏攻击

打破0.CL死锁

逃脱0.CL死锁的关键是找到早期响应小工具：使后端服务器无需等待主体到达即可响应请求的方法。在nginx上很简单，但在IIS上需利用Windows保留文件名（如/con）触发异常实现早期响应。

基于Expect的反同步攻击

Expect复杂性炸弹

Expect头是将单个HTTP请求发送拆分为两部分的古老优化。客户端发送包含Expect: 100-continue的头部块，服务器评估请求是否会被接受。若服务器响应HTTP/1.1 100 Continue，客户端被允许发送请求主体。这对客户端和服务器都很复杂，对反向代理更糟糕。

绕过响应头移除

所有HTTP/1.1响应都有一个头部块——除非发送Expect。因此第二个头部块常使解析器意外，并破坏前端服务器移除敏感响应头的尝试。此技术还揭示数百个试图掩藏以缓解定向攻击的服务器/版本标识。

防御HTTP反同步攻击

为何修补HTTP/1.1不足够

所有攻击都利用实现缺陷，但根本原因相同。HTTP/1.1的致命缺陷——弱请求分离——意味着微小错误常有关键影响。结合两个关键因素：

HTTP/1.1仅在不代理时简单。RFC包含众多陷阱
过去六年证明我们难以应用真正解决威胁的修补和强化

HTTP/2相比HTTP/1的安全性

上游HTTP/2+使反同步漏洞可能性大幅降低。因为HTTP/2是二进制协议，对每条消息长度零歧义。可预期实现错误，但给定错误实际可被利用的概率显著更低。

如何用HTTP/2击败请求走私

确保源服务器支持HTTP/2
在代理上切换上游HTTP/2
注意禁用浏览器与前端间HTTP/1非必需，只需确保上游转换为HTTP/2

结论

过去六年我们看到HTTP/1.1的设计缺陷定期使网站面临关键攻击。修补单个实现的尝试未能跟上威胁步伐，唯一可行长期解决方案是上游HTTP/2。这非快速修复，但通过传播上游HTTP/1.1危险性的认知，我们能帮助终结HTTP/1.1。