之前在做roarctf第一个web时候读到过关于php解析漏洞的文章。
https://www.freebuf.com/articles/web/213359.html
但是用的是在num参数前面构造一个%20来绕过waf。
但是后来看群里有个师傅提起了http走私协议。于是就去学习了一下。
HTTP走私原理:
HTTP请求走私漏洞的原因是由于HTTP规范提供了两种不同方式来指定请求的结束位置,它们是Content-Length标头和Transfer-Encoding标头,Content-Length标头简单明了,它以字节为单位指定消息内容体的长度。
Transfer-Encoding标头用于指定消息体使用分块编码(ChunkedEncode),也就是说消息报文由一个或多个数据块组成,每个数据块大小以字节为单位(十六进制表示) 衡量,后跟换行符,然后是块内容,最重要的是:整个消息体以大小为0的块结束,也就是说解析遇到0数据块就结束。
相当于我发送请求,包含Content-Length,前端服务器解析后没有问题发送给后端服务器,但是我在请求时后面还包含了Transfer-Encoding,这样后端服务器进行解析便可执行我写在下面的一些命令,这样便可以绕过前端的waf。
走私的四种方法:
CL不为0时
这种情况一般发生在get请求下,当前端允许content-length,后端不允许时,此时后端服务器就不会解析content-length,这样就可能绕过waf。
CL-CL型
这种利用的前提条件是服务器不会返回400错误。但是前端服务器按照第一个Content-Length的值对请求进行处理,而后端源站服务器按照第二个Content-Length的值进行处理,这样便有可能引发请求走私。比如出现下面这种情况时:
Content-Length:68 Content-Length:5 num=1GET /calc.php?num=1 HTTP/1.1
前端先解析第一个cl为68,就会把下面的“num=1GET/calc.php?num=1 HTTP/1.1”都当做请求的内容。但是后端会解析第二个cl,也就是说后端只解析“num=1” 后面的请求体就作为下次请求的请求头(前提是Connection:keep-alive)。这样就会引发走私。
CL-TE
就是当收到存在两个请求头的请求包时,前端代理服务器只处理Content-Length这一请求头,而后端服务器会忽略掉Content-Length,处理Transfer-Encoding这一请求头。
Content-Length:123 Transfer-Encoding: chunked
这里的chunked对请求内容进行分块编码,并且直到有rn的时候才结束。
TE-CL
所谓TE-CL,就是当收到存在两个请求头的请求包时,前端代理服务器处理Transfer-Encoding这一请求头,而后端服务器处理Content-Length请求头。
在calc的题目中:
<?php error_reporting(0); if(!isset($_GET['num'])){ show_source(__FILE__); }else{ $str =$_GET['num']; $blacklist= [' ', 't', 'r', 'n',''', '"', '`', '[', ']','$','\','^']; foreach($blacklist as $blackitem) { if(preg_match('/' . $blackitem . '/m', $str)) { die("what are you want to do?"); } } eval('echo'.$str.';'); } ?>
这里后端对特殊符号做了一些过滤,而且除了这个过滤,还有waf拦截字符串的输入。然后就想利用http走私来绕过。
因为这里是get请求,而content-length是在post才会有用,所以这里跟cl其实关系不大,但是利用起来也不会报错。
这里我最开始就是想用cl和chunked结合起来去绕过。
这里的cl设置多少都无所谓,只要设置了chunked,并且最后由rn那么就能成功执行,如果没有rn那么就会一直waiting。
于是我想着能不能重新构造一个请求头来试试:
这里第一个请求头那一定得是keep-alive,然后设置content-length为5。目的是让tcp能够持续响应,而且这里服务器会因为cl为5只识别num=1,后面的一大串就被安排到了下一轮的请求里。(最后的chunked后面还是得跟两次rn来控制块)
说到这里,感觉这道题其实没怎么利用到http走私,主要还是用分块传输chunked方法来绕过waf。但是毕竟也是通过这个点学习了http走私的知识,所以就记录下来。
如果各位有看到不对的地方,还请斧正!
本文作者:星盟安全团队
本文为安全脉搏专栏作者发布,转载请注明:https://www.secpulse.com/archives/118622.html