HTTP请求走私是一种利用前端服务器（如负载均衡器、CDN）和后端服务器在解析HTTP请求时存在差异，从而构造特殊请求包，导致前端与后端对请求边界判断不一致的攻击技术。攻击者通过精心构造的走私请求，可以绕过安全规则、劫持用户会话，甚至更危险的是——对网站缓存进行投毒。缓存投毒意味着攻击者能将恶意内容（如JavaScript、HTML）注入到缓存服务器中，当其他用户访问同一URL时，就会接收到被篡改的恶意响应，造成大规模的用户数据泄露或恶意代码执行。

HTTP请求走私的工作原理：为什么前端和后端会“误解”彼此？

核心问题在于HTTP协议中定义请求结束的标准不一致。RFC标准允许通过Content-Length（CL）和Transfer-Encoding（TE）两种头部来指定请求体长度，但当前端和后端服务器在处理这两个头部时优先级不同，就会产生解析歧义。例如，前端服务器可能优先处理Transfer-Encoding头部，认为请求体是分块传输的；而后端服务器却优先看Content-Length，将请求体按固定长度截断。这样，一个请求包中未被正确解析的部分就可能被“走私”到下一个请求中，污染后续的用户请求。

缓存投毒如何借助请求走私实现？

当攻击者利用请求走私，将恶意内容注入到缓存服务器的响应中时，就完成了缓存投毒。具体过程分三步：首先，攻击者发送一个走私请求，其中包含一个用于投毒的请求（如GET /index.html HTTP/1.1）。这个请求会被前端服务器转发给后端，但后端因为解析差异，可能将其与下一个正常请求合并处理。其次，攻击者控制恶意请求的响应内容，比如在响应头中插入X-Cache: Hit字段，使缓存服务器误以为这是可缓存的合法响应。最后，当其他用户访问同一资源（如/index.html）时，缓存服务器直接返回被投毒的恶意版本，而不是源站的安全内容。

常见的请求走私技术变体：CL.TE与TE.CL攻击

根据前端和后端服务器解析顺序的不同，主要存在两种走私技术变体。第一种是CL.TE攻击：前端使用Content-Length，后端使用Transfer-Encoding。攻击者可以构造一个包含CL头部和TE头部的请求，但TE部分采用畸形分块编码，使后端错误解析。示例请求如下：

POST /api HTTP/1.1
Host: target.com
Content-Length: 13
Transfer-Encoding: chunked

0

GET /poison.html HTTP/1.1

第二种是TE.CL攻击：前端使用Transfer-Encoding，后端使用Content-Length。攻击者构造一个TE头部，但隐藏CL头部，使后端按CL截断请求。这两种变体都可能被用于缓存投毒，尤其是当缓存服务器位于前端时，投毒效果会扩散到整个用户群。

实际攻击案例：从走私到缓存投毒的完整链条

一个典型场景是攻击者针对使用CDN的电商网站。首先，探测CDN（前端）和应用服务器（后端）的解析差异，确认存在CL.TE漏洞。然后，发送走私请求，将恶意JavaScript代码注入到网站的首页缓存中。例如，攻击者可能构造请求，使缓存服务器将<script>alert('xss')</script>存储为/index.html的响应。当普通用户访问首页时，CDN返回被投毒的页面，触发跨站脚本攻击，窃取用户的登录Cookie。这种攻击隐蔽性强，因为恶意内容存储在缓存中，源站并无异常日志。

防御策略：如何杜绝请求走私与缓存投毒？

防御需要多层次协同。首先，确保所有服务器使用一致的HTTP解析逻辑，禁用有歧义的头部处理。例如，配置前端和后端都只支持一种长度确定机制（如统一使用Content-Length），并严格验证Transfer-Encoding头部。其次，实施请求标准化：对传入请求进行规范化处理，拒绝包含多个长度头部的请求，或自动修正畸形分块编码。第三，缓存服务器应设置安全策略，如仅缓存响应状态码为200的GET请求，并对响应头进行校验，避免缓存带有危险头部（如X-Cache: Hit）的内容。最后，定期进行安全测试，使用自动化工具扫描走私漏洞，模拟攻击验证缓存投毒风险。

开发者与运维人员的实操检查清单

对于技术团队，建议立即执行以下步骤：

1. 审查所有HTTP服务器（Nginx、Apache、CDN配置）的解析设置，确保无歧义；

2. 在应用层添加中间件，过滤包含CL和TE双重头部的请求；

3. 监控缓存服务器的日志，关注异常缓存命中模式，如同一URL突然响应内容变化；

4. 对用户输入和输出响应进行严格编码，防止恶意脚本注入；

5. 考虑使用HTTP/2协议，其二进制帧结构减少了走私风险，但需注意降级攻击的可能性。

未来趋势：协议演进与持续威胁

随着HTTP/3的普及，基于QUIC的传输层可能减少传统走私漏洞，但攻击技术也会进化，例如利用中间件兼容性缺陷发起新型走私。同时，云原生架构中微服务间的请求转发增加了攻击面，缓存投毒可能蔓延至API网关。行业需保持警惕，将请求走私防护纳入DevSecOps流程，通过自动化安全测试和实时监控构建纵深防御体系。最终，安全不是单点解决方案，而是贯穿设计、开发与运维的持续实践。