模糊测试是一种不安全的测试方法(api模糊测试)

模糊测试是指通过向目标系统提供意外输入并监控异常结果来发现软件漏洞的方法。经过近20年的发展，它已经成为程序员界主流的漏洞挖掘技术。基于此，开发人员应该如何编写好模糊测试代码？

作者|约翰雷格尔

译者|新月，编辑|由旺旺流行摇滚出品/p | CSDN (ID: csdnnews)

以下是翻译：

模糊化是发现漏洞和其他软件缺陷的有力手段，但开发人员通常使用这种方法来深入发现部署代码中的问题。其实我们应该尽快完成模糊测试，开发人员应该花一些时间编写更容易进行模糊测试的代码。

在这篇文章中，我想介绍一些方法来告诉你如何为模糊测试编写更方便的代码。然而，这些方法并不全面，它们之间可能有重叠。在本文中，我将使用“fuzzier”来指代所有类型的随机测试用例生成器，无论它们是基于突变的(afl、libFuzzer等)。)或生成的(jsfunfuzz、Csmith等)。)发电机。注意，本文提出的建议并非适用于所有情况，但很多都是合理的软件工程建议。我将用粗体标出我认为特别重要的几点。

努力测试预测。

测试oracle确定测试用例是否会触发错误。默认情况下，模糊设备(如afl)可以使用的唯一预测是操作系统的页面保护机制。换句话说，它只能检测系统崩溃。但我们能做的远不止这些。

编译器插入的断言和消毒检查是另一种类型的预测。在模糊测试中，您应该尽可能多地使用这种类型的检查。除了这些简单的预测，还有许多其他的预测，例如：

函数与反函数：分析与输出的闭环、压缩与解压缩的闭环、加密与解密的闭环等类似代码是否会如预期的那样工作？

区别：两个不同的实现或者同一个实现的两种不同模式表现出相同的行为吗？

变形：如果在保证语义的情况下修改测试用例，系统会显示行为吗，比如在表达式中增加另一层括号？

资源：系统在处理输入时消耗的时间和内存是否合理？

具体领域：例如，图像质量因压缩而受损的图像在视觉上是否与未压缩的图像一致？

构建强大的预测值得我们花费时间和精力，因为它们经常可以发现应用程序级的逻辑错误，通常我们只能通过寻找数组越界来捕捉低级错误。

几年前，我写过一篇关于这个话题的文章(https://blog . rege HR . org/archives/856)。一位推特用户建议：“当测试解析器时，你必须检查它返回的对象，而不仅仅是这个动作的执行。”这是一个好建议。

干预输入/输出和状态

无状态代码更便于模糊测试。但是除此之外，你还需要API来控制状态和干预I/O，比如程序需要从操作系统获取内核数量、当前日期或者剩余磁盘空间量等信息，那么你就应该提供一个方法来设置这些值，并写入文档中。我并不是说我们需要随时改变内核数量，而是说我们可能会在单核模式下对代码进行一次模糊测试，然后需要在128核模式下再进行一次模糊测试。一些控制状态和I/O的方法非常重要，比如简化复位状态(支持持久模式的模糊测试)，避免会导致非确定性执行的隐藏输入。我们希望在模糊地测试代码时尽可能有确定性。

或者避免控制模糊测试的阻碍。

模糊测试的障碍是那些不能模糊的东西。模糊测试的典型障碍是输入中某处包含的校验和：模糊设备基于突变对输入进行随机修改会导致非法校验和，从而降低代码覆盖率。这个问题基本上有两种解决方案。首先，在模糊测试构造中关闭校验和验证；其次，确保模糊控制器能够产生具有合法校验和的输出。基于生成的模糊控制器具有这种功能；如果我们使用基于变异的模糊控制器，那么我们需要编写一个小工具。在生成测试用例之后，我们需要在测试用例被传递到模糊测试程序之前，给它们添加一个有效的校验和。Alf支持这种方法。

除了校验和之外，未满足的输入验证属性也是一个严重的问题。比如要对强类型编程语言的编译器进行模糊测试，盲目修改编译器的输入很难得到有效的编译器输入。我喜欢把有效性的约束分为软约束(无效输入除了浪费时间没有其他危害)和硬约束(系统在处理无效输入时可能会野跑，所以要避免无效输入，否则完全不可能进行模糊测试)。如果我们通过对C编译器的模糊测试来寻找错误代码中的错误，我们将面临严格的有效性约束，因为它会

导致未定义行为的编译器输入看上去很像是代码中有bug。对于这类问题，我们没有简单的通用解决方案，只能通过一系列技巧来考虑有效性属性。有一个最简单的解决方案（但往往不是正确的解决方案），那就是自己编写一个模糊器。但问题在于，如果自己编写模糊器，就无法再利用现代覆盖驱动的模糊测试技术——这种技术非常了不起的。为了匹配覆盖率驱动的模糊测试框架，你有以下几种选择：首先，编写一个能够满足有效性约束的自定义变异器；其次，采用了解结构的模糊，意思是说从模糊器中获取修改后的数据，并将其转换为模糊测试程序所需要的内容。关于如何让覆盖驱动的模糊器在有效性约束下依然良好地运行，且不需要大量的手动工作，我们还有大量的研究工作需要展开。这其中涉及很多细节，改日再深入介绍。一般来说，在模糊器中加入类似SAT的求解器并不能解决这个问题，其原因首先是，有的有效性约束（比如校验和）对于求解器来说难度特别大；其次是因为有些有效性约束（如C++程序中的未定义行为）是隐含的，我们无法从系统中推断，甚至从原理上也不可能。

一般来说，你无法通过为公共API提供输入的方式，来针对系统的大部分代码进行模糊测试，因为这些访问会被系统中的其他代码阻止。例如，如果你使用自定义的内存分配器实现或自定义的哈希表实现，那么应用程序级别的模糊测试可能无法针对分配器或哈希表进行有效的模糊测试。这些API应该直接暴露给模糊测试。单元测试和模糊测试有强烈的联系：如果其中一个可行且可取，那么另一个也应该差不多。通常你应该同时兼顾两者。

通常，Sanitizer和模糊器需要对构建过程进行调整，甚至是重大的改动。为了简化这一过程，请尽可能简化构建过程。确保可以轻松切换编译器以及修改编译器选项。尽量减少对特定工具（以及工具版本）的依赖。定期利用多个编译器构建和测试代码。构建系统的特殊依赖都需要记录下来。

最后，有些模糊测试的阻碍有点傻而且很容易避免。如果你的代码存在泄漏内存的问题，或者过深的调用栈会导致进程终止，那么使用持久模式的模糊测试是一件痛苦的事情，所以请尽量避免这些问题。尽量不要处理SIGSEGV信号，如果无法避免的话，那么应当有办法在模糊器构建中禁用相应的信号处理程序。如果你的代码无法与ASan或UBSan兼容，那么这些非常有用的预言就很难善加利用了。特别是，如果你的代码使用自定义的内存分配器，那么你应该考虑在模糊测试构建中将其关闭，或者经过调整后与ASan一起使用，否则就有可能漏掉重大bug。

为覆盖驱动的模糊器排除障碍

由于覆盖驱动的模糊器的主要精力放在了测试未覆盖的分支上，因此可能会被特殊的方式阻碍。例如，如果覆盖驱动的模糊器遇到了太多未覆盖的分支，它就会在这些分支上花费大量时间，导致覆盖程序其他分支的可能性降低。例如，有一次我比较了一个程序在使用和不使用UBSan两种情况下的afl覆盖率，结果发现（在我设定的时间限制下）sanitized程序的覆盖率要比没有sanitized的程序低得多。但另一方面，我们也希望模糊器能找到sanitizer的错误。我的建议是有sanitized和没有sanitized的程序都进行模糊测试。我不知道应该如何为这些模糊测试活动分配资源，也不知道是否有人在研究这个问题。也许这个问题并不重要，因为模糊测试本来就是过度测试。

有时候，你的程序在执行前期调用的代码会包含大量分支且会被过度模糊的代码。例如，可能你需要在处理输入之前对输入进行解压缩或解密。这很可能会影响基于覆盖的模糊器，导致模糊器花费大量时间去模糊测试加密库或压缩库。如果你不是希望这样，那么就应该提供一种方法，在模糊测试过程中禁用加密或压缩。

程序中的解释器都可能会给基于覆盖的模糊器造成困难，因为相关的程序执行路径是在解释器数据中编码的，而对于模糊器而言，一般情况下数据是不透明的。如果你想让基于覆盖的模糊器发挥最大作用，那么就应该考虑避免编写解释器，或者至少大力简化解释器。解决嵌入式解释器有一个很明好的方法（我相信肯定有人尝试过，不过我不知道）就是提供一个API，告诉模糊器该如何观察被解释语言的覆盖率。