在Black Hat USA 2025和DEF CON 33上，PortSwigger的研究总监James Kettle公布了新的HTTP异步攻击技术，这无疑证明了一件事：HTTP/1.1已经失效，任何仍依赖该协议的组织都处于风险之中。为了解这对企业意味着什么，我们采访了Burp Suite的创始人、PortSwigger的首席执行官、也是开创性的《Web Application Hacker’s Handbook》一书的作者——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必须消亡“运动的原因。这不是要把请求走私仅仅当作另一个漏洞类别来处理。而是要认识到协议本身在现代使用中已经失效，并将移除它视为一个战略优先事项。
谁需要为修复这个问题负责？ 这里有三方。供应商，包括云提供商和CDN，需要使上游连接的HTTP/1.1禁用成为可能且简单。目前，有些供应商并未做到。研究人员需要继续揭露这些问题，既通过新技术，也通过让防御者能够检测这些问题的工具。James的白皮书提出了几个可能的探索方向，他为Burp Suite开发的开源HTTP Request Smuggler扩展为你提供了一个坚实的构建基础。企业需要通过适当的扫描检查自己的环境，准确了解漏洞所在，并在必要时要求其供应商填补这些漏洞。
为什么Burp Suite特别适合检测这个问题？ Burp之所以不同，是因为它实现了自己的HTTP协议栈。这意味着它可以以其他工具无法做到的方式在协议层面操纵请求，而这正是发现请求走私所需要的。
我们还利用James全新的检测方法，在Burp Suite Professional和Burp Suite DAST的手动工具和自动扫描中构建了相应功能，因此组织既可以探索边缘情况，也可以在其环境中运行可重复的测试。没有其他工具能够如此有效地检测请求走私漏洞（如果它们能检测的话）。
领导者如何知道他们的供应商和合作伙伴是否真的在保护他们？ 目前唯一可靠的方法是测试。使用最新版本的Burp Suite和James的HTTP Request Smuggler扩展运行扫描，看看你是否暴露，并使用手动工具来验证发现。对于更大的资产组合，Burp Suite DAST在企业规模下测试异步漏洞方面具有独特的能力。
随着供应商的成熟，基于配置的保证在未来可能变得现实，但我们还没有达到那个阶段。目前，使用最先进的工具进行持续测试是打破假设、看清现实的唯一方法。
这样做对领导层有什么直接价值？ 清晰度。你能对最重要的问题获得快速、具体的答案：我们有漏洞吗？在哪里？有多严重？这使你有能力确定修复的优先级，向你的供应商升级问题，然后重新测试以确认改进。这是一个清晰的反馈循环，能将未知风险转化为可衡量的进展。
对于计划退出HTTP/1.1的CISO们，最重要的一条建议是什么？ 要全面考虑。修复不能是局部的——它必须是无处不在的。你的基础设施中的每个端点、每个环节、每个层面都需要超越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所言：”这不仅仅是你打个补丁就能解决的另一个漏洞。这是一个需要刻意消除的架构缺陷。如果你的技术栈中仍有HTTP/1.1，就假设自己暴露了。"