Fuzz前思考的七件事（转载）

本文转自https://www.linuxfoundation.org/blog/2016/02/7-things-to-consider-before-fuzzing-a-large-open-source-project/

1. 首先确定您的目标

确定您是否只是在寻找安全性问题，还是在寻找所有类型的正确性问题。Fuzzing发现了许多在正常使用中可能永远不会遇到的低严重性问题。这些可能看起来与安全漏洞完全相同，唯一的区别是没有跨越信任边界。例如，如果您模糊测试了一个只期望输入来自受信任工具的输出的工具，您可能会发现许多在正常使用中永远不会遇到的崩溃。是否有其他方法将造成崩溃的测试样例输入到工具中?如果是这样，您就发现了一个安全漏洞;如果不是这样，那么您就发现了一个可能永远无法修复的低优先级正确性问题。项目是否愿意处理所有发现的问题，或者只处理安全性问题?通过预先设置动态分析的期望，您可以为自己节省大量的时间和挫折。

2. 明确您的信任边界

明确并记录应该在哪里检查错误。对于像我这样的安全专家来说，创建一个强安全性的心理模型是很容易的，在这个模型中，每个函数都防御地检查每个输入。遗憾的是，现实世界要比这复杂得多。这种高度警惕是巨大的浪费，因此在生产中永远无法生存。我们必须更加努力地为项目建立一个正确的安全边界的心理模型。有必要了解在程序控制流中哪些地方应该进行检查，哪些地方可以省略检查。

3.根据接口划分项目

不同的模糊测试器有不同的适用特长。根据接口文件、网络、API将项目划分，使用不同类型的fuzzer将会更加高效。

4. 探索现有的工具

新的模糊化工具一直在开发，而旧的工具正在获得新的功能。重新审视一些最流行的工具，看看它们是否可以帮助您完成项目的一部分。戴维•伯德威尔(David Birdwell)最近将网络模糊测试技术(network fuzzing)加入到美国模糊扶普(Fuzzy Lop)的衍生产品中，值得一看。Hanno Bock写了关于如何在fuzzing项目中使用一些常见的模糊工具的[有用教程]。(https://fuzzing-project.org/tutorials.html)

5编写自己的工具

遇到如何在一个大型混合语言项目上执行动态分析的问题，而这个项目本身又不适合现有的工具时，我求助于David a . Wheeler，看看他会如何处理这个问题。惠勒博士建议，我可以考虑写一个专门针对项目api的模糊测试工具。根据它们生成随机输入，并添加大量至少在模糊期间启用的断言。如果您知道您的API(或者能够内测它)，那么创建一个特定的模糊器是相当容易的，您可以获取随机数生成器，为fireworks设置一个独立的容器或VM，然后就可以开始了。

6. fuzzing真的值得吗?

对模糊化工具的一个常见批评是，在您运行它们一段时间之后，它们就不再寻找bug了。这是一件好事!就像您不会因为发现很少的回归而抛弃自动化测试套件一样，您不应该使用这个基本原理来停止模糊测试您的项目。如果你的fuzzing工具不再寻找bug，恭喜你!是庆祝的时候了!现在，我们来寻找更困难的bug。

7. 听起来有很多工作

要做你真的希望我做这些吗?只要给我一个好工具的名字(AFL)。你不必做所有这些事，至少不必一次做完。如果您找到一个与您的项目一起工作的工具来覆盖项目的一个子集，那么您可以开始运行它。您将最终弄清楚项目开发人员(或您)是否愿意修复低优先级问题，以及项目的信任边界位于何处。您可能会发现一个崩溃，生成一个补丁并提交给项目，但却发现它被拒绝了，因为fuzzer生成的错误输入永远无法到达项目的那个部分，因此添加您的检查太浪费了。无论你采取哪种方法，都要帮那些追随你的人一个忙，并把它写下来。当然，它会过时，但它使阅读变得有趣，并帮助你身后的人站在你的肩膀上。
最后一个提醒，如果你正在模糊别人的项目，你有任何怀疑，你发现了一个安全漏洞，记得使用项目的安全漏洞报告过程!