警惕假阳性：如何区分HTTP管道化与请求走私

有时人们以为自己发现了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行为。建议从Extensions->BApp Store安装该扩展以获得最佳学习效果。

底层实现中，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标签组的"按顺序发送组（单连接）“功能）：

识别是否存在缓存层，若存在则进行污染——这是容易实现的高影响力攻击
若无缓存，寻找输入反射装置并利用其揭示前端注入的头信息（有时内部头可实现完全身份验证绕过）
若存在可见的前端安全措施（如阻止特定路径请求），尝试通过请求走私绕过
最后探索应用对主机头篡改的响应（包括直接请求和走私请求），可能通过连接锁定的请求走私访问原本禁用的内部系统，或发起其他主机头攻击

连接状态攻击

探索连接锁定的请求走私时，可能还会发现连接状态攻击（如首请求路由）。这类攻击因某些服务器对同一连接的首请求与后续请求区别对待而产生，严格来说不属于请求走私漏洞，甚至可能发生在无前端服务器的目标上，但最终影响与连接锁定的请求走私非常相似。HTTP Request Smuggler支持"连接状态探测"功能，可自动识别此类攻击。

客户端反同步攻击

另一种可 exploiting 连接复用的场景是客户端反同步攻击。但需注意重大限制：攻击请求必须是能令受害者浏览器跨域发送的请求！实践中这意味着不能使用任何头混淆技术。详细信息请参考《浏览器驱动的反同步攻击》及我们的客户端反同步学院专题。

结论

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