警惕虚假误报：如何区分HTTP管道化与请求走私

詹姆斯·凯特尔
研究方向总监
@albinowax

发布日期：2025年8月19日 14:30 UTC
更新日期：2025年8月19日 14:31 UTC

有时人们以为发现了HTTP请求走私漏洞，但实际上只是观察到了HTTP保持连接或管道化现象。这通常属于误报，但有时确实存在真实漏洞！本文将探讨如何区分这两种情况。

本文的写作灵感来源于http1mustdie.com的发布，随后我收到了大量关于连接复用的困惑和咨询。由于答案过于复杂，无法简单回复，因此特此撰文详细说明。

连接复用误报

如果你发现某个请求走私概念验证仅在重用连接时有效，这很可能是个误报。以下是连接复用的常见示例：

• Turbo Intruder概念验证中requestsPerConnection大于1时
• 启用Burp Intruder的HTTP/1连接复用功能时
• 使用Burp Repeater的"按顺序发送组（单连接）“或"启用连接复用"时
• Burp Repeater攻击在一个响应中显示两个HTTP/1响应时

然而，这并不总是误报。存在三类需要连接复用的有效漏洞：

• 连接锁定式请求走私
• 连接状态攻击（技术上不属于请求走私）
• 客户端反同步攻击

因此，在创建请求走私概念验证时，应尽可能禁用连接复用。如果这导致攻击失效，你将面临选择——放弃或深入探究。

为帮助区分这两种场景，我发布了一个名为"走私还是管道化？“的自定义操作——可通过复制粘贴安装到Burp Repeater，或通过BApp商店中的Extensibility Helper扩展导入。

HTTP/1连接复用

大多数工具将HTTP/1请求表示为独立的个体。这通常是个便利的抽象概念，但请求走私试图打破这种抽象，因此理解底层机制至关重要。

为此，我们刚刚推出了HTTP Hacker——一款新的Burp Suite扩展，用于展示底层HTTP行为。要充分利用这些示例，请从扩展->BApp商店安装HTTP Hacker并跟随操作。

底层实现中，HTTP/1.1通过在底层TCP/TLS套接字上连接请求和响应来实现连接复用。这被称为HTTP连接复用、管道化或保持连接。示例如下：

1
2
3
4
5
6
7

POST / HTTP/1.1
Host: hackxor.net
Connection: keep-alive
Content-Length: 5

12345GET /robots.txt HTTP/1.1
Host: hackxor.net

管道化是连接复用的一种子类型，客户端一次性发送所有请求，并依赖响应按正确顺序返回。大多数服务器支持管道化请求，但实际发送的客户端很少——这也是Turbo Intruder如此快速的原因。

理解了基本原理后，让我们考虑发送两次CL.0攻击并重用连接时会发生什么：

1
2
3
4
5
6

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

响应一：

1
2

HTTP/1.1 200 OK
Content-Type: text/html

响应二：

1
2
3
4
5

HTTP/1.1 200 OK
Content-Type: text/plain

User-agent: *
Disallow: /settings

可以看到至少有一个服务器忽略了格式错误的Content_Length头。你可能认为在前端和后端Web服务器之间造成了反同步：

然而，实际只是导致你的HTTP客户端与目标服务器之间的反同步：

底层请求流如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

POST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: YPOST / HTTP/1.1
Host: hackxor.net
Content_Length: 47

GET /robots.txt HTTP/1.1
X: Y

这毫无用处。事实上，hackxor甚至没有后端，因此对请求走私免疫。

希望这能澄清为什么重用客户端连接会导致误报——如有任何疑问请告知。

连接锁定式请求走私

如果我能简单地说"测试请求走私时永远不要重用连接"就好了，但现实从不简单。

有些前端服务器仅在客户端连接被重用时才重用上游连接。这意味着你可能遇到只能通过客户端连接复用触发的请求走私漏洞。我将此场景称为连接锁定式请求走私。

要确认这一点，可以尝试通过HTTP/2发送触发包含嵌套HTTP/1响应的请求。这证明不是误报，值得投入时间构建漏洞利用。或者，通常可以使用部分请求来区分连接锁定式请求走私。

但要证明漏洞真实存在，需要获得超出"攻击者可以让自己收到意外响应"的实际影响证据。连接锁定式请求走私不能用于直接跨用户攻击，但仍可：

• 如果存在缓存层，通过污染服务器缓存来利用其他用户
• 利用输入反射披露内部HTTP头
• 绕过前端服务器应用的任何安全控制

这是达成有效报告的途径！如果认为发现了连接锁定式请求走私，建议按以下步骤操作。可在Turbo Intruder中使用requestsPerConnection=2，或通过Repeater标签组的"按顺序发送组（单连接）“进行探索。

首先，确定是否存在缓存层，如果存在则进行污染——这是简单的高影响攻击。

如果没有缓存，寻找输入反射 gadget 并利用它揭示前端注入的任何头信息。有时内部头可实现完全身份验证绕过！

如果存在任何可见的前端安全措施（如对某些路径的请求被阻止），尝试使用请求走私绕过它们。

最后，探索应用程序对主机头篡改的响应，包括直接和走私请求中的篡改。可能通过连接锁定式请求走私访问先前禁用的内部系统，或发起其他主机头攻击。

连接状态攻击

在探索连接锁定式请求走私时，还可能发现如首请求路由等连接状态攻击。

这些攻击的发生是因为某些服务器对每个连接的第一个请求与同一连接的后续请求处理方式不同。技术上不属于请求走私漏洞，甚至可能发生在没有前端服务器的目标上，但最终影响与连接锁定式请求走私非常相似。

HTTP请求走私扫描器支持"连接状态探测"功能，可尝试自动识别这些攻击。

客户端反同步攻击

还存在另一种连接复用可被利用的场景，即客户端反同步攻击。请注意这有一个主要限制——攻击请求必须是能让受害者浏览器跨域发送的内容！实际上，这意味着不能使用任何头混淆技术。更多信息请参考《浏览器驱动的反同步攻击》和我们的客户端反同步学院主题。

结论

希望本文对你有所帮助！请求走私是一个深度巨大的主题，本文仅是入门介绍。如需精通，请查看我们所有的反同步研究和包含20多个交互式实验的完整学院主题。