HTTP请求走私漏洞详解

1. HTTP协议基础

1.1 HTTP/1.1特性

HTTP/1.1是应用层协议，相比HTTP/1.0引入了两个重要特性：

Keep-Alive：在HTTP/1.1中，所有HTTP报文默认都是持久的（长连接），除非显式指定Connection: close。这允许在单个TCP连接上发送多个请求，提高了连接利用率。
Pipeline：允许在一个TCP连接中连续发送多个请求而不需要等待响应，但响应必须按照请求的顺序返回。

1.2 报文长度标识机制

HTTP协议提供了两种方式来标识请求体的长度：

Content-Length (CL)：
- 明确指定请求体的字节长度
- 示例：Content-Length: 42表示请求体有42字节
- 问题：对于动态生成的内容，计算长度会增加内存消耗
Transfer-Encoding (TE)：
- 当值为chunked时，使用分块编码传输
- 每个块包含十六进制长度值+数据，以0长度块表示结束
- 示例格式：
```
5\r\n
chunk\r\n
0\r\n
\r\n
```

2. 漏洞原理

HTTP请求走私发生在前后端服务器对请求结束的判定不一致时，通常出现在：

前后端服务器分离架构
使用CDN加速服务的情况下

核心原理：前端和后端服务器对请求边界判断方式不同，导致请求被"截断"，剩余部分与下一个请求拼接，从而影响下一个请求的处理。

3. 漏洞类型及利用

3.1 CL-TE (前端使用CL，后端使用TE)

场景：

前端服务器只处理Content-Length请求头
后端服务器处理Transfer-Encoding请求头

攻击步骤：

构造特殊请求：

POST / HTTP/1.1
Host: vulnerable.com
Content-Length: 6
Transfer-Encoding: chunked

0\r\n
G\r\n

前端处理：
- 根据CL=6，认为请求体是0\r\nG\r\n（共6字节）
- 正常转发给后端
后端处理：
- 根据TE头，看到0\r\n认为请求结束
- 剩余的G\r\n会与下一个请求拼接

利用效果：

可导致拒绝服务（普通用户请求被篡改）
可构造XSS、SQL注入等攻击
可绕过前端认证

3.2 TE-CL (前端使用TE，后端使用CL)

场景：

前端服务器处理Transfer-Encoding请求头
后端服务器处理Content-Length请求头

攻击构造：

POST / HTTP/1.1
Host: vulnerable.com
Content-Length: 4
Transfer-Encoding: chunked

5c\r\n
GPOST / HTTP/1.1\r\n
Content-Length: 15\r\n
\r\n
x=1\r\n
0\r\n
\r\n

处理过程：

前端根据TE处理，看到0\r\n结束块
后端根据CL=4，只读取5c\r\n（4字节）
剩余部分与下一个请求拼接

3.3 TE-TE (混淆TE头)

场景：

前后端都使用TE处理，但通过混淆TE头使后端回退到CL处理

攻击构造：

POST / HTTP/1.1
Host: vulnerable.com
Content-Length: 3
Transfer-Encoding: chunked
Transfer-encoding: low

8\r\n
SMUGGLED\r\n
0\r\n
\r\n

处理过程：

前端使用第一个TE头正常处理
后端发现两个不一致的TE头，回退使用CL处理
导致请求走私

4. 漏洞检测

4.1 手动检测方法

尝试发送模糊的请求：
- 同时包含CL和TE头
- 发送不完整的chunked编码
- 发送非标准的TE值
观察响应：
- 延迟响应
- 异常错误
- 后续请求被影响

4.2 自动化工具

使用Burp Suite插件：

HTTP Request Smuggler：自动化检测各种请求走私变体

5. 防御措施

前后端一致：确保所有服务器使用相同方式解析请求
禁用TE：如果不需分块传输，禁用TE支持
规范化处理：
- 拒绝包含多个不同CL/TE头的请求
- 对TE头值大小写不敏感
连接管理：
- 对可疑连接立即关闭
- 为每个请求使用独立连接（影响性能）
Web应用防火墙：配置规则检测请求走私尝试

6. 实际利用案例

会话固定：通过走私请求设置受害者会话
权限提升：绕过前端安全控制
缓存投毒：污染CDN缓存
反射型XSS：将恶意脚本注入其他用户请求
Web缓存欺骗：获取其他用户敏感信息

7. 实验室练习

建议使用以下资源练习：

PortSwigger的Web安全学院实验室
自行搭建测试环境
使用Burp Suite的Repeater工具手动构造请求

8. 总结

HTTP请求走私是一种利用服务器对HTTP协议解析差异的攻击技术，危害严重且难以检测。防御的关键在于确保所有服务器组件对HTTP协议有一致的解析方式，并对异常请求进行严格处理。

HTTP请求走私漏洞详解 1. HTTP协议基础 1.1 HTTP/1.1特性 HTTP/1.1是应用层协议，相比HTTP/1.0引入了两个重要特性： Keep-Alive ：在HTTP/1.1中，所有HTTP报文默认都是持久的（长连接），除非显式指定 Connection: close 。这允许在单个TCP连接上发送多个请求，提高了连接利用率。 Pipeline ：允许在一个TCP连接中连续发送多个请求而不需要等待响应，但响应必须按照请求的顺序返回。 1.2 报文长度标识机制 HTTP协议提供了两种方式来标识请求体的长度： Content-Length (CL) ：明确指定请求体的字节长度示例： Content-Length: 42 表示请求体有42字节问题：对于动态生成的内容，计算长度会增加内存消耗 Transfer-Encoding (TE) ：当值为 chunked 时，使用分块编码传输每个块包含十六进制长度值+数据，以0长度块表示结束示例格式： 2. 漏洞原理 HTTP请求走私发生在前后端服务器对请求结束的判定不一致时，通常出现在：前后端服务器分离架构使用CDN加速服务的情况下核心原理：前端和后端服务器对请求边界判断方式不同，导致请求被"截断"，剩余部分与下一个请求拼接，从而影响下一个请求的处理。 3. 漏洞类型及利用 3.1 CL-TE (前端使用CL，后端使用TE) 场景：前端服务器只处理 Content-Length 请求头后端服务器处理 Transfer-Encoding 请求头攻击步骤：构造特殊请求：前端处理：根据CL=6，认为请求体是 0\r\nG\r\n （共6字节）正常转发给后端后端处理：根据TE头，看到 0\r\n 认为请求结束剩余的 G\r\n 会与下一个请求拼接利用效果：可导致拒绝服务（普通用户请求被篡改）可构造XSS、SQL注入等攻击可绕过前端认证 3.2 TE-CL (前端使用TE，后端使用CL) 场景：前端服务器处理 Transfer-Encoding 请求头后端服务器处理 Content-Length 请求头攻击构造：处理过程：前端根据TE处理，看到 0\r\n 结束块后端根据CL=4，只读取 5c\r\n （4字节）剩余部分与下一个请求拼接 3.3 TE-TE (混淆TE头) 场景：前后端都使用TE处理，但通过混淆TE头使后端回退到CL处理攻击构造：处理过程：前端使用第一个TE头正常处理后端发现两个不一致的TE头，回退使用CL处理导致请求走私 4. 漏洞检测 4.1 手动检测方法尝试发送模糊的请求：同时包含CL和TE头发送不完整的chunked编码发送非标准的TE值观察响应：延迟响应异常错误后续请求被影响 4.2 自动化工具使用Burp Suite插件： HTTP Request Smuggler ：自动化检测各种请求走私变体 5. 防御措施前后端一致：确保所有服务器使用相同方式解析请求禁用TE ：如果不需分块传输，禁用TE支持规范化处理：拒绝包含多个不同CL/TE头的请求对TE头值大小写不敏感连接管理：对可疑连接立即关闭为每个请求使用独立连接（影响性能） Web应用防火墙：配置规则检测请求走私尝试 6. 实际利用案例会话固定：通过走私请求设置受害者会话权限提升：绕过前端安全控制缓存投毒：污染CDN缓存反射型XSS ：将恶意脚本注入其他用户请求 Web缓存欺骗：获取其他用户敏感信息 7. 实验室练习建议使用以下资源练习： PortSwigger的Web安全学院实验室自行搭建测试环境使用Burp Suite的Repeater工具手动构造请求 8. 总结 HTTP请求走私是一种利用服务器对HTTP协议解析差异的攻击技术，危害严重且难以检测。防御的关键在于确保所有服务器组件对HTTP协议有一致的解析方式，并对异常请求进行严格处理。