HTTP请求走私

一.前提

需要有两台服务器，一台cdn缓存服务器，一台真实服务器，cdn和服务器之间相当于代理关系。

二.原理

利用HTTP请求的请求体的两种判断：
1.利用Content-Length字段来判断请求体的内容长度
2.利用Transfer-Encoding字段来判定请求体的结束位置
不同的服务器分割请求的标准不一样。对同一段tcp内容，前后端服务器获取到的http请求个数不一致，就导致了请求走私
这里简单介绍一下CL和TE的作用:
CL：请求体的长度就是CL的值
TE：分块传输的标志，以0\r\n\r\n代表分块结束（也就是0换行两次）

三.分析

CL-TE

靶场地址：https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te
1.进入靶场抓包并放到repeater中

2.将此选项关闭，为了不影响后续CL的值

截图已经关闭
3.将包改为POST请求


4.接下来我们就可以构造恶意数据了
修改Content-Length的值并且增加TE，修改如下图：

上图是我们修改后已经发送的一次请求
接下来发送第二次请求，

可以看到结果正是我们想要的结果。
分析：因为是CL-TE的请求方式，因此前端为CL，后端服务器为TE，CL长度设定为7，长度计算是这样的：从第一个字母开始算第一个，每次换行时都会有一个\r\n，那么这就是两个字节，那么我们的7是这样的形式：0\r\n\r\nhd，那么前端以CL请求头时，数据包是除了最后一个h没有前面的都有的，但是后端是TE请求头，它会按照0\r\n\r\n为结尾，那么，他将hd截掉了，在本次请求包中没有，那么当再次发送请求时，将会出现在第二次请求的开头。
照上面的思路走，我们将CL改为8出现的结果将会是HDHPOST，那么继续试验：
第一次请求：

第二次请求：

跟预料的结果一样

TE-CL

靶场地址：https://portswigger.net/web-security/request-smuggling/lab-basic-te-cl
1.还是将数据包放入repeater，并转为post，如下图

2.构造恶意数据
修改Content-Length的值并且构造出第二次我们的请求包，修改如下图：

上图是我们修改后已经发送的一次请求
接下来发送第二次请求，

出现了我们想要的结果
分析：因为是TE-CL的请求方式，因此前端为TE，后端服务器为CL，前端根据TE会取到0，那么数据包中有所有的POST请求，但到达后端后，后端采用CL，那么只会取4字节：5c\r\n，那么第一次请求将会截掉GPOST之后的，第二次请求时将会出现在开头。

TE-TE

靶场地址：https://portswigger.net/web-security/request-smuggling/lab-obfuscating-te-header
1.还是将数据包放入repeater，并转为post，如下图

2.构造恶意数据

上图是我们修改后已经发送的一次请求
接下来发送第二次请求，

分析：前端和后端服务器都采用TE,可以通过混淆TE头的方式来使得其中一个服务器不使用TE头的处理方式。转而进行CL解析，演变成CL.TE或TE.CL漏洞的形式。
常用混淆格式：

CL-CL

根据RFC7230的规范中，服务器接收两个Content-Length且两者值不同时，需要返回400错误，如果服务器不遵守规范，前端服务器读取第一个CL，而后端服务器读取了第二个CL，便造成了走私

POST / HTTP/1.1
Host:xxx.com
Content-Length:5
Content-Length:4
hello

余下的’o’被当成正常请求拼接到下一个请求中

CL!=0

CL不为0，当前端服务器允许GET请求携带请求体，而后端请求体不允许携带请求体，后端会忽略掉GET请求中的Content-Length头，可能会导致请求走私。

GET /HTTP/1.1
Host:xxx.com
Content-Length:33

GET /HTTP/1.1
Host:xxx.com

由于Pipeline存在，后端服务器忽略了CL后，可能会认为受到了两个数据包。

四.漏洞检测技术

1.延时技术—CL.TE漏洞

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 4
 
1
A
X

当前端服务器使用头且规定了CL的长度时，它仅仅会转发请求中的部分内容，X除外。而后端服务器使用Transfer-Encoding分块传输方式，它会接受到第一个分块数据 1\r\nA，但未遇到结束符0，继续等待直至响应超时

2.延时技术—TE.CL漏洞

POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 6
 
0
 
X

当前端服务器使用Transfer-Encoding头，在处理第一个分块的时候就遇到了0，结束解析，将数据包发送到后端服务器，X除外。而后端服务器使用Content-Length的方式，它会继续等待6个字节长度的数据直至响应超时。

3.CL.TE漏洞—响应包差异

第一次发包如上图，接下来进行第二次发包

发现成功发生请求夹带

4.TE.CL漏洞—响应包差异

第一次发包如上图，接下来进行第二次发包

发现也成功发生请求夹带