注册
登录
| 关键词： 漏洞 HTTP 测试 参数 验证 URL CRLF 34 数值 |
前言：漏洞挖掘和工作中的产品测试过程中除了白盒代码审计之外比较偏向黑盒测试/漏洞挖掘，那么我觉得漏洞挖掘/黑盒测试过程中的遇到过的一些fuzz技术思想有必要借用我遇到过的实战中的例子来归纳总结下，通过实例对fuzz的思想进行展开。 一.登陆1）验证码 图片验证码1 ->拒绝服务攻击 -》Fuzz存在潜藏参数，可控验证码生成大小：如存在验证码生成包中存在height、width、length等参数且能够被我们控制那么就可能进行拒绝服务攻击   图片验证码2->删除验证码参数bypass验证 手机验证码1->爆破 手机验证码2->短信轰炸 【发送次数bypass】: 0x1:fuzzing phone参数,如在手机号中添加空格、问号等等特殊字符进行intruder fuzz 0x2:若请求参数中存在次数参数尝试更改其值 2）用户名枚举 若测试中回显信息出现用户名不存在、或者回显code与正确的code不同时则可能存在用户名枚举  3）弱口令 4）密码重置 账户account、手机号、验证码未严格绑定导致任意用户密码重置与注册 二.逻辑漏洞[敏感信息泄露] （接口参数fuzz+骆驼命名法） 原本是一个如下一个根据个人信息显示订单的请求数据包 返回的一个正常的个人订单信息。然而我将post的内容删除后，请求接口上继续Fuzz参数并配合驼峰命名规则 最终得到大量订单信息的泄露  [逻辑漏洞-越权1] （参数值替换） 将相关的信息字段内容替换为测试账号B的信息（例如：login=A-> login=B 、userid=A->userid=B）  [逻辑漏洞-越权2] （参数值枚举） 对于以上情况在不知道账户2的id或不想另注册测试账户时用到另一种暴力而简便方法，可能大家都知道intruder.   [逻辑漏洞-IDOR] （IDOR-不安全的直接对象引用） IDOR或许和越权有点像，在测试越权修改user_id时也许经常会看到401未认证或用户未授权，大多少人会和我之前的我一样结束这样一个越权测试，认为目标系统不存在越权漏洞。 但在正是了解和接触IDOR之后测试面才会不断发散扩展。 IDOR漏洞不仅限于参数数值更改，它还包括参数数值删除，以及其他与个人信息相关的字段替换以及HTTP污染等。 》举例 假如请求中存在以下参数 1）替换请求中的userid 经常会出现 A B C 2）删除请求中对应的token/user_hash 保留userid,将与其对应的token/user_hash参数值删除 ,原例A->B 3)删除userid及对应user_hash 返回结果如B 但是最后当将userid、user_hash、anmousid都删除只保留email和content时却认证成功返回了数据。 对于C中情况测试还存在一个IDOR的Bypass，HTTP参数污染。  如图一个资产可能存在多种服务或程序，他们的请求或处理或参数解析方面可能存在不同，即平常所说的解析差异。 那么我们可以发送一个数值参数来造成WEB应用后端的解析混乱，当我们发送多个数值参数又会如何？ 那么我们可以发送具备不同数值的同名参数去混乱Web后端解析机制，通过这种攻击来（HTTP参数污染-HPP）实现我们的IDOR Bypass。 由于测试中未遇到过此bypass漏洞，这里借用大佬的一张图作为例子  具体可参考https://www.freebuf.com/vuls/216774.html [回显伪造] （本地验证） 当回显error时替换换为正确的回显内容，绕过验证 1）获取验证码后任意输入一个验证码。  2）抓包放行，得到的返回包如下  3）抓包改返回包修改为正确的返回包覆盖错误的返回包，如下 {“code”:1,”data”:”目标用户手机号”,”msg”:”绑定成功”}  4）放行，修改成功  漏洞本质：服务端没有对用户的上一步操作进行验证 [逻辑漏洞-越权] js信息接口fuzz 当遇到一个只有登陆框的网站时，我们能得到的信息少之又少时，查看源码fuzz网站的js信息能得到意想不到的收获，如隐藏的域名和接口。 1）敏感接口  一般可能出现越权或未授权漏洞 2）隐藏域名 我在挖掘末src某网站xxx.cn时，一番努力之后发现并无所获，而这时通过查看源码，意外的发现一个特殊的域名**bbs.abc.com **,我在其后面加上admin之后意外的跳转到了https://bbs.abc.com/admin/#/home/dashboard 后台，该bbs.abc.com为xxx.cn开发人员的一个测试网站存在着大量后台接口越权。   XXE-Fuzzing 对于xxe的测试，是当一个数据包的中出现 即对XML文件进行解析的场景中，都有可能出现XXE注入，如提交时，还有在上传中文件类型指定了excel、or word那么都可以进行Fuzz测试。 CGRF-Fuzzing 普通的过一下，常见的：token、referer是否严格验证 bypass a:删除token参数 b:空referer绕过、referer验证不严绕过（只匹配关键部分如链接前半部分是否包含域名关键字、链接是否存在域名关键字等） c:referer携带token，token劫持 读取型CSRF 1)jsonp 劫持  POC 2)cors ->crossdomain.xml->flash 若测试某资产时发现存在crossdomain.xml,并且内容如下： 则存在swf的跨域的读取CSRF 3)CORS跨域资源请求 在请求的时候加上了请求头 Origin: http://xxx.com，而对应的响应包中出现了`Access-Control-Allow-Origin: http://vul.com这个响应头其实就是访问控制允许，在这里是允许http://vul.cm的请求的，所以目标http://vul.com是可以被跨域读取该网址的内容 [SSRF-or-URL跳转漏洞ext-Fuzzing] 资产测试时可能存在这样的URL: 对于如上这样的GET型的链接Fuzz的点有什么呢？ SSRF、url跳转，结束了吗? ext扩展发散一下其实还有，只是平常利用的比较少或比较少想到在一次机缘巧合刚好想到也刚好遇上了，继续fuzzing下，其实还可以考虑CRLF，url_redict+CRLF、CRLF+XSS。 对于SSRF 测试 根据回显内容和状态即可确定漏洞是否存在。 协议利用 协议限制为http下向服务端提交302.php 辅助脚本302.php—-bypass http协议限制 测试完SSRF后发现没有该漏洞~   转入URL跳转测试   结束了么？没有，那么是否还存在其他利用方式呢？ 往下测试之前，我们先来看看URL跳转以及CRLF的原理. 插叙 CRLF 指的是回车符(CR，ASCII 13，r，%0d) 和换行符(LF，ASCII 10，n，%0a)。 正常的一个请求 抓包，在请求行的url参数中加入特殊构造的CRLF字符 如下 输出 这样一个CRLF对应的服务端的代码可能是这样子的 代码的意思是当条件满足时，将请求包中的url参数值拼接到Location字符串中，并设置成响应头发送给客户端。 假设存在CRLF漏洞，响应包此时应该 会出现如下情况 最终构造的Set-Cookie字符 会出现在HTTP头部的Cookie中且vuale=crlf会被设置成Cookie携带在Cookie中。最终的数据包会如下： 了解CRLF的服务端的代码原理后，可以知道本质还是在代码中的Location,这与url（302）跳转类似，因此在存在url跳转的情况下还可以尝试Fuzz,转为url跳转->CRLF->CRLF+XSS的利用 CRLF+XSS,payload可以更改为 会变成-> 若同时存在url跳转，payload可以变换一下,CRLF+XSS 那么 最后简单说下黑盒测试 中的漏洞利用链的Fuzz思路 在白盒代码审计中存在者多种的漏洞利用POP链如TP5-6的POP链曾被大多数人所发掘分析 而在黑盒测试审计中其实也存在可以利用漏洞链的思想。 如对于功能及其组件的测试、就单纯的代码审计的情况下比较难发现其漏洞，一个压缩包上传代码中严格限制了其文件类型但会回显其上传的路径 而 在另外一处备份恢复时首先会默认对其文件进行解压，若抓包中解压的路径可控，将两者组合利用就可进行木马上传和RCE。在fuzz中找各功能组件之间的关联性。 三.总结在漏洞挖掘中，Fuzz中每一个漏洞都可能存在多样的利用方式和可能性如常见的命令执行就可能出现在涉及后端操作的一些系统操作：扫描、节点查询、端口占用查询、文件删除等功能点 在黑盒测试漏洞挖掘中需要我们对每一个参数和漏洞点保持着善于发现和挖掘的思想或许会存在意外的收获 同时又需要我们对每一个功能点考虑后端可能的操作及可能涉及的代码开发及其原理，这样在漏洞挖掘中才会更加的高效。 我们才能够不断不断的前行去成长~
转载注明自：http://qclover.cn/2019/11/17/%E6%BC%8F%E6%B4%9E%E6%8C%96%E6%8E%98%E4%B9%8BWEB%E9%BB%91%E7%9B%92%E6%B5%8B%E8%AF%95.html |
| 本文出处： https://www.toutiao.com/a6778655468127519243/ |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
