题干与适用场景
一个应用经过 CDN、反向代理、WAF 和后端服务。安全团队发现不同组件对同一 HTTP/1.1 字节流的请求边界解释不一致，攻击者可能让前端认为只有一个请求，而后端从剩余字节中解析出第二个请求。请解释请求走私的原理，说明 Content-Length 与 Transfer-Encoding 冲突时的安全处理，并给出检测、修复、验证与上线方案。
RFC 9112 指出，多个接收方使用不同的健壮性解析规则会产生请求走私风险；OWASP 将其归因于前端和后端组件对请求解析不一致。题目考察候选人能否把抽象的“解析差异”还原为字节流、连接复用和安全边界问题，而不是只背诵某个攻击缩写。
面试官考察点
- 能否区分消息分帧、路由和应用层参数校验三个层次。
- 能否准确说明
Content-Length、Transfer-Encoding和 HTTP/1.0 降级的边界。 - 能否指出代理链中谁解析、谁复用连接，以及残留字节如何影响下一请求。
- 能否提出拒绝歧义请求、统一解析器和关闭连接等防御组合。
- 能否设计不发送真实攻击副作用的测试、监控和灰度回滚。
- 能否说明 HTTP/2 或 HTTP/3 场景仍需检查翻译层，而不是简单宣称协议升级即可解决。
回答前需要澄清的问题
- 链路中有哪些 HTTP 版本和中间件？默认至少有一个 HTTP/1.1 代理与一个后端连接池。
- 前后端是否复用到同一 TCP 连接？请求走私通常依赖连接复用或解析状态不同。
- 是否允许分块传输和请求体？默认公共入口允许，但可选择统一拒绝歧义组合。
- 修复目标是立即止血还是长期消除解析差异？需要分别给出临时和永久措施。
- 测试环境能否使用隔离后端和无副作用端点？默认必须使用隔离端点，不能在生产发送破坏性载荷。
30 秒回答框架
我会先画出代理到后端的字节流和连接复用关系。请求走私的根因是不同接收方用不同规则决定消息长度，尤其是同时出现 Content-Length 和 Transfer-Encoding 或非法重复长度时。入口应拒绝歧义请求，严格按 RFC 解析，异常后关闭连接，代理和后端使用同一实现与版本。修复后用隔离端点和双组件对照测试确认边界一致，监控异常 400、连接重置和解析错误，灰度期间保留旧路由以便回滚。
分步骤深入解答
第一步：画出消息和连接边界
先列出客户端、CDN、WAF、反向代理和后端各自是否解析请求、是否重写头部、是否复用上游连接。解释 HTTP/1.1 是字节流协议，接收方必须从头部字段推导消息体长度；一旦两层对边界的结论不同，剩余字节可能被下一层当作另一个请求。
不要从攻击载荷开始背诵。先用一个无副作用的示意字节流说明“前端读到一个请求，后端读到两个请求”的状态变化，面试官才能判断你理解了边界。
第二步：说明长度规则和歧义
RFC 9112 对消息体长度、Content-Length 和 Transfer-Encoding 给出明确规则。若请求同时带有二者，接收方不能各自选择一个继续处理；应将其视为潜在攻击并拒绝，必要时关闭连接。重复但值不同的 Content-Length 同样必须拒绝，不能取第一项或最后一项。
收到 HTTP/1.0 请求中的 Transfer-Encoding 时，服务器不能把它当成正常分块语义；应按规范处理错误并关闭连接。关键原则是所有接收方采用同一严格规则，而不是依赖“更宽容”来兼容坏客户端。
第三步：解释连接复用如何放大影响
前端代理可能把一个客户端连接拆成多个上游请求，后端连接池则在响应完成前继续等待剩余字节。如果前端和后端对边界不同，攻击者注入的前缀会留在复用连接中，成为下一个请求的开头。受影响对象可能包括缓存、认证路由、内部管理端点和其他租户请求。
因此修复不能只改应用路由。要检查代理是否在解析错误后复用连接，是否清空缓冲区，是否把异常请求转发给不同后端，以及 HTTP/2 到 HTTP/1.1 的翻译层是否重新生成一致的长度字段。
第四步：给出入口止血策略
边缘层先拒绝同时出现 Content-Length 与 Transfer-Encoding 的请求、重复长度字段、非法分块语法和不支持的 HTTP 版本。解析失败后关闭连接，不把剩余字节交给下一个请求。临时措施可以对受影响路由禁用上游连接复用，但这会增加延迟和连接成本，只能作为止血。
拒绝规则要有明确例外和日志分类，避免多个组件各自实现黑名单。能统一升级解析库时，应让代理与后端共享严格的规范行为，并用兼容性清单处理真实客户端。
第五步：统一解析和规范化头部
入口应在单一解析边界完成消息分帧，再把结构化请求传给应用。禁止应用重新解析原始头部或信任代理传来的“已校验长度”。若代理必须重写请求，应删除歧义字段并根据实际转发体重新生成一个规范长度，且下游不能看到旧字段。
对 HTTP/2 或 HTTP/3，帧层本身不同，但到 HTTP/1.1 的网关仍可能产生解析差异。检查每个协议翻译点的头部合并、请求体缓冲、异常连接处理和是否允许降级。
第六步：设计安全测试
在隔离环境准备前端代理和后端回显服务，让测试只记录请求 ID、解析长度和到达顺序。覆盖冲突长度、重复长度、非法分块、HTTP/1.0 降级、连接复用、超时和代理重试。测试断言前后端看到同一个请求数、同一方法、路径和体长度。
不要把会修改账户、订单或缓存的载荷发送到生产。可以用影子流量、合成连接和只读端点；若必须验证真实链路，先关闭副作用并保留连接级日志。
第七步：监控、灰度和回滚
监控解析错误、异常 400/431、连接重置、上游超时、同一连接多请求的边界异常和 WAF 与后端请求数不一致。按代理版本、协议、租户和路径分层，避免平均值掩盖单个边缘节点。
先让新解析策略在影子或小比例流量运行，设置停止条件，例如解析错误激增、合法客户端失败率上升或连接资源耗尽。回滚时恢复旧路由和配置版本，并保留“拒绝歧义请求”的安全开关；不能为恢复兼容性而重新打开宽松解析。
第八步：复杂度与沟通
单次消息分帧在读取头部和体时是线性于消息大小的；防御重点不是微优化，而是确保每个字节只被一个规范解析边界消费。把规范、组件版本、连接策略和测试矩阵写进运行手册。
向非安全团队解释时，用“两个收件人对同一信封的页数理解不同”说明风险，再给出可验证的工程动作：拒绝歧义、统一解析、错误断连、隔离测试和可回滚灰度。这样能把安全结论转成可执行的发布条件。
高质量示范回答
请求走私不是单个应用路由的 bug，而是代理链对同一 HTTP/1.1 字节流产生不同消息边界。前端可能依据 Content-Length 读完请求，后端却依据 Transfer-Encoding 继续读分块体；攻击者留下的字节就可能成为复用连接上的下一个请求。我的第一步是盘点每个解析和翻译点，统一升级到严格遵循 RFC 9112 的实现，并在入口拒绝二者并存、重复长度和非法分块；解析错误后关闭连接。
我会用隔离回显后端做冲突长度、连接复用、重试和协议翻译测试，断言各层看到的请求数、路径和体长度一致。上线先影子运行再灰度，监控解析错误、连接重置、合法请求失败率和前后端计数差异。超过停止条件就回滚路由和版本，但保留拒绝歧义请求的安全策略，避免用宽松解析换回表面兼容。
常见错误
- 只背诵两个攻击缩写，不解释字节流和连接复用。
- 说“优先使用 Content-Length”或“优先使用 Transfer-Encoding”，却忽略歧义请求应拒绝。
- 重复
Content-Length时取第一项或最后一项继续处理。 - 只修改后端应用，忽略 CDN、WAF、代理和协议翻译层。
- 测试直接打生产副作用端点，或没有断言前后端请求数一致。
- 解析错误后继续复用连接，让残留字节污染下一请求。
- 认为 HTTP/2 或 HTTP/3 自动消除了网关翻译层风险。
- 灰度只看总体 5xx，不分组件版本、协议和合法客户端失败率。
追问及应对
同时出现 Content-Length 和 Transfer-Encoding 时应该怎么做？
按严格规范视为歧义请求并拒绝，通常在解析边界关闭连接。所有代理和后端都要采用同一规则，不能让一层选择其中一个继续转发。
重复的 Content-Length 值相同也要拒绝吗？
在跨组件链路中，最安全的策略是拒绝重复字段，除非整条链路明确采用相同的规范合并规则。兼容性需求应通过受控白名单和测试解决，不能让不同组件自行决定。
如何验证修复没有破坏正常客户端？
收集合法客户端的协议版本、体编码和代理路径，在隔离环境做回放与合成测试。灰度监控合法 4xx、连接重置和延迟，并准备按客户端类型回滚或升级，而不是重新开启宽松解析。
HTTP/2 是否完全免疫请求走私？
HTTP/2 的二进制帧减少了部分 HTTP/1.1 分帧歧义，但 HTTP/2 到 HTTP/1.1 的网关翻译仍会生成头部和请求体。必须审计翻译规则、连接复用和下游解析，不能只看客户端协议。
代理解析失败后为什么应该关闭连接？
解析失败时无法证明缓冲区剩余字节属于当前还是下一请求。关闭连接丢弃不确定状态，能阻止残留字节在复用连接中被重新解释；代价是一次连接重建，应监控资源影响。
如何把请求走私与缓存投毒区分开？
请求走私是消息边界解析差异，缓存投毒是让缓存存入攻击者控制的响应或键。走私可能成为投毒的前置条件，但修复应先统一解析和断连，再单独验证缓存键、响应路由与权限。
你会保留哪些审计字段？
记录代理和后端版本、协议、连接 ID、解析结果、拒绝原因、头部规范化摘要、请求 ID 和响应状态。不要记录敏感正文；字段要能关联一条请求在各层的边界判断与最终处置。