秒懂Http请求走私
字数 1531 2025-08-12 12:08:15

HTTP请求走私漏洞详解

1. HTTP/1.1基础特性

1.1 Keep-Alive机制

  • HTTP/1.1默认使用持久连接(Persistent Connection)
  • 单个TCP连接上可以传输多个HTTP请求/响应
  • 通过Connection: keep-alive头显式声明(HTTP/1.1中默认)
  • 通过Connection: close显式关闭连接

1.2 管道化(Pipeline)

  • 允许客户端在同一个TCP连接上连续发送多个请求
  • 服务器必须按照请求到达的顺序返回响应

1.3 消息长度确定机制

Content-Length

  • 指定消息体的字节长度
  • 格式：Content-Length: <数字>
  • 问题：需要预先知道消息体长度，对动态生成内容不友好

Transfer-Encoding

  • 指定传输编码方式
  • 常用值：chunked(分块传输)
  • 分块传输格式： 
    <十六进制长度>\r\n
<数据>\r\n
0\r\n
\r\n
  • 以0长度块表示消息结束

2. 请求走私漏洞原理

2.1 基本前提

  • 前后端服务器分离架构(如反向代理+应用服务器)
  • 前后端对请求边界判断不一致
  • 导致请求被"截断"或"拼接"，影响后续请求

2.2 攻击原理图

[前端服务器] --不一致的边界判断--> [后端服务器]
      |                              |
      v                              v
正常处理请求                 将部分请求与下个请求拼接

3. 漏洞类型及利用

3.1 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

解析：

  1. 前端计算Content-Length为6(0\r\nG\r\n)
  2. 后端看到0\r\n认为请求结束
  3. 剩余的G与下个请求拼接

3.2 TE-CL类型

特征：

  • 前端使用Transfer-Encoding头
  • 后端使用Content-Length头

攻击示例：

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

5\r\n
GPOST\r\n
0\r\n
\r\n

解析：

  1. 前端处理分块：5字节的"GPOST"和结束块
  2. 后端根据Content-Length:4只读取"5\r\n"
  3. 剩余的"GPOST"与下个请求拼接

3.3 TE-TE类型

特征：

  • 前后端都处理Transfer-Encoding头
  • 通过混淆TE头使后端回退到CL处理

攻击示例：

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

0\r\n
G\r\n

解析：

  1. 前后端看到两个不一致的TE头
  2. 后端可能回退到使用Content-Length
  3. 导致类似CL-TE的攻击效果

4. 漏洞利用场景

4.1 拒绝服务(DoS)

  • 通过走私请求破坏正常用户的请求
  • 导致用户请求被错误解析或拒绝

4.2 绕过安全控制

  • 绕过前端的安全检查或认证
  • 访问本应受限的资源

4.3 组合攻击

  • 与XSS、SQL注入等漏洞结合
  • 会话固定攻击
  • 缓存投毒

5. 漏洞检测方法

5.1 手动检测步骤

  1. 寻找可能存在前后端分离的站点
  2. 尝试构造CL-TE/TE-CL/TE-TE的混淆请求
  3. 观察响应是否异常
  4. 发送两个连续请求，检查第二个请求是否受影响

5.2 自动化工具

  • Burp Suite插件：HTTP Request Smuggler
  • 自定义脚本发送测试请求

6. 防御措施

6.1 服务器配置

  • 前后端使用相同的请求解析逻辑
  • 禁用有歧义的请求头组合
  • 严格验证HTTP请求格式

6.2 编码实践

  • 避免直接转发原始HTTP请求
  • 对代理的请求进行规范化处理

6.3 其他措施

  • 使用HTTP/2(原生解决部分问题)
  • 定期安全测试和代码审计

7. 实验环境搭建

建议使用以下环境练习：

  • Burp Suite官方实验室(PortSwigger)
  • 自建反向代理+后端服务器环境
  • 使用Docker容器模拟多服务器架构

8. 扩展阅读

  • RFC 7230: HTTP/1.1 Message Syntax and Routing
  • OWASP HTTP Request Smuggling页面
  • PortSwigger关于请求走私的研究文章
HTTP请求走私漏洞详解 1. HTTP/1.1基础特性 1.1 Keep-Alive机制 HTTP/1.1默认使用持久连接(Persistent Connection) 单个TCP连接上可以传输多个HTTP请求/响应 通过 Connection: keep-alive 头显式声明(HTTP/1.1中默认) 通过 Connection: close 显式关闭连接 1.2 管道化(Pipeline) 允许客户端在同一个TCP连接上连续发送多个请求 服务器必须按照请求到达的顺序返回响应 1.3 消息长度确定机制 Content-Length 指定消息体的字节长度 格式： Content-Length: <数字> 问题：需要预先知道消息体长度，对动态生成内容不友好 Transfer-Encoding 指定传输编码方式 常用值： chunked (分块传输) 分块传输格式： 以0长度块表示消息结束 2. 请求走私漏洞原理 2.1 基本前提 前后端服务器分离架构(如反向代理+应用服务器) 前后端对请求边界判断不一致 导致请求被"截断"或"拼接"，影响后续请求 2.2 攻击原理图 3. 漏洞类型及利用 3.1 CL-TE类型 特征 ： 前端使用 Content-Length 头 后端使用 Transfer-Encoding 头 攻击示例 ： 解析 ： 前端计算 Content-Length 为6(0\r\nG\r\n) 后端看到 0\r\n 认为请求结束 剩余的 G 与下个请求拼接 3.2 TE-CL类型 特征 ： 前端使用 Transfer-Encoding 头 后端使用 Content-Length 头 攻击示例 ： 解析 ： 前端处理分块：5字节的"GPOST"和结束块 后端根据 Content-Length:4 只读取"5\r\n" 剩余的"GPOST"与下个请求拼接 3.3 TE-TE类型 特征 ： 前后端都处理 Transfer-Encoding 头 通过混淆TE头使后端回退到CL处理 攻击示例 ： 解析 ： 前后端看到两个不一致的TE头 后端可能回退到使用 Content-Length 导致类似CL-TE的攻击效果 4. 漏洞利用场景 4.1 拒绝服务(DoS) 通过走私请求破坏正常用户的请求 导致用户请求被错误解析或拒绝 4.2 绕过安全控制 绕过前端的安全检查或认证 访问本应受限的资源 4.3 组合攻击 与XSS、SQL注入等漏洞结合 会话固定攻击 缓存投毒 5. 漏洞检测方法 5.1 手动检测步骤 寻找可能存在前后端分离的站点 尝试构造CL-TE/TE-CL/TE-TE的混淆请求 观察响应是否异常 发送两个连续请求，检查第二个请求是否受影响 5.2 自动化工具 Burp Suite插件：HTTP Request Smuggler 自定义脚本发送测试请求 6. 防御措施 6.1 服务器配置 前后端使用相同的请求解析逻辑 禁用有歧义的请求头组合 严格验证HTTP请求格式 6.2 编码实践 避免直接转发原始HTTP请求 对代理的请求进行规范化处理 6.3 其他措施 使用HTTP/2(原生解决部分问题) 定期安全测试和代码审计 7. 实验环境搭建 建议使用以下环境练习： Burp Suite官方实验室(PortSwigger) 自建反向代理+后端服务器环境 使用Docker容器模拟多服务器架构 8. 扩展阅读 RFC 7230: HTTP/1.1 Message Syntax and Routing OWASP HTTP Request Smuggling页面 PortSwigger关于请求走私的研究文章