HTTP请求走私
Posted 番茄酱料
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了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漏洞—响应包差异
第一次发包如上图，接下来进行第二次发包
发现也成功发生请求夹带
以上是关于HTTP请求走私的主要内容，如果未能解决你的问题，请参考以下文章