网站漏洞防护之HTTP请求走私检测与反向代理配置修正

HTTP请求走私是近年来针对反向代理架构最隐蔽、破坏力最强的漏洞之一。它不直接攻击应用代码，而是利用前端代理服务器和后端源站对HTTP请求边界解析不一致，将恶意请求“夹带”进下一个正常用户的请求中。攻击一旦成功，轻则窃取敏感数据、劫持用户会话，重则实现缓存投毒、绕过WAF防护，甚至直接接管后台管理接口。解决这个问题的核心在于两点：精确检测出环境中是否存在走私风险，以及通过修正反向代理配置从根本上消除解析歧义。

要理解检测和修复，必须先搞清楚漏洞产生的底层逻辑。HTTP协议规范中，界定请求体长度主要依赖两个头部：Content-Length（CL）和Transfer-Encoding（TE）。Content-Length直接声明请求体的字节数，简单明了。Transfer-Encoding: chunked则采用分块传输，每个分块自带长度前缀，以长度为0的块表示结束。问题在于，当请求同时包含这两个头部，或者存在畸形换行、歧义编码时，前端代理和后端服务器可能选择不同的头部来确定请求边界。如果前端用Content-Length认为请求在A点结束，而后端用Transfer-Encoding认为在B点结束，中间这段数据就会被后端当成下一个请求的开头，攻击者精心构造的恶意数据就此注入合法请求流。

CL.TE类型中，前端信任Content-Length，后端信任Transfer-Encoding。攻击者发送一个POST请求，包含Content-Length和Transfer-Encoding: chunked，但请求体内容被精心截断。前端按Content-Length读完整个请求体后转发给后端，后端因为看到Transfer-Encoding，会尝试解析分块数据，结果把剩余部分当作下一个请求的前缀。TE.CL类型正好相反，前端信任Transfer-Encoding，后端信任Content-Length。攻击者在分块数据中提前结束，后端却按Content-Length继续读取，导致下一个请求被吞并。实际环境中还存在TE.TE混淆，即通过头部混淆让代理和源站对Transfer-Encoding的合法性判断出现分歧。

最直接的检测手段是构造时间延迟请求。以CL.TE为例，发送如下精心设计的请求到目标站点：

POST / HTTP/1.1
Host: target-server.com
Content-Length: 6
Transfer-Encoding: chunked

0

G

前端代理看到Content-Length: 6，认为请求体是“0\r\n\r\nG”，完整转发。后端看到Transfer-Encoding: chunked，解析到“0\r\n\r\n”就认为分块结束，剩下的“G”被留在缓冲区等待下一个请求。紧接着发送一个正常GET请求，后端实际收到的是“GET / HTTP/1.1”，这会导致服务器返回异常响应或超时。如果观察到响应延迟明显增加或返回400错误，基本可以确认存在走私漏洞。TE.CL类型的检测则发送如下请求：

POST / HTTP/1.1
Host: target-server.com
Content-Length: 4
Transfer-Encoding: chunked

5c
GPOST / HTTP/1.1
Content-Length: 15

x=1
0

前端按分块解析，看到“5c”表示接下来92字节的分块数据，完整读取后转发。后端信任Content-Length: 4，只读4个字节，剩下的“GPOST / HTTP/1.1...”被当作下一个请求处理。如果后续正常请求收到异常响应，说明TE.CL走私存在。

手工测试适合单点验证，面对大规模资产排查则需要借助专业工具。Burp Suite的HTTP Request Smuggler插件是目前最成熟的检测方案，它自动发送多种变异请求，通过分析响应时间差异和状态码异常来判定走私类型。使用前需在Burp的Repeater模块中右键选择“Launch Smuggler probe”，插件会依次尝试CL.TE、TE.CL、TE.TE等攻击向量。另外，smuggler.py这类命令行工具更适合集成到CI/CD管道，它可以读取URL列表批量扫描，输出存在风险的端点。检测时务必注意：不要在生产环境的高峰期进行，构造的恶意请求可能污染真实用户会话；建议在预发布环境或业务低峰窗口操作，并且测试后立即清理缓存。

修复请求走私不能依赖应用层补丁，必须从反向代理和源站的HTTP协议解析层面彻底统一。核心原则是：确保前端代理和后端服务器使用完全相同的请求边界判定逻辑，并且尽可能在代理层就完成请求体的规范化处理。具体来说，如果代理和后端都支持HTTP/1.1，应强制两者都只使用Transfer-Encoding: chunked来传输请求体，由代理负责将客户端各种形式的请求体统一转换为标准分块格式再转发给后端。如果后端是旧版HTTP/1.0服务不支持分块，则代理必须严格使用Content-Length，并剥离所有Transfer-Encoding头部。

在Nginx环境下，以下配置项直接关系到走私防护。首先，禁止客户端请求同时携带Content-Length和Transfer-Encoding，Nginx默认会拒绝此类请求并返回400，确保这一行为未被修改。其次，强制代理层处理请求体缓冲：

location / {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_set_header Transfer-Encoding "";
    proxy_request_buffering on;
    client_max_body_size 10m;
    client_body_buffer_size 128k;
}

proxy_http_version 1.1确保代理与后端使用HTTP/1.1通信，支持分块传输。proxy_set_header Connection ""和proxy_set_header Transfer-Encoding ""清空这两个可能引发歧义的头部，由Nginx重新生成标准头部。proxy_request_buffering on强制Nginx完整接收客户端请求体后再转发，杜绝流式转发可能造成的边界模糊。如果后端是HTTP/1.0服务，需要额外配置proxy_set_header Transfer-Encoding ""并确保Nginx自动计算Content-Length，禁止分块传输。

Apache作为反向代理时，mod_proxy模块需要启用请求体缓冲。在虚拟主机配置中添加：

ProxyPreserveHost On
ProxyPass / http://backend/ timeout=30
ProxyPassReverse / http://backend/
SetEnv proxy-sendcl 1
SetEnv proxy-sendchunks 0

proxy-sendcl 1强制Apache使用Content-Length方式转发请求，proxy-sendchunks 0禁用分块传输，两者结合确保代理层采用单一明确的长度声明方式。HAProxy的配置则更为底层，在backend段落中必须明确指定HTTP模式并启用请求体缓冲：

backend web_servers
    mode http
    option http-buffer-request
    http-request deny if { req.hdr_cnt(transfer-encoding) gt 0 } { req.hdr_cnt(content-length) gt 0 }
    server server1 192.168.1.10:80 check

http-request deny规则直接拒绝同时包含Transfer-Encoding和Content-Length的请求，从入口处消灭歧义。option http-buffer-request确保HAProxy完整缓冲请求体后再向后端转发，避免流式处理引入的时序问题。

现代架构中，客户端到代理通常使用HTTP/2，而代理到后端仍使用HTTP/1.1，这个协议转换过程可能引入新的走私变种。HTTP/2本身没有Content-Length和Transfer-Encoding的歧义问题，但代理在将HTTP/2请求降级为HTTP/1.1时，如果对伪头部:authority、:method、:path的处理不规范，可能生成畸形HTTP/1.1请求。例如，攻击者在HTTP/2请求中注入换行符构造的恶意值，降级后可能被解析为额外的请求头部甚至新的请求。修复方法是在代理层严格验证所有HTTP/2伪头部的值，拒绝包含CR、LF字符的请求。Nginx中可以通过以下配置增强校验：

if ($http_authority ~ "[\r\n]") { return 400; }
if ($request_uri ~ "[\r\n]") { return 400; }

同时，确保代理软件版本保持最新，主流反向代理对HTTP/2降级走私的补丁通常会在版本更新中及时合入。

配置修正能堵住已知攻击向量，但协议层面的新变种层出不穷。建立纵深防御体系需要在多个层面布控。网络层，在WAF规则集中启用专门的请求走私检测规则，ModSecurity的CRS规则集已包含相关检测逻辑，规则ID 920000、920001、920002等针对请求头异常进行拦截。应用层，后端服务应实现严格的请求合法性校验，拒绝任何包含异常Transfer-Encoding值的请求，并记录所有400错误日志用于事后分析。监控层，对反向代理的错误日志进行实时聚合分析，如果短时间内出现大量“client sent invalid request”或“upstream sent invalid chunked data”类错误，极有可能是正在遭受走私探测或攻击。

配置修改完成后，必须通过完整的测试用例验证修复效果。第一步，使用之前的手工检测payload重新测试，确认所有延迟和异常响应均已消失。第二步，使用Burp Suite的Smuggler插件进行全量扫描，确保CL.TE、TE.CL、TE.TE三类均无检出。第三步，构造边界测试用例，包括超长Content-Length值、负数Content-Length、Transfer-Encoding头部重复出现、分块大小使用十六进制大写混合等畸形请求，确认代理层统一返回400或直接断开连接，而非透传给后端。第四步，在业务低峰期进行有限度的生产验证，监控后端服务器的访问日志，确认没有出现畸形请求行或异常参数拼接。

HTTP请求走私的防护不是一次性工程。每次反向代理软件升级、后端服务更换、网络架构调整，都可能重新引入解析差异。建议将走私检测用例集成到自动化安全回归测试中，每次变更后自动执行。同时，在反向代理的访问日志中记录请求体的实际长度和代理计算出的Content-Length值，定期离线分析两者的偏差。如果发现代理记录的Content-Length与客户端声明的Content-Length不一致，或者代理检测到分块解析异常，即使没有造成安全事件，也应当作为高危信号立即排查。对于使用CDN或第三方代理服务的场景，务必与供应商确认其HTTP协议解析策略，确保与源站配置严格一致，必要时通过合同条款约束供应商的协议实现标准。