首发:云众可信 作者:Key 背景
之前有幸做过一次线下的议题分享《我的Web应用安全模糊测试之路》,讲解了一些常用的WebFuzzing技巧和案例,该议题得到了很大的回响,很多师傅们也与我进行了交流,但考虑到之前分享过很多思路非常不全面,这里以本篇文章作为一次总结,以实战引出技巧思路(方法)。 实战案例
以下分享的案例都是个人在参与项目或私密众测邀请时遇见的真实案例,案例大多基于个人收集和整理的FuzzDict项目(字典库)。 其中涉及的一些漏洞可能无法作为Fuzzing归类,这里也进行了强行的归类,只是想告诉大家漏洞挖掘中思路发散的重要性,个人也觉得比较经典。
注: 漏洞案例进行了脱敏以及细节上的修改
案例-Add
[SQLi注入漏洞]
2.目录扫描发现/user/目录,二层探测发现/register接口,其意为:“注册” 3.根据返回状态信息去Fuzz用户名、密码参数->结果:uname\pwd 4.对uname参数进行SQL注入测试,简单的逻辑判断存在 5.注入点使用16进制的方式无法注入,SQLmap参数--no-escape即可绕过 [拒绝服务]图片验证码
图片验证码DoS(拒绝服务攻击)这个思路很早就出来了,当时的第一想法就是采集样本收集参数,使用搜索引擎寻找存在图片验证码的点: 根据这些点写了个脚本进行半自动的参数收集: 在漏洞挖掘的过程中,经常会抓取图片验证码的请求进行Fuzz: Fuzz存在潜藏参数,可控验证码生成大小: [JSONP]无中生有
使用callback_dict.txt字典进行Fuzz 成功发现callback这个潜藏参数 [逻辑漏洞]响应变请求
返回的信息如下所示: {"responseData":{"userid":"user_id","login":"user_name","password":"user_password","mobilenum":"user_mobilephone_number","mobileisbound":"01","email":"user_email_address"}}尝试了一些测试思路都无法发现安全漏洞,于是想到了响应变请求思路 将相关的信息字段内容替换为测试账号B的信息(例如:login=A -> login=B) 发现无法得到预期的越权漏洞,并尝试分析该网站其他请求接口对应的参数,发现都为大写,将之前的参数转换为大写 继续Fuzz,结果却出人意料达到了预期 案例-Update
[逻辑漏洞]命名规律修改
一个登录系统,跟踪JS文件发现了一些登录后的系统接口,找到其中的注册接口成功注册账户进入个人中心,用户管理处抓到如下请求: POST URL: https://xxx/getRolesByUserIdPOST Data: userId=1028返回如下信息: 成功返回了敏感信息,并通过修改userId可以越权获取其他用户的信息 [逻辑漏洞]敏感的嗅觉
在测一个刚上线的APP时获得这样一条请求: POST /mvc/h5/jd/mJSFHttpGWP HTTP/1.1 …… param={"userPin":"$Uid$","addressType":0}而这个请求返回的信息较为敏感,返回了个人的一些物理地址信息 在这里param参数是json格式的,其中"userPin":"$Uid$"引起我注意,敏感的直觉告诉我这里可以进行修改,尝试将$Uid$修改为其他用户的用户名、用户ID,成功越权: [逻辑漏洞]熟能生巧
收到一个项目邀请,全篇就一个后台管理系统。针对这个系统做了一些常规的测试之后除了发现一些 没用的弱口令外(无法登录系统的)没有了其他收获。 尝试对请求参数m的值进行Fuzz,7K+的字典进行Fuzz,一段时间之后收获降临 获得了一个有用的请求:?m=view,该请求可以直接未授权获取信息 案例-Delete
[逻辑漏洞]Token限制绕过
这时候尝试删除token请求参数,再访问并成功重置了用户的密码: [SQLi辅助]参数删除报错
挖掘到一处注入,发现是root(DBA)权限: 成功通过SQLi漏洞进行GetWebshell 字典收集
项目推荐
注: 以下项目来自“米斯特安全团队”成员编写或整理发布 借助平台
2.借助zoomeye、fofa等平台收集 总结 核心其实还是在于漏洞挖掘时的心细,一件事情理解透彻之后万物皆可Fuzz 平时注意字典的更新、整理和对实际情况的分析,再进行关联整合
|