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）：