网站漏洞防护之HTTP请求走私拦截

HTTP请求走私（HTTP Request Smuggling）本质上是一种利用前端代理或负载均衡器与后端服务器之间，对HTTP请求边界解析不一致所引发的严重安全漏洞。攻击者通过构造一个模棱两可的请求，使得前端服务器认为这是一个完整的请求，而后端服务器却将其解析为两个独立的请求，其中第二个“走私”的请求会被附加到下一个正常用户的请求之前。这直接导致了缓存投毒、会话劫持、绕过WAF防护以及未授权访问等高危风险。要彻底拦截这种攻击，不能仅靠单一的规则匹配，必须从协议解析的根本差异点入手，实施多维度的阻断策略。

拦截HTTP请求走私，首先必须理解它为何能绕过常规检测。HTTP规范定义了两种确定请求体长度的方式：Content-Length（CL）头和Transfer-Encoding（TE）头。当一份请求同时包含这两个头，或者包含格式错误的Transfer-Encoding值时，不同服务器实现会产生分歧。例如，前端使用Content-Length认为请求体只有6个字节，而后端基于Transfer-Encoding: chunked解析，将后续数据视为下一个请求的开头。这种解析差异是走私攻击的温床，常见的变种包括CL.TE、TE.CL以及TE.TE三种模式。拦截策略的核心就是消除这种歧义，强制前后端采用统一且严格的解析标准。

最有效的拦截发生在流量入口的代理层。不要试图去“理解”或者“修复”一个恶意请求，最稳妥的做法是直接拒绝任何存在歧义的请求。部署在边缘的负载均衡器或反向代理必须配置为严格遵守HTTP规范。具体操作上，如果系统架构中后端服务器默认使用Content-Length，那么前端代理应配置为直接丢弃任何同时包含Content-Length和Transfer-Encoding头的请求。如果业务必须支持分块传输，则必须确保Transfer-Encoding头的值严格为chunked，拒绝任何包含空格、大小写混淆或畸形字符的Transfer-Encoding头，例如Transfer-Encoding : chunked或Transfer-Encoding: xchunked等变体。这种基于白名单的协议校验，能在攻击者试探解析差异的第一时间就阻断连接。

虽然协议规范化能拦截大部分变异，但高级攻击者会利用前端与后端对分块编码解析的细微差异进行TE.TE攻击，比如在Transfer-Encoding头中插入微小的混淆字符，使得前端忽略该头而后端正常解析。针对这种情况，Web应用防火墙需要部署专门的走私检测规则集。核心逻辑是检查请求体中是否隐藏了第二个HTTP请求的原始数据。WAF引擎应当对请求体进行解码和规范化处理，扫描是否存在内嵌的HTTP动词如GET、POST，或者完整的HTTP请求行。一旦在请求体中发现0x0d 0x0a 0x0d 0x0a这样的双CRLF序列，且其后跟随了类似HTTP方法的数据，应立即判定为走私攻击并阻断。此外，对于Content-Length数值与实际接收到的请求体大小不一致的情况，WAF应具备自动修正或直接断链的能力，防止后端被伪造的长度值欺骗。

HTTP请求走私攻击之所以能污染其他用户的请求，根源在于前端代理与后端服务器之间为了性能而建立的持久连接复用机制。攻击者发送的恶意请求残留会被下一个无辜用户的正常请求前缀所捕获。因此，在极其敏感的业务场景下，通过架构调整切断攻击链条是最彻底的防御手段。如果业务允许，可以在代理层配置强制关闭与后端之间的Keep-Alive连接，即每个客户端请求都对应一个全新的后端连接。虽然这会增加一定的TCP握手开销，但能完全杜绝跨请求污染。对于现代高并发系统，更优雅的做法是在代理层实现严格的连接状态监控，一旦某个后端连接处理过包含异常Transfer-Encoding或返回了非标准状态码的请求，立即主动关闭该连接，避免其被复用。

现代架构中，客户端到代理通常使用HTTP/2，而代理到后端可能降级为HTTP/1.1。这种协议转换过程引入了新的走私风险，即HTTP/2降级走私。攻击者利用HTTP/2帧的伪头与HTTP/1.1请求头的映射缺陷，注入被禁止的头部或伪造Content-Length。拦截此类攻击的关键在于代理层的转换逻辑必须极度严谨。在将HTTP/2请求转换为HTTP/1.1时，绝对禁止将HTTP/2的伪头如:method、:path直接作为普通头部转发。同时，对于HTTP/2中不存在的Content-Length头，如果在转换过程中由代理自动计算生成，必须确保该值不可被用户通过帧数据篡改。更严格的策略是，在降级转发时，如果发现转换后的HTTP/1.1请求中出现了两个Content-Length头，或者Content-Length与Transfer-Encoding共存，应视为协议转换错误，直接丢弃该请求并记录告警。

在Nginx反向代理层实施拦截，核心配置示例如下。这段配置直接拒绝了包含歧义传输特征的请求，并严格限制了分块传输的格式。

# 拒绝同时包含 Content-Length 和 Transfer-Encoding 的请求
if ($http_content_length ~ .) {
    set $cl_exists 1;
}
if ($http_transfer_encoding ~ .) {
    set $te_exists 1;
}
if ($cl_exists = 1) {
    if ($te_exists = 1) {
        return 400; # 直接返回400 Bad Request
    }
}

# 严格校验 Transfer-Encoding 的值，仅允许确切的 "chunked"
if ($http_transfer_encoding !~* ^chunked$) {
    if ($http_transfer_encoding ~ .) {
        return 400;
    }
}

# 在后端连接层面，限制复用并主动清理异常连接
proxy_set_header Connection "";
proxy_http_version 1.1;
# 强制每次请求后关闭后端连接，彻底杜绝污染（性能敏感系统可结合 upstream keepalive 精细控制）
# proxy_set_header Connection "close"; 

上述配置通过变量检测实现了逻辑判断，虽然Nginx的if语句在常规重写中需谨慎使用，但在安全拦截场景下，这种直接返回状态码的方式是稳定且高效的。对于使用了ModSecurity的WAF环境，可以加载专门的走私检测规则，例如检测请求体中是否包含未经编码的HTTP请求行特征。

即使部署了严格的协议校验，仍可能存在未知的解析绕过手法，尤其是在复杂的微服务网格中，不同语言编写的服务对HTTP解析器的实现千差万别。此时，拦截不能仅依赖特征匹配，还需引入行为分析。安全运营团队应监控后端服务的异常响应模式。例如，如果监控系统发现某个后端应用突然开始对大量正常请求返回“400 Bad Request”或“501 Not Implemented”，且这些请求的原始路径看起来正常，这极有可能是走私攻击导致请求前缀被污染，使得后端无法识别被拼接后的畸形URL。建立这种基于异常流量基线的告警模型，能够发现那些绕过静态规则的高级走私攻击。一旦确认攻击源IP或会话特征，可以在前端网络层进行动态封禁。

安全防御讲究纵深，后端应用程序自身也应具备一定的抗走私能力。开发人员应避免在业务代码中直接操作原始Socket流进行HTTP解析，而是依赖经过安全审计的成熟HTTP框架。同时，应用程序服务器如Tomcat、Gunicorn或uWSGI的配置需要检查。确保应用服务器严格拒绝包含非法字符的HTTP头，并设置合理的请求超时时间。如果应用服务器接收到的请求体大小与声明的Content-Length不一致，应直接抛出异常而非尝试读取不完整的数据流。这种在后端服务层的严格校验，是拦截走私攻击的最后一道关卡，能有效防止前端代理漏过的畸形请求对业务逻辑造成破坏。

要彻底拦截HTTP请求走私，必须按照优先级分层实施：第一优先级是协议规范化，在入口处拒绝歧义请求，这是成本最低、效果最直接的方案；第二优先级是WAF深度检测，针对分块编码的载荷进行内容扫描，阻断内嵌的走私请求；第三优先级是架构加固，通过控制连接复用策略或升级全链路HTTP/2来消除降级解析差异；第四优先级是持续监控，通过后端异常状态码的波动来反推前端拦截策略的盲区。HTTP请求走私的拦截不是一次性的规则部署，而是一个随着协议演进和攻击手法变化而持续对抗的过程，只有深入理解HTTP解析的底层逻辑，才能在防御体系中占据主动。