一次 HTTP 请求走私事故复盘：A 用户的请求体被拼进 B 用户会话的根因与加固

一、现象：三起「串号」投诉，指向一个没人想到的入口

先摆数字。去年 Q3 我们给一家多租户订单 SaaS 做安全加固复盘。技术栈是 Nginx 1.24 反代 + Spring Boot 3.1（内嵌 Tomcat 10.1.11），对外提供 POST /api/order、POST /api/order/cancel 两个写接口。

一周内连出三起「串号」投诉：

• 用户 A 提交订单后，紧接着用户 B 刷新页面，页面里闪出了 A 的订单明细片段（订单号、收货片段）；
• 一个未登录的请求，返回了带 Set-Cookie: session=... 的管理后台响应；
• 一次「取消订单」接口返回了 200，但实际把下一个用户的创建请求给吞了。

当天流经这两个接口的请求约 1.7 万次，事后从 Nginx access log 与后端业务日志对账，确认被污染 / 错位的请求约 40 余条，涉及 23 个租户的 61 笔订单。这不是偶发 bug——抓包重放后，我用 3 次请求就能稳定复现「把 A 的请求体拼进 B 的会话」。

二、根因：前端代理和后端对「一个请求在哪里结束」判断不一致

HTTP 请求走私（HTTP Request Smuggling）的本质，一句话：前端代理（Nginx）与后端（Tomcat）对同一个请求体「到底读到哪算结束」的理解不一致，于是多出来的字节没有变成独立请求，而是被「吞」进了下一个请求里。

它有两种基本形态，方向相反：

CL.TE（前端信 Content-Length，后端信 Transfer-Encoding） 请求同时携带 Content-Length: N 和 Transfer-Encoding: chunked。Nginx 按 Content-Length 切分请求边界，Tomcat 按 chunked 的终止块 0\r\n\r\n 切分。当 chunked 体比 Content-Length 长时，Nginx 认为「请求到此结束，后面的字节是下一个请求」，而 Tomcat 认为「请求还没结束，把后面那段也当成当前请求体的一部分」——错位就此产生。

TE.CL（方向相反） Nginx 按 chunked 切分、Tomcat 按 Content-Length 切分。多数现代前端代理都默认支持 chunked，所以 TE.CL 反而比 CL.TE 更难防。

关键点：两端都「支持」chunked 不是安全，恰恰是「都支持但语义不一致」才危险。只要至少一端会跟随/忽略某个头，而另一端不这么认为，就存在走私面。

三、具体做法：把「请求边界」收敛成唯一事实来源

1. 检测：上线前跑三类探测

用 h2smuggler（或 smuggler/smudge）对目标做 CL.TE / TE.CL / CL0.TE 探测。最小复现 payload（CL.TE，Content-Length=4 但 chunked 体更长）：

POST /api/order HTTP/1.1
Host: shop.example.com
Content-Type: application/json
Content-Length: 4
Transfer-Encoding: chunked

5
GET /
0

aaaa

Content-Length=4 让 Nginx 在 aaaa 处就切分请求；而 Tomcat 读到 0\r\n\r\n 才认为结束，于是把 aaaa 之后的字节并入当前请求体——下一个真实请求的头部就被「顶」进了 A 的 body。

2. 修复：入口层只信一端（推荐以 Content-Length 为唯一事实来源）

在 Nginx 入口直接拒绝双头并存或拒绝 chunked，把歧义挡在代理层：

# 方案 A：拒绝同时携带 Content-Length 与 Transfer-Encoding 的请求
map "$http_content_length$http_transfer_encoding" $ambig {
    default "";
    ~*.* "1";
}
if ($ambig) { return 411; }

# 方案 B（更激进）：入口不信任 chunked，统一转成 Content-Length
if ($http_transfer_encoding ~* "chunked") {
    return 411;
}

说明：RFC 9112 允许两者并存（以 Content-Length 优先），但安全上应主动拒绝歧义请求，把「唯一事实来源」固定在代理侧。

3. 后端兜底：Tomcat 对非法 chunked 直接 400

把 Tomcat 升到已修复版本（9.0.62+ / 10.1.8+），这些版本对畸形 chunked 会返回 400 而非静默解析；Spring 侧再叠加一条过滤器，对「Transfer-Encoding 与 Content-Length 数值不一致」的请求直接 400，避免依赖单点。

4. WAF 与监控

接入 OWASP CRS 的 942100 规则族（HTTP 走私检测）兜底；同时把「400/411 异常请求体」纳入告警——走私流量往往伴随大量 411 Length Required，是天然的信号。

四、踩过的坑（反直觉之处）

1. 「前后端都支持 chunked 就安全」是最大误区——问题不在「支持」，在「语义不一致」。
2. TE.CL 比 CL.TE 难防：多数前端代理默认按 chunked 切分，方向相反时更难收敛，务必两端同时改。
3. trailing headers 是隐形杀手：chunked 的终止块 0\r\n\r\n 之前可以塞尾部头，很多 naive 解析器会在 0\r\n\r\n 处提前结束，把尾部字节漏给下一个请求。
4. 大小写敏感：transfer-encoding 与 Transfer-Encoding 在部分旧解析器里行为不同，别只测一种写法。
5. 0 长度 chunk / 多个 0; 尾块会让解析器分叉，h2smuggler 的 CL0.TE 模式专门打这个。
6. 反直觉点：把请求「规范化成只保留 Content-Length」并不总有效——如果后端忽略 Transfer-Encoding，CL.TE 依然成立；必须两端对齐到同一端，只改一端等于没改。

五、结论与可复用清单

• 入口代理与后端必须对「请求边界」有唯一且一致的定义；推荐以 Content-Length 为唯一事实来源，在入口拒绝 chunked 或拒绝双头并存。
• 上线前用 h2smuggler 跑 CL.TE / TE.CL / CL0.TE 三类探测，并留档复现命令纳入回归。
• 升级 Tomcat 到 9.0.62+ / 10.1.8+ 等修复版本，后端叠加「双头不一致即 400」的过滤器。
• WAF 兜底（OWASP CRS 942100 族）+ 监控 400/411 异常请求体告警。
• 记性：走私不是「某一层有 bug」，而是「两层对同一协议的理解不一致」——修法是收敛语义，而不是给某一端打补丁。

参考：OWASP HTTP Request Smuggling 指南、RFC 9112（HTTP/1.1）。本文案例数据已脱敏。