0%

http请求走私攻击

理论

当服务器使用如cdn、负载等设备时,可能存在前端设备和后端设备对http报文解析方式不同造成的问题。详情见:
https://xz.aliyun.com/t/5978

分析

CL.TE

当cdn设备优先解析Content-length(以下简称CL),后端服务优先解析Tranfor-Encoding(以下简称TE)时,

前端设备转发协议以CL长度为准

upload successful
会将’G’以上的全部转发,但后端设备以TE解释http请求时,会将0\n\n作为报文的结束。

这时G会连接到下一个报文中

upload successful

upload successful

实际上,这种形式用处不大,大概率随机影响别人的请求的响应?

TE.CL

TE.CL顾名思义就是前端设备解析TE,后端设备解析CL,这里可以采用burp的插件生成chunked

chunked格式

chunked的格式其实很简单,一个长度,然后后面跟设定长度的内容,然后再一个长度,再后面跟设定长度的内容,最后0结尾。

upload successful

upload successful

upload successful

梳理一下

TE.CL的形式下,前端解析TE,会将整个包发给后端,后端解析CL,第一个CL到296,之后的POST会作为新的连接响应,则GPOST响应出来。

TE.TE

这个形式,我看很多文章其实没有写到点子上,实际上这种可能性出现的很少,因为存在比较苛刻的条件,他是涉及到前后端解析出现差错导致其变形为TE.CL或CL.TE

例如前端从上到下读header,后端从下到上读header,前端读到第一个Transfer-Encoding: x发现是错误的头停止了,按照CL解析,后端读最后一个Transfer-Encoding: chunked没问题,按照TE解析,辣么就形成了一个CL-TE,如果前后端交换则是TE-CL。其实本质还是前后端解析不一导致的

组合的形式很多不仅仅是这一种形式

1
2
Transfer-Encoding: x
Transfer-Encoding: chunked

很多文章也有梳理。

利用

由于仅仅通过修改请求方法并不能体现危害,并且该漏洞这样使用是没有屌用的,根据文章的描写,该漏洞可以配合别的漏洞和现象使用造成特殊的效果。

思考后发现CL.TE很难有所利用,因为后端以TE作为解析依据,在使用的时候TE很难精确的定位报文结束位置,也就无法拼接下一个报文去利用,故一般考虑TE.CL型的利用

以反射型参数为例

upload successful

upload successful

就是把其他用户的下一个http请求拼接在了我们的请求的参数后,实现了直接从服务器侧面获取用户cookie

总结

更多利用方式可以参考原文,这里主要是对一些细节进行梳理。

黑盒测试目标主要以采用了cdn、云waf的网站等。目标基数应该还蛮大。

burp的靶场在这

https://portswigger.net/web-security/request-smuggling