刚暑假实习回到学校,发现自己的确没有实战经验,于是想着去挖挖src获取经验。前两天突发奇想--国内好多站用扫描器都会封ip,国外的会不会呢?抱着这样的心态,便打开了xray,在hackerone上顺便找了一个src(星巴克),开始扫描。本菜鸟只能惊叹xray是真的NB,出去吃个饭回来,一看结果:
于是乎进行漏洞测试,自己太菜,请教了学长才绕过网站过滤,然后学长问我有没有学过走私,可以试一下走私。???我一头的问号。于是开始了请求走私的一波学习
早在2005年时, Watchfire就已经发现这个漏洞。危害程度:重要!不过,HTTP 走私技术要求对处理 HTTP 消息的各种代理相当熟悉,否则无法发动这种攻击。接下来我们一起了走进请求走私世界
自HTTP / 1.1以来,广泛支持通过单个底层TCP或SSL / TLS套接字发送多个HTTP请求。该协议只需将HTTP请求背靠背放置,服务器就会解析标头,以确定每个请求的结束位置和下一个开始的位置。在默认情况下,HTTP协议中每个传输层只能承载一个HTTP请求和响应,浏览器收到上一个请求响应后,才开始下一个请求。这种多层体系结构接收来自多个不同用户的HTTP请求,并通过单个TCP / TLS连接进行路由:
这就意味着,在很短的时间里,前后端请求信息要求一致是很重要的。否则,攻击者可能发送一条含糊不清的消息,对HTTP请求进行污染,该信息就会被后端解释为两个不同的HTTP请求:
这使攻击者能够在下一个合法用户请求开始时预先添加任意内容。在本文中,被走私的内容将被称为“前缀”,并以橙色突出显示。
接下来用几个实例来说明HTTP走私攻击
POST / HTTP/1.1 Host: vulnerable-website.com Content-Length: 13 Transfer-Encoding: chunked 0 SMUGGLED
前端服务器处理Content-Length头并确定请求主体长度为13个字节,直到SMUGGLED结束。此请求将转发到后端服务器。
后端服务器处理Transfer-Encoding标头,因此将消息体视为使用分块编码。它处理第一个块,它被称为零长度,因此被视为终止请求。以下字节SMUGGLED未经处理,后端服务器将这些字节视为序列中下一个请求的开始。
接下来看一个例子:
初始请求:
更改请求:
- 把GET请求改为POST请求
- 添加Content-Length头以及POST请求数据
更改完后,对数据包连续请求两次:
Host: vulnerable-website.com Content-Length: 3 Transfer-Encoding: chunked 8 SMUGGLED 0
前端服务器处理Transfer-Encoding头,因此将消息体视为使用分块编码,处理第一块时,有八个字节,直到SMUGGLED到最后一个字节。开始处理第二个块,第二块是0个字节,视为终止请求。此时把请求转发到后端
接下来看一个例子:
初始请求:
更改请求:
- 改为POST请求
- 把Repeater的Update Content-length关掉
- 添加Content-length和Transfer-Encoding
- 根据上面的解释进行传递POST数据
S.P: 0后面一定要多加两个\r\n
更改完后,对数据包连续请求两次:
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规范的细微偏离。实现协议规范的实际代码难以十分精准体现,并且不同的实现通常包含不同变化。要发现TE.TE漏洞,有必要找到Transfer-Encoding标头的一些变体,以便只有一个前端或后端服务器处理它,而另一个服务器忽略它。
接下来看一个例子:
初始请求:
更改请求包:
- GET改为POST
- 把Repeater的Update Content-length关掉
- 添加多个Transfer-Encoding
S.P: 0后面一定要多加两个\r\n
更改完后,对数据包连续请求两次:
https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn