HTTP请求走私（HTTP Request Smuggling）是一种利用前端代理服务器和后端服务器对HTTP请求边界解析不一致来实现攻击的技术，攻击者通过精心构造畸形请求，让前端和后端对"一个请求在哪里结束、下一个请求从哪里开始"产生分歧，从而绕过安全策略、窃取敏感数据或实现缓存投毒。要防护这类漏洞，核心思路就是在请求进入后端之前，对所有HTTP请求进行严格的规范化解析、重组和校验，确保前后端看到的是完全一致的请求结构。下面我会从原理、攻击手法、防护策略到具体实现，把这件事讲透。
一、HTTP请求走私到底是怎么回事
HTTP协议本身并没有严格规定一个请求的结束位置，它依赖两个机制来判断：Content-Length头部和Transfer-Encoding头部。当一个请求同时包含这两个头部时，不同的服务器实现会有不同的优先级判断。前端代理（比如负载均衡器、CDN、WAF）可能优先看Content-Length，后端服务器可能优先看Transfer-Encoding，或者反过来。这种差异就是走私的温床。
举个最简单的例子：攻击者发送一个请求，Content-Length说请求体有100字节，但实际只发送了50字节，然后紧接着在同一条TCP连接上再塞一个恶意请求。前端代理认为这是一个完整的100字节请求（后面的恶意部分被当作下一个请求），而后端只读到50字节就认为请求结束了，剩下的内容被当作下一个请求的开头。这样攻击者就成功把恶意请求"走私"进了后端。
二、三种主流的走私攻击类型
第一种是CL.TE攻击（Content-Length与Transfer-Encoding冲突）。攻击者同时发送Content-Length和Transfer-Encoding: chunked两个头部，前端和后端对优先级处理不同，导致请求被拆分或拼接错误。
第二种是TE.CL攻击（Transfer-Encoding与Content-Length冲突）。原理类似，但利用的是Transfer-Encoding: chunked的分块传输机制和Content-Length的冲突。攻击者可以在分块数据中嵌入额外内容，让后端误解析。
第三种是分块传输混淆攻击。利用chunked编码中的扩展语法，比如在分块大小后面加注释、加空格等，不同解析器对这些"非法"但"可容忍"的格式处理不同，造成解析差异。
# CL.TE攻击示例 POST / HTTP/1.1 Host: target.com Content-Length: 15 Transfer-Encoding: chunked 0 GET /admin HTTP/1.1 Host: target.com # 前端看到：Content-Length=15，认为整个请求体是"0\r\n\r\nGET /admin..."共15字节，后面是新请求 # 后端看到：Transfer-Encoding优先，读到"0\r\n\r\n"就认为分块结束，GET /admin被当作新请求
三、防护的核心原则：请求规范化与重组
防护HTTP请求走私，不能只靠WAF的规则匹配，因为走私攻击的变形太多，规则永远追不上。真正有效的方法是在请求到达后端应用之前，做一层严格的请求规范化（Request Normalization）。具体来说有以下几个关键步骤：
首先，拒绝所有包含歧义头部的请求。任何同时包含Content-Length和Transfer-Encoding的请求，直接拒绝。任何Content-Length值与实际请求体长度不一致的请求，直接拒绝。这是最基本的第一道防线。
其次，对所有请求进行重新编码和重组。不管前端传过来的请求长什么样，在中间层把它完全解析成标准结构，然后用统一的方式重新生成请求再转发给后端。这样后端看到的永远是干净、标准的请求。
第三，统一处理分块传输。对所有chunked编码的请求，在中间层先完整解码，验证分块格式合法性，然后用Content-Length重新封装后再转发。
四、具体的技术实现方案
方案一：在反向代理层做请求重组。以Nginx为例，可以通过Lua模块或者自定义的中间件来实现。核心逻辑是读取完整的请求体，校验Content-Length和实际长度是否一致，然后重新构造请求。
# Nginx + Lua 请求重组示例
location / {
access_by_lua_block {
local headers = ngx.req.get_headers()
local cl = headers["Content-Length"]
local te = headers["Transfer-Encoding"]
-- 拒绝同时存在CL和TE的请求
if cl and te then
ngx.status = 400
ngx.say("Bad Request: Ambiguous headers")
ngx.exit(400)
end
-- 校验Content-Length与实际体长度
ngx.req.read_body()
local body = ngx.req.get_body_data()
if cl and body and #body ~= tonumber(cl) then
ngx.status = 400
ngx.say("Bad Request: Content-Length mismatch")
ngx.exit(400)
end
}
proxy_pass http://backend;
}方案二：使用专门的安全中间件或API网关。很多商业WAF和API网关产品已经内置了HTTP走私防护模块，它们会在流量入口处自动做请求规范化。如果你用的是云服务商的负载均衡，建议开启其高级防护功能，通常会包含这一层。
方案三：在应用层做二次校验。即使前面有代理层防护，应用本身也应该对请求头部做校验。比如在Java Spring Boot中，可以写一个Filter，在请求进入Controller之前检查头部合法性。
// Spring Boot Filter 示例
@Component
public class SmugglingProtectionFilter implements Filter {
@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
HttpServletRequest httpReq = (HttpServletRequest) request;
String contentLength = httpReq.getHeader("Content-Length");
String transferEncoding = httpReq.getHeader("Transfer-Encoding");
if (contentLength != null && transferEncoding != null) {
((HttpServletResponse) response).sendError(400, "Ambiguous headers");
return;
}
// 读取完整body并校验
String body = new BufferedReader(new InputStreamReader(httpReq.getInputStream()))
.lines().collect(Collectors.joining("\n"));
if (contentLength != null && !contentLength.equals(String.valueOf(body.length()))) {
((HttpServletResponse) response).sendError(400, "Length mismatch");
return;
}
chain.doFilter(request, response);
}
}五、容易被忽略的防护细节
很多人以为只要WAF开着就万事大吉，但实际上有几个细节特别容易出问题。第一是HTTP/2到HTTP/1.1的转换。如果你的前端用HTTP/2，后端用HTTP/1.1，中间的协议转换层本身就可能引入解析差异，这个转换点必须做严格的请求重组。
第二是管道化请求（HTTP Pipelining）。HTTP/1.1支持在同一连接上连续发送多个请求，如果处理不当，前一个请求的尾部可能被当作后一个请求的头部。解决办法是在代理层禁用管道化，或者对每个请求做完整的边界校验。
第三是分块传输中的扩展语法。RFC 7230允许chunked编码中在分块大小后面加扩展信息，比如"5;name=value\r\n"。有些解析器会忽略扩展，有些会报错。防护时必须在中间层把这些扩展全部剥离，只保留纯数字的分块大小。
第四是头部折叠和注入。走私攻击经常配合HTTP头部注入使用，比如在请求中嵌入\r\n来伪造新的头部。防护时要对所有头部值做严格的过滤，禁止头部值中出现换行符。
六、如何验证你的防护是否有效
防护做完了，怎么确认真的防住了？最直接的方法是用专门的走私测试工具做渗透测试。比如使用开源工具"HTTP Smuggler"或者Burp Suite的相关插件，对你的系统发送各种变体的走私请求，看是否都被拦截或正确处理了。
测试时要覆盖所有攻击类型：CL.TE、TE.CL、分块混淆、管道化、头部折叠等。同时要测试正常请求是否还能正常通过，避免防护策略过于激进导致误杀。
另外建议建立持续监控机制。在代理层记录所有被拒绝的歧义请求，定期分析日志，看是否有新型的走私变体出现。安全是动态的，防护策略也需要持续更新。
七、总结与建议
HTTP请求走私是一种底层协议层面的漏洞，它不依赖应用代码的bug，而是利用协议本身的模糊性。防护它不能只靠某一个环节，需要从前端代理、中间件、到后端应用形成完整的纵深防御。核心就是三件事：拒绝歧义请求、规范化重组请求、持续测试验证。把这三件事做扎实，基本上就能挡住绝大多数走私攻击。对于中小企业来说，优先选择内置了走私防护的云WAF或API网关产品，成本低效果好；对于大型系统，建议在自建代理层实现定制化的重组逻辑，配合定期的安全审计，才能真正高枕无忧。
