代码审计里的请求走私：六个检查点

危害在于绕开前置的鉴权与限流，直接命中后端连接上的另一个用户会话

正着读代码容易漏，因为入口太多；反着找危险点，数据流只有那么几条。

先说结论

先列危险点，再回溯入口，最后确认校验与权限。

• 检查点一：所有外部入口是否都过统一校验
• 检查点二：危险函数是否集中封装
• 检查点三：校验是否只做一次、是否白名单
• 检查点四：权限判断是否在服务端
• 检查点五：错误信息是否泄露内部细节
• 检查点六：是否有兜底日志

检查点一：入口

同一个请求同时出现 Content-Length 与 Transfer-Encoding 时，RFC 要求以 TE 为准。

把入口列全：HTTP 参数、请求头、上传、消息队列、定时任务的外部输入。漏一个就白审。

检查点二：危险点

反代与后端都复用长连接，前一个请求的残留字节才会被算进下一个请求。

检查点三：校验逻辑

HTTP/2 降级到 HTTP/1.1 时头字段被重写，是最容易产生长度歧义的环节。

看到「先替换再校验」「只在一个接口校验」这两种写法，基本可以直接标红。

这个问题的几个审计细节

实际代码里最容易漏的几处：

• 反代与后端都复用长连接，前一个请求的残留字节才会被算进下一个请求
• 危害在于绕开前置的鉴权与限流，直接命中后端连接上的另一个用户会话

检查点四到六

危害在于绕开前置的鉴权与限流，直接命中后端连接上的另一个用户会话。

越权是审计里性价比最高的方向：少一行判断，就是一个中高危。错误信息要统一，日志要记入口摘要。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• 请求走私的本质是链路上前后两套 HTTP 解析器，对「请求在哪里结束」理解不一致
• 由一层统一处理 TE，并拒绝同时带 CL 与 TE 的请求，可以消掉大部分场景
• 只在一层做规范化，另一层仍按自己的规则解析长度
• 把 400 增多当成客户端问题，没有去看连接复用
• 测试时用短连接，复现不出来就认为不存在

审计的产出不是「找到几个洞」，是「知道这类洞在哪个模式里反复出现」。