您可能认为，自首次公开发现近21年后，HTTP请求走私即使在最过时的后端服务器和代理上也几乎无法利用。遗憾的是，尽管行业已尽力，但反同步响应队列并控制整个应用程序的日子远未结束。随着《HTTP/1.1必须消亡：反同步终局》的发布，PortSwigger研究向世界揭示了真相：HTTP/1.1本质上不安全，因此必须消亡。

为了启动反同步终局并提供证据，James Kettle和一个漏洞赏金猎人与研究人员团队通过引入两种新的反同步漏洞类别，成功入侵了3个主要CDN，获得了超过35万美元的奖金。

尽管这些新技术取得了巨大成功，但论文中分享的技术影响才刚刚开始。《HTTP/1.1必须消亡》不仅向行业展示了HTTP请求走私仍然是一个普遍且关键的问题，更重要的是，它呼吁我们所有人加入反同步终局。

无论您是反同步漏洞的新手、经验丰富的渗透测试专业人士，还是希望利用这一史上最大关键奖金机会的漏洞赏金猎人，以下内容将为您提供加入摧毁HTTP/1.1所需的一切。

HTTP/1.1必须消亡：回顾

今年我有幸在PortSwigger的帮助下前往DEF CON现场观看演讲，与研究团队交流，并尽可能多地吸收信息以撰写本文。

该研究涵盖了两个新的反同步漏洞类别，再次凸显了实现HTTP/1.1的复杂性及其致命缺陷：识别单个请求之间边界的挑战。我认为，将这一"挑战"本身视为漏洞，是理解HTTP/1.1必须消亡所需的最大心态转变。

虽然历史上我们专注于修补中间组件之间的解析器差异，但过去9年的研究应该告诉我们，这种方法彻底失败了。通过摒弃现成的漏洞探测，并识别出一种新的扫描技术（已集成到最新版本的HTTP Request Smuggler中），专注于检测HTTP头部的不一致解析，James揭示了大量的反同步线索，只需少量手动工作，通常就能完全攻陷任何在上游某处实现HTTP/1.1的目标。

与往常一样，所有工具和技术均已开源发布，允许社区获取这些新方法并开始寻找关键的反同步漏洞。

简而言之，该研究呈现得极其出色、强大，且一如既往地令人震惊。

快速掌握最新研究

许多漏洞赏金猎人深知，尽快跟进最新研究至关重要——如果您想获得最高奖金的话。对于新手的测试人员和猎人来说，这可能有些令人生畏，这是有充分理由的。HTTP请求走私存在已久，完全理解该主题已成为一项重大挑战，尤其是对新手的测试人员和漏洞赏金猎人而言。在开始挖掘之前，让我们列出您需要快速掌握的資源。

1. 掌握HTTP/1.1

HTTP/1.1本身是一个庞大的主题。然而，PortSwigger研究团队的Martin在其演讲《冲浪流中：野外高级HTTP反同步利用》中对其进行了精彩总结（特别关注反同步漏洞）。遗憾的是，我想这篇演讲的录像在本文发布时不会发布。作为替代，我建议您查看James的论文《HTTP反同步攻击：请求走私重生》中的"核心概念"部分。首先消化这些内容，它们将让您熟悉关键概念"请求是个谎言"。换句话说，最好将HTTP/1.1视为字节流，而不是单个"请求"。

2. 是反同步还是流水线？

一旦开始尝试连接复用，您很快就会遇到看起来非常像反同步漏洞的流水线情况。这太常见了，而且非常令人沮丧。现在就掌握这个主题。如果您没有这些知识就投身反同步终局，您将会遇到困难。阅读《如何区分HTTP流水线与请求走私》以了解所需的一切。

3. 实验，实验，再实验

既然您已经涵盖了基础知识，接下来请深入PortSwigger的免费Web Security Academy内容，了解HTTP请求走私实际上是什么，以及如何利用它。这些故意设计为易受攻击的交互式实验室旨在模拟真实系统的行为，并且通常基于PortSwigger在研究期间发现的真实漏洞。我还建议使用HTTP Hacker完成相关实验，这将帮助您可视化整个HTTP流。

4. 延伸阅读

此时，您已具备利用已知反同步漏洞所需的一切。但是，如果您想发现广泛存在的反同步问题，最好的办法是尽可能了解每一个反同步漏洞类别。以下精选论文将极大地提升您的理解，并有助地为您提供一些关于进行自己研究的线索（如果那是您喜欢的事情）。

• Portswigger的Web Security Academy上"请求走私"主题下的所有内容
• @__w4ke 的 Funky Chunks
• @sw33Lie, @bsysop 和 @_medusa_1 的 TE.0 请求走私
• @tincho_508 的 响应走私

渗透测试人员的后续步骤

如果您是咨询公司或内部的渗透测试人员，希望您在过去几年中没有忽视HTTP请求走私。如果您以前从未发现过反同步问题，好消息是现在比以往任何时候都更容易找到正确的线索。如果您发现过并且问题已修补，我强烈建议您在未来进行任何重新测试时，假设先前发现的走私问题很可能可以通过稍微不同的头部混淆技术或策略重新发现。

作为渗透测试人员，您通常需要专注于特定类别的漏洞，特别是如果反同步漏洞被客户列为重点领域。在这些情况下，我会采用大量模糊测试来寻找功能性的解析器差异，无论是通过增强HTTP Request Smuggler还是通过您自己的模糊测试技术。

最后，是时候确保您的修复建议是最新的了。如果上游任何地方启用了HTTP/1.1，它就需要被移除。如果客户能够管理，端到端的HTTP/2+是理想的。在此阅读完整的修复建议。

漏洞赏金猎人的后续步骤

如果您是漏洞赏金猎人，反同步终局代表了获取奖金的大好机会，并且一如既往，您可以遵循一些核心策略来实现这一目标。

争当第一

如果您阅读本文时已经对HTTP请求走私有很好的掌握，请立即开始。使用最新的HTTP Request Smuggler更新并进行扫描。尽可能快地覆盖您所拥有的一切，以抢占先机。优先考虑猎人流量较低的私有项目，以给自己最好的机会。然而，这种策略的效果会很快减弱，因为James论文中的技术很少被经验丰富的猎人所忽视。

做到彻底

如果您不是自动化爱好者，并且更喜欢手动挖掘，那么通过针对特定程序上的一个非常大的文件，您可能会获得优势。现代应用程序绝对庞大，并且通常会根据您请求的资源将流量路由到不同的后端或中间组件。在这些情况下，选择代理历史记录中的所有内容，并让smuggler对相似条目进行去重，可能会在不太明显的地方产生反同步漏洞。

追求新颖

然而，迄今为止最有效的策略将是通过一种新颖的检测技术来增强HTTP Request Smuggler。如果您扫描的是其他人没有寻找的东西，您很可能会找到许多易受攻击的主机，可以向支付丰厚的项目报告。引用论文摘要中关于新的解析器差异扫描的话：“这种策略创造了大量的反同步研究线索”。根据我的经验，这 somehow 是一种轻描淡写的说法，所以发挥创意，只管尝试。

如果您不习惯这种方法，请不要因为复杂的代码更改想法而气馁。James使得添加新技术变得相当简单，并且有太多可以探索的内容，以至于我在下面专门创建了一个关于如何解决这个问题的部分。

调整HTTP Request Smuggler

新的反同步检测技术从Web安全研究社区中涌现已久，现在创建自己的技术比以往任何时候都更容易。要找到它们，您可以使用像HTTP Garden这样的模糊测试工具，阅读旧的研究论文和论坛帖子（流行AI模型的深度研究功能可能非常擅长找到这些……），或者（我认为是最有趣的选择）基于"愚蠢的想法"（肯定"别人已经想到过"）对现有工具进行微小的代码更改。关于这个话题我不会多说，因为James本人在多篇关于其研究方法的文章中详细介绍了这一点：

• 如何为Web安全研究自动化构建自定义扫描器
• 所以你想成为一名Web安全研究员？

如《HTTP/1.1必须消亡》论文所示，可以通过多种方式添加到smuggler的解析器差异扫描。有些比其他更容易，而我在编码方面很懒，因此以下按实现难易程度排序：

头部

在基本层面上，解析器差异扫描寻找那些可以根据实际处理头部的代理/后端触发不同响应的头部。因此，添加一个新的头部来检测这种行为实际上只取决于哪些头部会导致响应差异。还值得注意的是，您可以根据头部的值（无效 vs 有效）以及有效版本的头部是否与变异头部同时存在来获得不同的响应。因此，SignificantHeader 类要求您提供头部名称、值以及原始头部是否应与变异头部一起保留。

截至今天已实现的头部有：

1
2
3
4

canaryHeaders.add(new SignificantHeader("Host-invalid", "Host", "foo/bar", true));
canaryHeaders.add(new SignificantHeader("Host-valid-missing", "Host", original.httpService().host(), false));
canaryHeaders.add(new SignificantHeader("CL-invalid", "Content-Length", "Z", true)); 
canaryHeaders.add(new SignificantHeader("CL-valid", "Content-Length", "5", true));

所以本质上，是Host和Content-Length头部的几种不同表示形式。就是这样。如果您查看代码，有许多被注释掉的SignificantHeaders，可能值得根据您的经验重新启用或稍作修改。

总的来说，添加一个新的头部来测试差异涉及1行新代码：

1

canaryHeaders.add(new SignificantHeader("My New SigHeader", "HeaderName", "HeaderValue", true/false));

将最后的布尔值设置为false将确保原始请求中同名的头部被替换以避免重复头部。这实际上是单一和重复策略之间的区别，因此可能值得为两种策略都创建一个新的SignificantHeader。

排列

排列最好被认为是将头部从一个或多个代理/后端隐藏起来的方法。要添加这些，您需要将排列添加到ParserDiscrepancyScan.java文件中的此处，然后在HiddenPair.java中的switch case内创建排列逻辑本身。

例如，如果我想添加一个在头部名称后添加两个制表符的头部排列，我会进行以下更改。注意，PermutationOutcome.NODESYNC似乎是专门寻找差异的最佳选择。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

//ParserDiscrepancyScan.java
permutors.add(new HiddenPair("DOUBLETAB", HideTechnique.DOUBLETAB, PermutationOutcome.NODESYNC));

//HiddenPair.java
enum HideTechnique {
    //…,
    DOUBLETAB
}
//…

case DOUBLETAB:
                request = request.withAddedHeader(targetHeader.name()+"\t\t", targetHeader.value());
                break;

策略

策略看起来稍微复杂一些，尽管DUPLICATE和SINGLE策略仅通过SignificantHeader定义控制。源于不同HTTP动词的策略最近通过启动扫描时的方法覆盖选项添加。我怀疑这有点说明问题，并且可能是开始寻找容易被忽视的差异的好地方。

无论如何，如果您想添加更多基于方法的策略，您可能只需要在此处附近添加一个新的for循环，该循环使用base.withMethod("OPTIONS")更新基本请求，然后继续扫描的正常逻辑。

希望您现在对解析器差异扫描的可扩展性有了很好的了解。如果您取得成功，收集尽可能多的奖金/报告，然后如果您愿意，请提交拉取请求，以便其他测试人员可以使用您的技术。为了获得额外加分，考虑撰写一篇博客文章，以便社区可以传播消息，宣布又一种反同步技术已被发现。

利用反同步终局优势

总的来说，我们网络安全社区如何利用反同步终局来获得优势？HTTP/1.1不会很快消失，虽然无HTTP/1.1的世界是目标，但CDN、代理和云提供商都需要付出巨大努力。这需要时间，这是无法回避的事实。

对于漏洞赏金猎人来说，这对我来说代表了您所见过的最大机会之一。新颖的反同步技术通常仅差一个字符，这还没考虑已集成到开源工具中的现有技术的近乎无限的组合和排列。开始扫描吧，肯定还会有几十万美元的奖金开始让天平倾斜。

至于咨询公司和内部渗透测试人员，如果您厌倦了重新测试那些运行带有降级的HTTP/2的看似已加固的应用程序，现在就是您的时刻。确保您的修复建议是最新的，并花一些额外的时间进行解析器差异的模糊测试，我确定您不会失望。

结论

应用安全世界现在比以往任何时候都更有能力使用一种在2004年首次构想的技术来控制整个应用程序。无论您是经验丰富的反同步专家、刚刚被流水线误报刺痛的新手，还是只是想帮助防止一系列不可避免的题为"我告诉过你"的Black Hat演讲的人，请立即加入反同步终局，帮助我们消灭HTTP/1.1。