HTTP/1.1必须淘汰：Dafydd Stuttard谈这对企业安全意味着什么
在Black Hat USA 2025和DEF CON 33上，PortSwigger的研究总监James Kettle揭示了新的HTTP异步（desync）技术，这些技术无疑证明了一点：HTTP/1.1已存在缺陷，任何仍依赖它的组织都面临风险。
为了解这对企业意味着什么，我们采访了Burp Suite的创造者、PortSwigger首席执行官、同时也是开创性著作《Web应用黑客手册》作者的Dafydd Stuttard。他向安全领导者传达的信息很明确：“如果你的技术栈中存在任何HTTP/1.1的跳转，就假定你是脆弱的。”
为什么安全领导者在2025年仍需关心“旧”协议漏洞？
我想说的第一点是，它们根本不是“旧”漏洞；它们依然非常活跃。HTTP/1.1至今仍承载着约一半的互联网流量。协议本身是旧的，是为一个不同的互联网设计的，那个互联网没有预见到今天庞大、分层的现代基础设施。当你将CDN、代理和应用服务器串联在一起时，它们在处理请求方式上的细微分歧就变得不可避免。
对于HTTP/1.1尤其如此，因为它本质上是一个基于文本的协议。因此，与之交互的每个系统都必须独立解析字节流，以识别出独立的HTTP消息和其中编码的任何相关数据。要保持解析的一致性非常具有挑战性，尤其是在如今第三方服务及其关联基础设施如此普遍的世界里。
薄弱环节究竟在哪里？
通常不在人们以为的地方。浏览器与边缘网络之间的连接通常是稳固的：它是加密的，并且广泛支持HTTP/2。真正的危险潜伏在上游：在你的CDN与源服务器之间、你的代理与应用服务器之间，甚至是内部微服务之间的通信中。
如果这些跳转中的任何一个仍在使用HTTP/1.1，你就暴露在风险之下。这就是为什么这并非传统意义上的“bug”。它不是你可以打个补丁就能继续前行的东西。这是一个架构缺陷，唯一真正的修复方法是彻底淘汰HTTP/1.1。
一个令人不安的事实是，许多看似支持HTTP/2+的服务，包括主流CDN，会在内部将客户端发送的HTTP/2流量降级为HTTP/1.1。如果你的基础设施在前端Web服务器上游的任何地方进行了这种降级，你不仅重新打开了异步攻击的大门，事实上还使威胁变得更加严重。
这种降级通常发生在第三方基础设施内部，你可能甚至没有选择禁用它。为什么？因为供应商需要与仍被其大量客户使用的遗留系统保持向后兼容。我认为James在他的研究论文中说得最好，他指出“采用基于云代理的一个被忽视的危险是，你实际上是将另一家公司的技术债纳入了你自己的安全态势中”。
是什么让这对大型组织尤其危险？
对企业而言，挑战在于规模和复杂性。你不仅仅是运行一个Web应用，而是在协调一整个生态系统：多个CDN、分层的反向代理、服务网格、微服务、API，这些通常来自一系列不同的供应商。这种复杂性是滋生难以发现的协议级别问题的沃土，这些问题往往对你的安全具有关键性影响。
在一个大型组织中，一次成功的异步攻击不仅仅关乎劫持一个用户会话。它关乎大规模暴露——凭证泄露、数据被盗、恶意内容被注入，整个平台的信任遭到破坏。对攻击者而言，这是金矿。对你而言，这是系统性的业务风险。
为了让大家有个概念，James和他的合作者在今年的研究中，在成功入侵了几家主要CDN的几乎所有客户（总计约3000万个网站）后，获得了超过35万美元的漏洞赏金。这仅仅凸显了这些问题的严重性和持久性，尽管经过了多年所谓的加固。
如果组织不采取行动，真正的商业风险是什么？
风险在于攻击者可能获得整个站点的控制权。通过HTTP异步（又称请求走私）攻击，攻击者可以操纵服务器处理流量的方式，从而导致一系列严重后果：窃取活动会话、拦截属于其他用户的敏感响应，或者注入影响大规模用户的恶意代码。
这是一种不仅会打击你的安全态势，还会打击客户信任、合规义务，并最终损害你企业声誉的漏洞。
你认为大多数组织是否低估了这个问题？
几乎可以肯定。尽管具有相似的潜在影响，但请求走私在历史上并没有像SQL注入或跨站脚本那样受到同等程度的关注。而且由于问题通常源于企业外部由供应商管理的基础设施，领导者很容易忽视它。人们常常假设，来自领先供应商的标准、广泛使用的技术默认是安全的。
但James的最新研究表明，这种假设是危险的。即使云提供商宣传支持HTTP/2，许多也会在内部悄悄降级到HTTP/1.1。这意味着漏洞可能在你认为安全的地方重新出现。
如果HTTP/1.1在上游连接中持续存在会怎样？
那么循环将继续：补丁、绕过、再发现。历史表明，临时的缓解措施无法解决根本缺陷。攻击者会简单地适应并绕过它们。只要HTTP/1.1仍在发挥作用，问题就不会消失。
这就是我们发起“HTTP/1.1必须淘汰”运动的原因。这不仅仅是把请求走私当作另一类bug来处理。这是要认识到协议本身已不适用于现代用途，并将其移除视为一项战略优先事项。
谁需要负责修复这个问题？
这里涉及三方面。供应商，包括云提供商和CDN，需要让禁用每个上游连接的HTTP/1.1成为可能且简单明了。目前，有些并没有这样做。研究人员需要继续用新技术和让防御者能够检测这些问题的工具来揭示这些问题。James的白皮书提出了几个潜在的探索方向，他为Burp Suite开发的开源HTTP请求走私扩展为你提供了一个坚实的构建基础。企业需要通过适当的扫描检查自己的环境，准确了解漏洞所在，并在必要时督促其供应商修复它们。
为什么Burp Suite特别适合检测这个问题？
Burp之所以不同，是因为它实现了自己的HTTP协议栈。这意味着它可以在协议层面以其他工具无法做到的方式操纵请求，而这正是发现请求走私所需要的。
我们还利用James全新的检测方法，在Burp Suite Professional和Burp Suite DAST的手动工具和自动化扫描中构建了相应功能，因此组织既可以探索边缘情况，也可以在其环境中运行可重复的测试。没有其他工具能够如此有效地检测请求走私漏洞。
领导者如何知道他们的供应商和合作伙伴是否真的在保护他们？
目前唯一可靠的方法是测试。使用最新版的Burp Suite和James的HTTP请求走私扩展运行扫描，看看你是否暴露，并使用手动工具验证发现。对于更大的资产组合，Burp Suite DAST在检测企业规模的异步漏洞方面具有独特能力。
基于配置的保证在未来随着供应商的成熟可能变得现实，但我们还没到那一步。目前，使用最先进的工具进行持续测试是打破假设、看清现实的唯一方法。
这样做对领导层最直接的价值是什么？
清晰度。你能快速、具体地回答最重要的问题：我们脆弱吗？在哪里？有多严重？这让你有能力确定修复的优先级，向供应商升级问题，然后重新测试以确认改进。这是一个清晰的反馈循环，能将问题从未知风险转化为可衡量的进展。
对于计划淘汰HTTP/1.1的首席信息安全官，最重要的建议是什么？
思考端到端。修复不是部分的——它必须是普遍的。你基础设施中的每个端点、每次跳转、每个层面都需要超越HTTP/1.1。
并且要认识到，你当前大多数应用安全工具——SAST、SCA、传统DAST——甚至都没有找对地方。这是一个传输层缺陷。你需要能够在该层面进行探测的工具和流程，并且需要组织意愿来确保HTTP/1.1在你的资产中真正被淘汰。
安全领导者现在应该做什么
- 映射你的现实：清点每个上游连接——CDN到源站、代理到应用、服务到服务——并确定哪里仍在使用HTTP/1.1。
- 制定无HTTP/1.1策略：要求在所有地方使用HTTP/2或更高版本，并督促供应商提供支持。
- 像攻击者一样测试：使用Burp Suite扫描你的应用，并在协议层面验证暴露情况。使用Burp Suite DAST大规模扫描你的资产组合，并在Burp Suite Professional中验证结果。
- 将其制度化：将检查纳入架构审查、新系统上线流程和供应商评估中，防止HTTP/1.1卷土重来。
结束语
正如Dafydd所言：“这不仅仅是你可以修补的另一个bug。这是一个需要有意消除的架构缺陷。如果你的技术栈中仍有HTTP/1.1，就假定你已暴露。”