Fuzz 测试的思路和测试工具有哪些

目前fuzz测试领域最为专业的测试工具是一款叫Mu 协议分析仪的工具，目前在中国只有达信通成科技（北京）有限公司在代理。

协议分析仪就是能够捕获网络报文的设备。协议分析仪的正当用处在于扑捉分析网络的流量,以便找出所关心的网络中潜在的问题。

假设网络的某一段运行得不是很好，报文的发送比较慢,而我们又不知道问题出在什么地方，此时就可以用协议分析仪来作出精确的问题判断。协议分析仪在功能和设计方面有很多不同。有些只能分帆埋析一种协议，而另一些能够分析几百种协议。

扩展资料：

展望协键芹议分析仪已成为数据通信系统设计、建设和管理维护所不可缺少的工具。随着数据通信技术的不断发展，协议分析仪将向三个方向发展。

①增强功能。开发、测试和分析高层协议将是协议分析仪发展的必然趋势。同时，协议分析仪还将逐渐增加协议一致性测试功能，向开放系统互连（OSI）一致性测试方向发展。

②扩大应用范围。协议分析仪除用于各种数据通信系统和广域数据通信网外，有效地应用到局域网（LAN）和综合业务数字网（ISDN）等领域也态亮蚂是一个必然的趋势。

③提高 *** 作的方便程度。采用将模拟功能与编程功能分开；增加显示屏幕的尺寸和提高显示屏幕的清晰度；增加翻译显示等措施，以提高 *** 作的方便程度。

参考资料来源：百度百科-协议分析仪

在日常测试工作中，经常会有api接口的测试，除了正向流程的测试之外，我们经常还需要覆盖一些异常情况。

例如：

事实上，我们组的接口测试demo框架中，在dataprovider中也经常能够看到诸如下面的例子。

此处是看看接口在传入非期望值的时候，能不能够很好的处理类似请求。

除此以外，还有一些和业务场景强相关的值类型，比如网络测试的时候，我们会关心cidr的格式；计费测试的时候，又特别关注数字的类型。

一方面，给每个接口增加类似的异常接口测试相对比较无趣；另一方面，我们作为人，考虑问题，不管是开发还是测试，都难免挂一漏万，有一些边边角角的case没能考虑到。

既然如此，我们能否统一抽象出来一种接口异常测试的框架， 自动 注入各种类型的异常，然后将凡是服务没有捕获的，抛出trace, exception 的，记录下请求的payload，为后续验证覆盖提供支撑。

主要使用了模糊测试技术（fuzz testing, fuzzing）。其核心思想是自动或半贺纤搭自动的生成随机数据输入到一个程序中，并监视程序异常，如崩溃，断言(assertion)失败，以发现可能的程序错误，比如内存泄漏。（摘抄之维基百科）

简单的模糊测试随机输入数据，而更加高效的模糊测试，需要理解对象结构或者协议。通过向数据内容，结构，消息，序列中引入一些异常，来人为的构造聪明的模糊测试。

如果你持续关注文件系统或内核技术，你一定注意过这样一篇文章：Fuzzing filesystem with AFL。Vegard Nossum 和 Quentin Casasnovas 在 2016 年将用户态的 Fuzzing 工具 AFL（American Fuzzing Lop）迁移到内核态，并针对文件系统进行了测试。

结果是相当惊人的。Btrfs，作为 SLES（SUSE Linux Enterprise Server）的默认文件系统，仅在测试中坚持了 5 秒钟就挂了。而 ext4 坚持时间最长，但也仅有 2 个小时而已。( https://zhuanlan.zhihu.com/p/28828826 )

所以基于此，在api接口测试中引入模糊测试理论上也是可行的，而且是有效的。

经过一番调研和搜索之后，发现了以下这个项目在接口fuzz测试中，有比较好的上手体验。

我对 PyJFAPI 稍微进行了一些修改，包括日志记录，以及异常判断的地方，只记录服务器返回500错误的情况等。

首先需要准本一个请求的模板。

这里是一个 post请求，定义了一些请求头和请求体。星号之间的请求json体，为异常注入点。

它会自动分析你的json格式，生成各种 payload。理论上来说，你只需要给它提供一份接口的scheme就行(要是所有接口都可以从Swagger直接导出那就很方便了)。

运行：

返回

我们可以手工请求一下这些导致异常的payload。

实例1：

事实上，我们本来已经对这个cidr参数进行了一些异常值的测试。包括：

等等。可以发现，还是有部分特殊情形没有考虑到。

实例2

我把程序构造的部分异常打印出来，可以看禅拿到类型还是很丰富的。

pjfapi.py 脚本本身使用方法很简单。 -h 看下help为命令行参数的基本说明。

本文简要的介绍了fuzz测试技术，以及将其应用到api接口测试中的实现，给竖消出了一个具体的fuzz接口测试例子。它不一定能够完全替代掉人工的接口异常，但是可以作为一个很好的补充。

在对伍裤源码进行重新编译之后，使用如下命令用AFL对其进行fuzz：

其中， fuzz_in 为输入数据所在文件夹， @@ 表示从文件读取输入。但是这里的输入是在fuzz_in文件夹下，因此命令行写@@，程序会在 ./ 下找输入，找不到自然不会出现正确结果。

下面对界面进行简单的介绍：

process timing

这里展示了当前fuzzer的运行时间、最近一次发现新执行路径的时间、最近一次崩溃的时间、最近一次超时的时间。

值得注意的是第2项，最近一次发现新路径的时间。如果由于目标二进制文件或者命令行参数出错，那么其执行路径应该是一直不变的，所以如果从fuzzing开始一直没有发现新的执行路径，那么就要考虑是否有二进制或者命令行参数错误的问题了。对于此状况，AFL也会智能地进行提醒

overall results

这里包括运行的总周期数、总路径数、崩溃次数、超冲纯时次数。

其中，总周期数可以用来作为何时停止fuzzing的参考。随着不断地fuzzing，周期数会不断增大，其颜色也会由洋红色，逐步变为黄色、蓝色、绿色。一般来说，当其变为绿色时，代表可执行的内容已经很少了，继续fuzzing下去也不会有什么新的发现了。此时，我们便可以通过Ctrl-C，中止当前的fuzzing

stage progress

这里包括正在测试的fuzzing策略、进度、目标的执行总次数、目标的执行速度腔判简

执行速度可以直观地反映当前跑的快不快，如果速度过慢，比如低于500次每秒，那么测试时间就会变得非常漫长。如果发生了这种情况，那么我们需要进一步调整优化我们的fuzzing

要提高AFL测试效率，可以使用并发测试。

查看自己机器CPU cores：

通过afl-whatsup命令查看总体测试情况：

---