网络安全：HTTP请求走私与CL.TE差异

清欢

发布时间：2026-09-09 | 2人浏览过

原创

理解HTTP请求走私与请求边界

HTTP请求走私（HTTP Request Smuggling）是一种利用前端代理服务器与后端Web服务器对HTTP请求长度和边界解析不一致，从而绕过安全控制或劫持会话的攻击技术。在HTTP/1.1协议中，请求体的结束位置通常由Content-Length（CL）或Transfer-Encoding: chunked（TE）决定。当请求同时包含这两个头部时，RFC规范明确要求优先使用TE，但不同厂商的代理组件与后端应用服务器在实现时可能存在差异。若前端按CL截断请求而忽略TE，后端却按TE解析，攻击者便可构造特殊请求，使前端认为请求已结束并放行，而后端却将后续正常请求的头部或数据误认为是前一个请求的残留体。这种请求粘连会破坏多租户隔离，导致缓存投毒或越权访问。理解该机制的核心在于掌握协议规范与实际组件实现之间的偏差，以及请求边界判定逻辑的脆弱性。

展示代理服务器、负载均衡器与后端Web服务器之间HTTP请求解析不一致的真实抓包或架构界面。 — 展示HTTP请求在前端与后端解析边界不一致时，被拆分并形成隐藏请求的真实技术示意。

对比CL.TE与TE.CL解析差异

请求走私主要分为CL.TE与TE.CL两类典型场景，其核心差异在于前后端对冲突请求头的解析优先级不同。在CL.TE场景中，前端代理优先依据Content-Length计算请求体长度并截断，而忽略Transfer-Encoding；后端服务器则严格遵循RFC规范，优先按Transfer-Encoding: chunked解析。例如，攻击者发送一个包含Content-Length: 4和Transfer-Encoding: chunked的请求，请求体为0\r\n\r\n（表示chunk结束）后紧跟G。前端读取4个字节后认为请求结束，将剩余部分转发给后端；后端却按TE解析，将0\r\n\r\n视为当前请求结束，而将G与下一个请求的头部拼接，形成畸形请求。相比之下，TE.CL则是前端按TE解析、后端按CL解析，导致前端将后续请求吞入当前请求体。CL.TE的危害在于攻击者能精准控制残留字节，更容易实现请求头注入或路由劫持，且因前端按固定长度放行，流量特征更隐蔽。

展示真实HTTP原始请求中Content-Length与Transfer-Encoding同时存在，以及代理和后端采用不同解析规则的对比界面。 — 真实原始HTTP请求同时包含 Content-Length 与 Transfer-Encoding，并在请求末尾携带隐藏请求，直观体现CL.TE差异。

安全验证与识别请求走私

在授权测试环境中识别CL.TE走私，需遵循无害探测、时序观察、逐步验证的原则，严禁直接在生产环境发送恶意拼接请求。首先，使用Burp Suite Repeater构造包含冲突头部的探测请求，例如同时设置Content-Length: 11与Transfer-Encoding: chunked，请求体为0\r\n\r\nX。若存在CL.TE，前端会按CL读取完整请求并转发，后端按TE解析到0\r\n\r\n即结束，将X残留至连接池。随后发送第二个正常请求，若后端将X与GET拼接为XGET，将返回400或404错误，而正常情况应返回200。通过对比两次请求的响应状态码或响应时间差异，可初步判定解析不一致。测试过程中应使用独立测试域名、限制并发数，并避免携带敏感Payload。确认漏洞后，仅记录请求构造逻辑与响应特征，不执行越权或数据篡改操作，确保测试行为符合安全合规要求。

展示Burp Suite等安全测试工具中的HTTP请求编辑器、Repeater或检测结果，用于体现请求边界异常和验证过程。 — 展示通过Burp等工具验证请求走私后产生差异响应（404）的实际测试结果。

修复解析不一致与常见避坑

修复HTTP请求走私的核心在于统一前后端解析规则并消除头部冲突。首先，应在反向代理层强制规范化请求，通过配置丢弃或重写同时包含CL与TE的请求，例如Nginx可启用http2协议规避HTTP/1.1解析缺陷，或通过Lua脚本拦截冲突头部。其次，升级代理组件至最新稳定版，确保其严格遵循RFC 7230规范，对冲突头部直接返回400 Bad Request而非降级处理。需注意，WAF通常基于单请求特征匹配，难以识别跨请求的边界粘连问题，单独依赖WAF防护存在明显盲区，必须结合网关层的协议合规校验。修复验证阶段，应使用自动化脚本重放CL.TE探测序列，确认代理层已拦截冲突请求或后端响应不再出现状态码异常。同时，建立持续集成测试流水线，将请求走私用例纳入回归测试，防止配置回退引入新风险。