WebFuzzing方法和漏洞案例总结
0x00 前言
WEB应用模糊测试(WEB Fuzz)是一种特殊形式的网络协议模糊测试,专门关注遵循HTTP规范的网络数据包。
在Fuzz请求完成后,目标应用发回来的响应提供了Fuzz请求所造成影响的各种线索。如果发现了异常,就可以确定于异常相关的请求。下面总结了一些响应信息,这些响应信息可能指示漏洞条件的存在:
- HTML状态码
- 响应中的错误信息
- 响应中包含的用户输入
- 性能下降
- 请求超时
- WEB Fuzzer错误信息
- 处理或者未处理的异常
0x01 响应信息详细
- HTML状态码
HTML状态码是一种重要信息,它提供了快速判断对应的请求是成功还是失败的指示。因此,WEB Fuzzer解析原始响应,得到状态码,然后在一个显示响应详细信息的列表中将其单独展示出来。通过THML状态码信息,用户能够快速确定需要进一步详细检查的响应部分。
- 响应中的错误信息
从设计上来说,WEB服务器一般都会在动态生成的网页中包含错误信息。如果一个WEB服务器在生产环节中启动不当,启用了调试功能,就会发生这种情 况。以下是一个典型的透露了太懂信息的例子:当验证错误时,WEB应用给出的错误信息是“密码不正确”而不是“用户或密码不正确”。如果攻击者试图通过暴 力方法强行破解某个WEB应用的登陆密页面,“密码不正确”的错误消息就会告诉攻击者输入的用户名存在,只是密码不正确。这使得未知参数有两个(用户名和 密码)减少为一个(密码),极大地增加了攻击者进入系统的可能。在识别SQL注入攻击时,应用的错误信息同样特别有用。
- 响应中包含的用户输入
如果动态生成的WEB页面包含用户输入的数据,就有可能产生XSS漏洞。WEB应用的设计者应当过滤用户的输入,以确保不会发生这类攻击。但 是,WEB应用没有进行核实的过滤是个常见的问题。因此,如果在HTML响应信息中找到了WEB Fuzzer提供的数据,那就表面应当测试应用中的XSS漏洞。
- 性能下降
尽管通过其表现形式(直接的应用崩溃),我们很容易识别DoS攻击,但DoS漏洞则微妙得多。性能下降通常表明应用可能易于收到Dos攻击。请求超时是一种发现性能下降的方法,但是在Fuzz的过程中,还应当使用血能监视器检查问题,如过高的CPU使用率或内存使用率。
- 请求超时
参考上一条,不能忽视请求超时,因为它们可能表示存在临时或者永久的Dos条件。
- WEB Fuzzer错误信息
WEB Fuzzer有它子的错误处理方式,当某些特定函数执行失败时,它会弹出错误信息。例如,如果目标服务器因为前一个Fuzz请求而线下,WEB Fuzzer可能会给出一个错误信息,表明无法链接到目标服务器。这意味着可能发生了DoS攻击。
- 处理或未被处理的异常
当对WEB应用进行Fuzz时,可能会在应用本身以及它运行的服务器上都发现漏洞。因此,监视服务器多的状态也很重要。尽管WEB服务器返回的响应 信息为我们提供了发现潜在漏洞的信息,但它们并没有揭示全部问题。如果输入稍加变化,Fuzz请求极可能会导致处理或未被处理的异常,从而导致可被利用的 条件。因此,在Fuzz过程中,建议在目标WEB服务器上连接一个单独的调试器,这样就能够识别这些异常,比如FileFuzz和COMRaider,都 带有内置的调试功能。WEB Fuzzer并不需要调试功能呢,因为WEB Fuzzer不需要反复地启动和中止一个应用。我们的方法是向某个Web应用发送一系列的fuzz请求,服务器会持续运行并相应这些请求,并阻止导致 Dos的输入。
0x02 漏洞案例
其中涉及的一些漏洞可能无法作为Fuzzing归类,这里也进行了强行的归类,只是想告诉大家漏洞挖掘中思路发散的重要性,个人也觉得比较经典。
Fuzz针对一部分网站可以扫描的全面,只要你的字典足够强大就可以扫描到绝大多部分的目录和文件,以下是个人和网上搜集和整理的字典库。
个人搜集的字典:

网上搜集的字典:

注: 漏洞案例进行了脱敏以及细节上的修改
- [SQLi注入漏洞]
1.获得项目子域:https://xxx.com
2.目录扫描发现/user/目录,二层探测发现/register接口,其意为:“注册”

3.根据返回状态信息去Fuzz用户名、密码参数->结果:uname\pwd
4.对uname参数进行SQL注入测试,简单的逻辑判断存在
5.注入点使用16进制的方式无法注入,SQLmap参数–no-escape即可绕过

- [拒绝服务]图片验证码
图片验证码DoS(拒绝服务攻击)这个思路很早就出来了,当时的第一想法就是采集样本收集参数,使用搜索引擎寻找存在图片验证码的点:

根据这些点写了个脚本进行半自动的参数收集:

在漏洞挖掘的过程中,经常会抓取图片验证码的请求进行Fuzz:
图片验证码地址:https://xxx/validateCode

Fuzz存在潜藏参数,可控验证码生成大小:

- [JSONP]无中生有
获得一个敏感信息返回的请求端点:http://xxx/getInfo
使用callback_dict.txt字典进行Fuzz

成功发现callback这个潜藏参数

- [逻辑漏洞]响应变请求
这里同样是获得一个敏感信息返回的请求端点:http://xxx/getInfo
返回的信息如下所示:
{“responseData”:{“userid”:”user_id”,”login”:”user_name”,”password”:”user_password”,”mobilenum”:”user_mobilephone_number”,”mobileisbound”:”01”,”email”:”user_email_address”}}
尝试了一些测试思路都无法发现安全漏洞,于是想到了响应变请求思路
将响应报文的JSON字段内容转化为HTTP请求的字段内容(BurpSuite插件项目:https://github.com/gh0stkey/JSONandHTTPP):

将相关的信息字段内容替换为测试账号B的信息(例如:login=A -> login=B)
发现无法得到预期的越权漏洞,并尝试分析该网站其他请求接口对应的参数,发现都为大写,将之前的参数转换为大写

继续Fuzz,结果却出人意料达到了预期

- [逻辑漏洞]命名规律修改
一个登录系统,跟踪JS文件发现了一些登录后的系统接口,找到其中的注册接口成功注册账户进入个人中心,用户管理处抓到如下请求:
POST URL: https://xxx/getRolesByUserId
POST Data: userId=1028
返回如下信息:

可以看见这里的信息并不敏感,但根据测试发现userId参数可以进行越权遍历
根据url判断这个请求的意思是根据用户id查看用户的身份,url中的驼峰方法(getRolesByUserId)惊醒了我,根据命名规则结构我将其修改成getUserByUserId,也就是根据用户id获取用户,也就成为了如下请求包
POST URL: https://xxx/getUserByUserId
POST Data: userId=1028

成功返回了敏感信息,并通过修改userId可以越权获取其他用户的信息
- [逻辑漏洞]敏感的嗅觉
在测一个刚上线的APP时获得这样一条请求:
POST /mvc/h5/jd/mJSFHttpGWP **HTTP/**1.1……
param={“userPin”:”$Uid$”,”addressType”:0}
而这个请求返回的信息较为敏感,返回了个人的一些物理地址信息

在这里param参数是json格式的,其中”userPin”:”$Uid$”引起我注意,敏感的直觉告诉我这里可以进行修改,尝试将$Uid$修改为其他用户的用户名、用户ID,成功越权:

- [逻辑漏洞]熟能生巧
收到一个项目邀请,全篇就一个后台管理系统。针对这个系统做了一些常规的测试之后除了发现一些 没用的弱口令外(无法登录系统的)没有了其他收获。
分析这个后台管理系统的URL:https://xxx/?m=index,该URL访问解析过来 的是主⻚信息。
尝试对请求参数m的值进行Fuzz,7K+的字典进行Fuzz,一段时间之后收获降临

获得了一个有用的请求:?m=view,该请求可以直接未授权获取信息

- [逻辑漏洞]Token限制绕过
在测业务的密码重置功能,发送密码重置请求,邮箱收到一个重置密码的链接:http://xxx/forget/pwd?userid=123&token=xxxx
这时候尝试删除token请求参数,再访问并成功重置了用户的密码:

- [SQLi辅助]参数删除报错
挖掘到一处注入,发现是root(DBA)权限:

但这时候,找不到网站绝对路径,寻找网站用户交互的请求http://xxx/xxxsearch?name=123,删除name=123,网站报错获取绝对路径:

成功通过SQLi漏洞进行GetWebshell
- 字典收集:
BurpCollector(BurpSuite参数收集插件):https://github.com/TEag1e/BurpCollector
Fuzz字典:https://github.com/TheKingOfDuck/fuzzDicts
- 借助平台
1.依靠Github收集:https://github.com/search?q=%22%24\_GET%22&type=Code
2.借助zoomeye、fofa等平台收集
0x03 总结
核心其实还是在于漏洞挖掘时的心细,一件事情理解透彻之后万物皆可Fuzz!
平时注意字典的更新、整理和对实际情况的分析,再进行关联整合。