关于 Web App Fuzz 的一点看法

Fuzz分很多种，有大的是fuzz整个应用，有小的是fuzz个别函数。有的是fuzz 网络协议，有的则是fuzz某个接口。

但总的来说，FUZZ都是填充脏数据，然后捕获异常，最后发现问题的一个过程。

所以，FUZZ有三个关键

1. 如何填充脏数据
2. 如何捕获异常
3. 获取异常后如何回溯执行过程

FUZZ可以算作是黑箱测试的一种，输入提供脏数据，黑箱里经过复杂逻辑运算后，如果输出异常，则开始回溯整个过程。

对于WEB 应用来说，同样也是这个过程。

虽然WEB应用可以分为很多环节，但是整体来说，还是可以看做一个黑箱。所以出现了很多基于HTTP协议的FUZZER，比较典型的是 Acunetix 自带的那个，就属于这类型。

WEB APP FUZZ的难点，有这么几个：
1、如何按照指定流程或者指定的条件进行fuzz
很多WEB应用的流程复杂，在满足条件前，无法成功执行流程。其实所有的fuzzer都会遇到这个问题，不光是web fuzzer

2、如何回溯出整个函数执行过程
如果是程序抛出了异常，能够捕获到，就比较简单。但是更多的时候，程序不会抛出异常。比如fuzz XSS的时候，fuzz成功的特征是程序原样输出了脏数据，这时候程序没有抛出异常，进行栈回溯就相对非常困难了。

3、如何减少没有意义的FUZZ
假设WEB APP使用了MVC，有同学提出能否直接FUZZ 模板（view层）。这个想法我之前也想到过，不过随后被我自己否决掉了。因为模板系统是接受从DB出来的数据，作为模板的输入，模板的输出则是渲染成了HTML。如果只有单独的模板系统要检查，那么这样FUZZ是有意义的，但是问题是WEB APP是一个整体，单方面的用FUZZER去改变进入模板之前的数据反而是没有意义的。

举例，



如果$var是从DB中取出来，其值是 ，是一个常量，或者是前面的程序逻辑已经保证了这里用户无法控制

而针对模板的FUZZER硬要把 $var 改成 javascript:xxx 或者 是 空格 onclick='xxx' ，有意义吗？这样的误报会大量存在。所以直接FUZZ模板是没有意义的。

对于这种整体的WEB APP，还是应该定制输入，然后捕获输出异常，再回溯整个流程。如果 MVC 好的话，回溯的过程会很简单。如果层次划分做的不好，就是一件非常恶心的事情了。比如在fuzz 访问控制问题的时候，如果访问控制是程序员自己写的，回溯就变得非常恶心了。


MS的SDL blog上，曾经有篇文章，讲的是 A Layer of Hurt ，意思是在代码中插一层，进行自动化混淆数据然后fuzz。 这个思路也是值得借鉴的。但是要注意，该文中捕获的 read 函数，实际上完全等价于用户能够控制的输入部分，所以这样fuzz是没有问题的。否则就会出现我上面第三点提到的问题，很多FUZZ数据都变得没有意义了。


今天因为正好和同事讨论到这个问题，所以抛出一点个人见解，也希望和大家交流。