模糊测试是一种通过向目标系统提供非预期的输入并监视异常结果来发现软件漏洞的方法。
 
实现流程： 
 1. 确定测试的目标 
 2. 确定输入的向量 
 3. 生成模糊测试数据 
 4. 执行模糊测试数据 
 5. 监视异常 
 6. 判断发现是否有漏洞可以被利用
 
模糊测试一般分为两大类： 
 1. 本地模糊测试 
 应用于本地系统或者托管的目标系统上，比如命令行模糊测试、文件格式模糊测试、 
 内核模糊测试。
 
远程模糊测试 
 远程模糊测试远程测试目标网络。比如：网络协议模糊测试、数据库模糊测试、Web模糊测试。
 
我主要研究的是网络协议模糊测试： 
 网络协议模糊测试的对象主要是各类网络产品中的网络协议解析模块，目的是测试其在组装、解析网络协议过程中是否出现漏洞。其思想是通过Socket与被测目标之间进行通信，向被测目标应用发送变异或者包含错误的模糊值，并监视目标应用以发现错误。
 
目前最常见的网络协议模糊测试实施方案有两种： 
 1.客户端和服务端模式。自己写的模糊器或者第三方模糊测试器可以分别用来充当客户端和服务端，以此来测试相应的服务端和客户端的安全性。比如Web服务程序。 
 2.为了测试防火墙、路由器、安全网关等部署在网络中间的设备。模糊器构造的数据被发送到协议服务器的过程中，位于模糊器和协议服务器之间的被测对象起到了重组和解析的作用，一旦重组和解析过程中出错，可能造成被测对象出现异常状态。模糊器中的监控模块用来对被测对象的异常状态进行收集、分析，最终定位漏洞所在。
 
Unix平台自动化网络协议模糊测试 
 1.使用SPIKE模糊测试框架 
 SPIKE用模糊字符串库中的内容迭代模糊变量，达成模糊测试。模糊字符串可以是任何数据类型。 
 SPIKE包含了一部分预先写好的针对具体协议的模糊测试器，比如：HTTP模糊测试器、Microsoft RPC模糊测试器、X11模糊测试器、Citrix模糊测试器、Sun RPC模糊测试器等。 
 还有一些通用的模糊测试脚本等。

介绍
这篇博文介绍了关于模糊测试的基础知识，以及几种模糊测试工具，并由以下三个部分阐述一些最新的关于fuzzing技术的资讯。
 
第一部分主要介绍高级模糊测试技术。简要地讨论了使用模糊测试的情景，并进一步解释了开启模糊测试场景以及经典的模糊测试工具的架构。
 第二部分主要描述模糊测试入门的过程，并介绍几种通俗易懂，易于理解和使用的模糊测试工具。虽然，通常情况下直接使用现有的fuzzer更为简便，但是由用户自己编写的fuzzer或调整现有的fuzzer可能会产生更好的效果。本文提供的不是一个足够全面完整的列表，而是一系列不同模糊测试技术的示例。
 第三部分主要阐述了最近发表的关于模糊测试技术的研究。它将重点关注新型模糊测试技术和经过测试用例已生成技术的公开研究结果。
0 – Fuzzing 101

 
介绍
 

本章节将介绍高级模糊测试技术，并简要地讨论了使用模糊测试技术的理由。我将会进一步解释你需要如何开始进行模糊测试以及典型的模糊测试工具的架构。
什么是模糊测试？

 
Fuzzing或模糊测试是一种自动化的软件测试技术，通常用于识别程序中的潜在漏洞。对程序进行模糊测试是通过向其提供随机输入语句并记录导致程序中的崩溃或非崩溃的内存损坏的测试用例来完成的。在某种意义上，模糊测试就是通过蛮力搜索漏洞。几乎所有需要某种输入的软件都可以进行模糊测试，比如——浏览器，通过查看或编辑文件的应用程序，系统内核，大多数API和其他程序接口，驱动程序，网络守护程序，Web应用程序等等都可以对其进行fuzzing。中国菜刀
 
 

简单的模糊测试不需要任何有关程序的信息，因此，这是一种黑盒测试技术。但是，有一些先进的模糊测试技术可以分析或检测源代码或二进制文件，以便将生成的输入定制到模糊程序，这将是本系列的下一篇博文介绍的内容之一。

为什么选择模糊测试？

Fuzzing 是一种自动发现 bug 的方法; 理想情况下，Fuzzing 可以简单地在机器上运行并且不受干扰。 因为它不需要太多的手动交互，所以它可以是一种廉价的测试技术。另一方面，手工测试非常耗费资源，它揭示的错误数量取决于测试人员的技能。模糊测试和手动测试的结合是最佳的一种做法，因为这两种技术通常会发现不同类型的错误，并且它们可以互补。
 应用程序越复杂，就会有越多的 bug，随着复杂性的增加，攻击面也会增加。 对非常复杂的应用程序进行手工测试需要花费大量时间，并且需要良好的测试技能。 例如，如果一个公司决定只手动测试一个浏览器，那么在下一个版本完成之前，就需要很多技能熟练的测试人员来测试整个应用程序。一个fuzzer可以简单的永久运行并且可以在软件发布之前完成测试。 大多数fuzzer的规模相当不错，所以如果需要测试的更快，找到更多的bug，那么你可以只是增加更多的测试机器或更多的CPU内核。也可以使用 Fuzzing 回归测试来确保不会再次引入任何已知的 bug。
 作为一个安全研究人员， fuzzing 的确是伟大的，因为一旦一个fuzzer设置好并运行后，你可以解放双手去做其他的事情。
模糊测试的常见问题
 虽然 fuzzing 是一个发现bug的伟大且廉价的方法，但它并不总是最佳的选择。这取决于应用程序和期望的缺陷类型，fuzzer 可能需要大量的时间来进行设置才能找到更多的缺陷。特别是那些能够意识到输入结构的可自编写的智能fuzzer的设置将会花费一些工作，直到它产生可用的结果。
 一个fuzzer是不能替代其他安全措施的。虽然你有最强大的fuzzer，发现了大量的漏洞，但它不太可能找到一个程序中的每一个漏洞。所以如果你的 fuzzer 没有发现更多的漏洞，这并不意味着你的程序是完全安全的。模糊测试只是对其他安全措施(如定期代码审计和其他安全开发原则)的一个很好的补充。
 Fuzzer可以产生许多误报，无法利用的bug以及重复的结果。因此，评审过程是强制性的，无论是手动的还是自动的，这是需要资源的。输入越复杂，评审过程就越复杂。
 最大限度地提高Fuzzer的效率是模糊测试最困难的部分之一。一个Fuzzer的价值通常取决于它发现了多少以前未知的bug或漏洞。为了找到更多的 bug，fuzzer 需要有一个高崩溃率的测试用例，这高度依赖于生成的测试用例的质量。通过管道/dev/urandom 到你的目标很容易，但是每个测试用例的崩溃率可能太低，无法在适当的时间窗口中找到任何内容。同时，单个测试用例的执行时间应该尽可能的短。
模糊测试需要什么？
 要开始模糊测试，你需要一个接受输入的目标。应用程序越复杂，就越有可能使用fuzzer找到bug。它可以是内部软件，也可以是第三方软件，这取决于你的测试用例。你需要考虑你想要捕捉的bug的类型。一个 fuzzer 需要知道什么时候它发现了一个 bug，所以最容易发现的 bug 是那些导致崩溃的 bug，因为这将表明一个潜在的安全漏洞。
 当你清楚你想模糊测试的应用程序和bug类型，那么你有必要思考情况使用什么样的fuzzer。如果你不想从头开始编写模糊测试工具，那么你可以选择许多不同的模糊测试工具。其中一些需要工具一些工作来进行设置，其他的工作则可以迅速完成。因为正确选择模糊测试工具既重要又困难，本系列的下一篇博客文章将介绍一些最重要的 模糊测试工具。天空彩​​​​​​​
一个fuzzer可以找到什么类型的bug？
 理论上，通过模糊测试工具可以找到所有可能的 bug 类型。fuzzer需要一种检测机制来将程序的行为分类为无意的或恶意的。因此，有些 bug 的类比其他 bug 的类在代码中更容易找到，因为它们会产生明显的错误行为。例如，内存损坏bug在触发时导致崩溃是很容易检测到的。另一方面，逻辑错误可能非常难以检测，因为程序没有明显的不正常行为，而且预先定义检测逻辑错误的规则可能比较棘手。
一个典型的fuzzer架构
 一个典型的fuzzer由三个不同的部分组成。 一个测试用例生成器生成输入，输入到被测试的程序; 一个worker程序执行给定的输入，并识别意外的行为; 一个日志记录器记录有趣的测试用例以及分析 bug 所需的一切。大多数fuzzer还包括一个服务器或主机，它协调其他三个部分并管理它们之间的通信。
 
 
测试用例生成器
 测试用例生成器主要负责创建新的测试用例。为了创建新的测试用例，它可以自己识别出输入的结构，这被称为智能fuzzer。相反，不知道输入结构的测试用例生成器被称为愚蠢fuzzer。测试用例可以从头开始生成，也可以从现有的测试用例中变异。复杂的fuzzer也可以将生成和变异结合从而生成测试用例。
模糊测试的导向类型
 由测试用例生成器创建的测试用例在质量上有很大的不同。因此，测试用例生成器需要某种指导来决定变更或生成哪些测试用例。最常见的启发式指导是代码覆盖率。理论上，代码覆盖的越多，模糊测试就能发现更多的错误。测试用例生成器可以配置为创建类似于发现新覆盖率测试用例的测试用例。与覆盖率导向的模糊测试类似，基本上所有与发现更多bug相关的指标都可以用作测试用例生成器的指导，例如数据流指导。
愚蠢fuzzer
 不需要输入结构模型来生成新测试用例的测试用例生成器称为愚蠢fuzzer。愚蠢fuzzer的优点是它不需要输入结构的信息，因此适合对很多不同的程序进行模糊测试而不需要太多的调整。使用愚蠢fuzzer的最大缺点是，大多数输入需要预定义的结构或包含校验和，fuzzer将很难生成有效的输入，因此主要是测试应用程序的解析代码。
智能fuzzer
 与愚蠢fuzzer相反的是一个智能fuzzer，它的测试用例生成器能够理解输入文件的结构。输入文件的结构称为输入模型。例如，输入模型可以是编程语言的语法或数据格式模型。智能fuzzer的优点是它主要创建有效的输入文件，这将导致实际程序中更高的代码覆盖率。然而，一个智能fuzzer通常是高度专业化的特定类型的输入，它需要一个好的输入模型才能够创建测试用例，从而可能触发bug。
基于变异的模糊测试
 基于变异的fuzzer是通过变异已知的测试用例来创建新的测试用例。常见的变异技术包括位翻转，即将输入中的随机位进行翻转，或移动、删除、重复输入中的数据块。一个基于变异的fuzzer的主要优点是它需要较少的worker来设置。基于变异的fuzzer的关键部分是选择有趣的测试用例进行变异。这些测试用例需要尽可能不同，使模糊测试达到尽可能多的代码覆盖率，使其更有可能发现bug。例如，如果目标是一个查看和编辑图片的应用程序，并且所选择的测试用例只是 PNG 格式的，那么fuzzer就不太可能覆盖到处理其他文件类型的代码。
基于生成的模糊测试
 基于生成的fuzzer会从头开始生成新的测试用例。基于生成的fuzzer需要知道输入文件的结构，否则它们只会生成随机的字节。通常它们需要worker来进行设置，并且专门用于特定的输入类型。 然而，一旦启动并运行之后，它们往往能比基于变异的fuzzer产生更多的代码覆盖率，因此更有可能发现不同的bug。
测试用例最小化
 随着时间的推移，由变异创建的测试用例在规模和复杂性上都趋向于增长。这会导致更长的执行时间，并且使得分析有趣的测试用例变得更加困难。较小的测试用例也可以更好地将模糊测试集中在被模糊测试的软件的有趣部分上。因此，fuzzer的测试用例生成引擎也应该能够最小化测试用例。最小化测试用例的目标是找到尽可能小的测试用例，同时触发初始测试用例触发的相同行为。 在这种情况下，相同的行为意味着要么触发相同的崩溃代码，要么满足相同的指导要求。例如，对于覆盖率导向的模糊测试是否意味着在最小化测试用例中命中相同的有趣代码块。这可以通过删除测试用例的某些部分、向目标提供修改后的输入并观察其行为是否仍然满足相同的要求来实现。

 
 
 
 
 多年来，我震惊于可能导致Microsoft Word崩溃的损坏文件数量。 几个字节不合时宜，整个应用程序就大火了。 在较旧的，不受内存保护的操作系统上，整个计算机通常会随之崩溃。 为什么Word无法识别何时收到错误数据，而只是发出错误消息？ 为什么仅仅因为一些东西被扭曲而破坏了自己的堆栈和堆？ 当然，Word并不是面对畸形文件时唯一表现恶劣的程序。 
 
 
 本文向您介绍了一种尝试避免此类灾难的技术。 在模糊测试中，您使用随机的不良数据（也称为fuzz ）攻击程序，然后等待一下，看看有什么坏处。 模糊测试的诀窍在于，这是不合逻辑的：自动模糊测试不会试图猜测可能会导致崩溃的数据（就像人工测试人员可能会做的那样），而是会在程序上尽可能多地抛出乱码。 通过这种测试确定的故障模式通常会使程序员感到震惊，因为没有逻辑的人会想到它们。 
 
 
 模糊测试是一种简单的技术，但是它仍然可以揭示程序中的重要错误。 它可以识别实际的故障模式，并指示在软件出厂前应插入的潜在攻击途径。 
 
 
 模糊测试的工作原理 
 
 
 模糊测试是一个非常简单的实现过程： 
 
 
 准备正确的文件以输入到您的程序。 
 用随机数据替换文件的某些部分。 
 使用程序打开文件。 
 看看有什么休息。 
 
 
 您可以通过多种方式改变随机数据。 例如，您可以随机分配整个文件，而不是替换其中的一部分。 您可以将文件限制为ASCII文本或非零字节。 用任何方式对其进行切片，关键是在应用程序上抛出大量随机数据并查看失败的原因。 
 
 
 
  
 测试基于C的应用程序 
 
  
 当字符串包含额外的零时，许多用C编写的程序都会遇到麻烦-如此之多，以至于额外的零会完全隐藏代码中的其他问题。 一旦确定了程序存在零字节的问题，您可能希望将其删除以使其他问题浮出水面。 
 
 
 
 
 虽然您可以手动进行初始测试，但实际上应该自动执行模糊测试以达到最佳效果。 在这种情况下，面对输入损坏时，首先需要为应用程序定义正确的错误行为。 （如果您发现程序没有费心去定义当输入数据损坏时会发生什么，那么，这是您的第一个错误。）然后，您只需将随机数据传递到程序中，直到找到一个不会触发适当数据的文件即可。错误对话框，消息，异常等。存储并记录该文件，以便以后可以重现该问题。 重复。 
 
 
 尽管模糊测试通常需要一些手动编码，但是有些工具可以提供帮助。 例如，清单1显示了一个简单的Java™类，该类随机修改文件的特定长度。 我通常喜欢在前几个字节之后开始模糊测试，因为程序似乎比以后的错误更容易注意到早期的错误。 （您想查找程序不会检查的错误，而不是程序会检查的错误。） 
 
 
 清单1.用随机数据替换文件的一部分的类 
 
 
import java.io.*;
import java.security.SecureRandom;
import java.util.Random;

public class Fuzzer {

     private Random random = new SecureRandom();
     private int count = 1;

     public File fuzz(File in, int start, int length) throws IOException  
{

         byte[] data = new byte[(int) in.length()];
         DataInputStream din = new DataInputStream(new FileInputStream(in));
         din.readFully(data);
         fuzz(data, start, length);
         String name = "fuzz_" + count + "_" + in.getName();
         File fout = new File(name);
         FileOutputStream  out = new FileOutputStream(fout);
         out.write(data);
         out.close();
         din.close();
         count++;
         return fout;
     }


     // Modifies byte array in place
     public void fuzz(byte[] in, int start, int length) {

         byte[] fuzz = new byte[length];
         random.nextBytes(fuzz);
         System.arraycopy(fuzz, 0, in, start, fuzz.length);

     }

}
 
 
  
 关于代码 
 
  
 我可以采用多种方法来优化清单1中的代码。 例如，对于使用java.nio的内存映射文件，它是一个非常好的候选者。 我还可以改善其错误处理和可配置性。 因为我不想让这些细节妨碍我在此处提出的想法，所以我将其保留下来。 
 
 
 
 
 模糊文件很容易。 将其传递给应用程序通常并不难。 脚本语言（如AppleScript或Perl）通常是编写模糊测试这一部分的最佳选择。 对于GUI程序，最困难的部分是识别应用程序是否指示正确的故障模式。 有时，最简单的做法是让人员坐在程序前，并将每个测试标记为通过或失败。 确保单独命名并保存所有生成的随机测试用例，以便您可以重现通过此过程检测到的所有故障。 
 
 
 防御性编码 
 
 
 可靠的代码遵循这一基本原则： 切勿在未经验证其一致性和完整性的情况下将外部数据接受到程序中。 
 
 
 如果您从文件中读取一个数字并期望它是正数，请在使用该数字进行进一步处理之前检查该数字是否正确。 如果您期望一个字符串仅包含ASCII字母，请确保它包含。 如果您认为文件包含四个字节的整数倍，请检查该文件。 切勿假设外部提供的数据的任何特征都符合您的预期。 
 
 
 最常见的错误是假定由于程序实例将数据写出，因此可以在不验证数据的情况下再次读回数据。 这很危险！ 数据可能已被另一个程序覆盖在磁盘上。 磁盘故障或网络传输错误可能损坏了它。 它可能已经被另一个有错误的程序修改了。 甚至可以故意修改它，以破坏程序的安全性。 假设什么都不做。 验证一切。 
 
 
 当然，错误处理和验证是丑陋的，令人讨厌的，不便的，并且被全世界的程序员彻底鄙视。 进入计算机时代已有60年了，我们仍然没有检查诸如打开文件是否成功或内存分配是否成功之类的基本信息。 要求程序员在读取文件时测试每个字节和每个不变式似乎是没有希望的-但是不这样做会使您的程序容易受到模糊的影响。 幸运的是，可以得到帮助。 正确使用的现代工具和技术可以大大减轻加强应用程序的痛苦。 特别是，三种技术脱颖而出： 
 
 
 校验和 
 基于语法的格式，例如XML 
 经过验证的代码，例如Java 
 
 
 带有校验和的模糊验证 
 
 
 您可以采取的最简单的措施是将校验和添加到数据中。 例如，您可以对文件中的所有字节求和，然后除以256后的余数。将结果值存储在文件末尾的一个额外字节中。 然后，在信任输入数据之前，请验证校验和是否匹配。 这种非常简单的方案将未检测到的意外故障的风险降低到256分之一。 
 
 
 诸如MD5和SHA之类的健壮的校验和算法除了将256除以余数外，还做很多事情。在Java语言中， java.security.DigestInputStream和java.security.DigestOutputStream类提供了将校验和附加到数据的便捷方法。 使用这些校验和算法中的一种，可以将意外损坏的可能性降低到不到十亿分之一（尽管您会看到，仍然有可能进行故意的攻击）。 
 
 
 XML存储和验证 
 
 
 用XML存储数据是避免数据损坏问题的一种极好的方法。 XML原本是用于网页，书籍，诗歌，文章和类似文档的，但它在从财务数据到矢量图形再到序列化对象的几乎每个领域都取得了广泛的成功。 
 
 
 
  
 不切实际的界限 
 
  
 如果您真的想破坏XML解析器，则可以尝试几种方法。 例如，大多数XML解析器都有一定的最大大小。 如果元素名称的长度超过22亿个字符（Java String的最大大小），则SAX解析器将失败。 但是，实际上，这些限制是如此之高，以至于在达到这些限制之前您将耗尽内存。 
 
 
 
 
 这使得XML格式的模糊性的主要特点是，XML解析器承担任何关于输入。 这正是您想要的强大文件格式。 XML解析器的设计使所有输入（格式正确或无效，有效或无效）都以定义的方式进行处理。 XML解析器可以处理任何字节流。 如果您的数据首先通过XML解析器，则解析器可以为您提供的一切都需要准备。 例如，您不需要检查数据是否包含空字符，因为XML解析器永远不会为您传递空值。 如果XML解析器在其输入中看到一个空字符，它将引发异常并停止处理。 当然，您仍然需要处理此异常，但是编写catch块来处理检测到的错误比编写代码来检测所有可能的错误要简单得多。 
 
 
 为了进一步提高安全性，您可以使用DTD和/或架构来验证文档。 这不仅检查XML的格式是否正确，而且检查它是否至少接近您的期望。 验证很少会告诉您有关文档需要了解的所有信息，但是它使编写许多简单的检查变得很容易。 使用XML，将接受的文档严格限制为您知道如何处理的格式非常简单。 
 
 
 仍然会有一些您无法使用DTD或架构验证的代码。 例如，您无法测试发票中某个项目的价格是否与库存数据库中该项目的价格相同。 当从客户那里收到包含价格的订购文档时，无论是XML格式还是其他格式，您都应在提交价格之前始终检查以确保客户未修改价格。 但是，您可以使用自定义代码实施这些最后的检查。 
 
 
 基于语法的格式 
 
 
 使XML如此抗模糊的一个特征是，使用Backus-Naur Form（BNF）语法对格式进行了仔细而正式的定义。 许多解析器是使用解析器生成器工具（例如JavaCC或Bison）直接从此语法构建的。 这种工具的本质是读取任意输入流并确定其是否满足语法要求。 
 
 
 如果XML不适合您的文件格式，您仍然可以获得基于解析器的解决方案的强大功能。 但是，您必须为文件格式编写自己的语法，然后开发自己的解析器以读取它。 滚动自己的工作比仅使用现成的XML解析器要耗费更多的工作。 但是，这是一个比将数据简单地加载到内存中而不对语法进行正式验证要强得多的解决方案。 
 
 
 Java代码验证 
 
 
 模糊测试导致的许多崩溃是内存分配错误和缓冲区溢出的直接结果。 使用在Java或托管C＃等虚拟机中执行的安全的，垃圾收集的语言编写应用程序可以消除许多潜在的问题。 即使使用C或C ++编写代码，也应使用可靠的垃圾收集库。 在2006年，任何台式机或服务器程序员都不应管理自己的内存。 
 
 
 Java运行时为其自身的代码增加了一层保护。 在将.class文件加载到虚拟机中之前，将通过字节码验证程序以及可选的SecurityManager对其进行验证。 Java不假定创建.class文件的编译器没有错误或行为不正确。 Java语言从一开始就被设计为允许在安全的沙箱中执行不受信任的，潜在的恶意代码。 它甚至不信任它本身已经编译的代码。 毕竟，有人可能已经使用十六进制编辑器手动更改了字节码，以尝试触发缓冲区溢出。 我们所有人都应该对程序输入有这种偏执感。 
 
 
 像敌人一样思考 
 
 
 每种先前的技术在防止意外损坏方面都大有帮助。 两者合计并正确实施，它们可以将未发现的意外损坏的机会降低到基本上为零。 （嗯，不是零，而是与宇宙射线导致CPU加1 + 1并得出3的机会相同的数量级。）但并非所有数据损坏都是无意的。 如果有人故意引入不良数据以期破坏程序的安全性怎么办？ 像破解者一样思考是保护代码的下一步。 
 
 
 回到攻击者的思维方式，让我们假设您要攻击的应用程序是用Java编程语言编写的，使用非本机代码，并且将所有外部数据存储为XML，在接受之前已对其进行了全面验证。 您还能成功攻击它吗？ 是的你可以。 但是，随机更改文件中字节的幼稚方法不太可能成功。 您需要一种更高级的方法来解决程序的内置错误检测机制并围绕它们进行路由。 
 
 
 当测试抗模糊应用程序时，不能进行纯黑盒测试，但是经过一些明显的修改，基本思想仍然适用。 例如，考虑校验和。 如果文件格式包含校验和，则只需将校验和修改为匹配随机数据，然后再将文件传递给应用程序。 
 
 
 对于XML，请尝试模糊各个元素的内容和属性值，而不要在文档中随机选择要替换的字节部分。 请小心用合法的XML字符而不是随机字节替换数据，因为几乎可以肯定甚至是一百字节的随机数据格式也有误。 您也可以更改元素名称和属性名称，只要注意确保生成的文档仍然格式正确即可。 如果根据限制性很强的架构检查XML文档，则需要弄清楚该架构没有检查的内容，以确定可以在哪里进行有效的测试。 
 
 
 真正严格的架构与剩余数据的代码级验证相结合，可能使您没有任何回旋余地。 作为开发人员，这是您应该争取的。 该应用程序应该能够有意义地处理您发送的任何字节流，因为它在法律上是无效的，因此不会被拒绝。 
 
 
 结论 
 
 
 模糊测试可以演示程序中是否存在错误。 并没有证明不存在此类错误。 尽管如此，通过模糊测试可以极大地提高您对应用程序的健壮性和安全性的信心，以防止意外输入。 如果您对程序进行了24小时的模糊测试并且仍然可以正常使用，那么同类的进一步攻击就不太可能损害它。 （并非不可能，请注意，可能性较小。）如果模糊测试确实揭示了程序中的错误，则应修复它们。 通过明智地使用校验和，XML，垃圾回收和/或基于语法的文件格式，从根本上强化文件格式可能会更有效率，而不是插入出现的随机错误。 
 
 
 模糊测试是一种用于识别程序中实际错误的关键工具，并且是所有安全意识和面向健壮性的程序员都应在其工具箱中使用的工具。 
 
 
 
 
 
 
 

  

 
 
 

  
翻译自: https://www.ibm.com/developerworks/java/library/j-fuzztest/index.html
 

转载自：CTF ALL IN ONE
 
基本原理
 
模糊测试（fuzzing）是一种通过向程序提供非预期的输入并监控输出中的异常来发现软件中的故障的方法。
 
用于模糊测试的模糊测试器（fuzzer）分为两类：
 
一类是基于变异的模糊测试器，它通过对已有的数据样本进行变异来创建测试用例
另一类是基于生成的模糊测试器，它为被测试系统使用的协议或文件格式建模，基于模型生成输入并据此创建测试用例。
 
模糊测试流程
 
模糊测试通常包含下面几个基本阶段：
 
确定测试目标：确定目标程序的性质、功能、运行条件和环境、编写程序的语言、软件过去所发现的漏洞信息以及与外部进行交互的接口等
确定输入向量：例如文件数据、网络数据和环境变量等。
生成模糊测试数据：在确定输入向量之后设计要模糊测试的方法和测试数据生成算法等
执行模糊测试数据：自动完成向测试目标发送大量测试数据的过程，包括启动目标进程、发送测试数据和打开文件等
监视异常：监视目标程序是否产生异常，记录使程序产生异常的测试数据和异常相关信息
判定发现的漏洞是否可被利用：通过将产生异常的数据重新发送给目标程序，跟踪异常产生前后程序相关的处理流程，分析异常产生的原因，从而判断是否可利用
 
基本要求
 
要实现高效的模糊测试，通常需要满足下面几个方面的要求：
 
可重现性：测试者必须能够知道使目标程序状态变化所对应的测试数据是什么，如果不具备重现测试结果的能力，那么整个过程就失去了意义。实现可重现性的一个方法是在发送测试数据的同时记录下测试数据和目标程序的状态
可重用性：进行模块化开发，这样就不需要为一个新的目标程序重新开发一个模糊测试器
代码覆盖：指模糊测试器能够使目标程序达到或执行的所有代码及过程状态的数量
异常监视：能够精确地判定目标程序是否发生异常非常的关键
 
存在的问题
 
模糊测试中存在的问题：
 
具有较强的盲目性：即使熟悉协议格式，依然没有解决测试用例路径重复的问题，导致效率较低
测试用例冗余度大：由于很多测试用例通过随机策略产生，导致会产生重复或相似的测试用例
对关联字段的针对性不强：大多数时候只是对多个元素进行数据的随机生成或变异，缺乏对协议关联字段的针对性
 
方法实现
 
输入数据的关联分析
 
通常情况下，应用程序都会对输入的数据对象进行格式检查。通过分析输入到程序的数据对象的结构以及其组成元素之间的依赖关系，构造符合格式要求的测试用例从而绕过程序格式检查，是提高模糊测试成功率的重要步骤。
 
应用程序的输入数据通常都遵循一定的规范，并具有固定的结构。例如：网络数据包通常遵守某种特定的网络协议规范，文件数据通常遵守特定的文件格式规范。输入数据结构化分析就是对这些网络数据包或文件格式的结构进行分析，识别出特定的可能引起应用程序解析错误的字段，有针对性地通过变异或生成的方式构建测试用例。通常关注下面几种字段：表示长度的字段、表示偏移的字段、可能引起应用程序执行不同逻辑的字段、可变长度的数据等。
 
应用程序所能处理的数据对象是非常复杂的。例如 MS Office 文件是一种基于对象嵌入和链接方式存储的复合文件，不仅可以在文件中嵌入其他格式的文件，还可以包含多种不同类型的元数据。这种复杂性导致在对其进行模糊测试的过程中产生的绝大多数测试数据都不能被应用程序所接受。数据块关联模型是解决这一问题的有效途径。该模型以数据块为基本元素，以数据块之间的关联性为纽带生成畸形测试数据。其中，数据块是数据块关联模型的基础。通常一个数据对象可以分为几个数据块，数据块之间的依赖关系称为数据关联。
 
数据块的划分通常遵循三个基本原则：
 
使数据块之间的关联性尽可能的小
将具有特定意义的数据划分为一个数据块
将一段连续且固定不变的数据划分为同一个数据块
 
数据块关联模型的划分：
 
关联方式 
  
内关联：指同一数据对象内不同数据块之间的关联性。 
    
长度关联：数据对象内某一个或几个数据块表示另一数据块的长度。是文件格式、网络协议和ActiveX控件模糊测试中最常见的一种数据关联方式。
 
外关联：指属于多个不同数据对象的多个不同数据块之间存在的关联性。 
    
内容关联：某个数据对象的某个数据块表示另一个（或同一个）数据对象的另一个数据块的值。在需要用户验证的网络协议应用中经常出现。
 
 
关联强度 
  
强关联：关联数据块的数量大于等于非关联数据块的数量。
弱关联：关联数据块的数量小于非关联数据块的数量。
 
评价标准 
  
有效数据对象效率：构造的畸形数据对象个数与能够被应用程序所接受处理的数据对象个数的比率。
 
 
测试用例集的构建方法
 
常见的构建方法有以下几种：
 
随机方法：简单地产生大量伪随机数据给目标程序。
强制性测试：模糊测试器从一个有效的协议或数据格式样本开始，持续不断地打乱数据包或文件中的每一个字节、字、双字或字符串。
预先生成测试用例：对一个专门规约的研究，以理解所有被支持的数据格式和每种数据格式可接受的取值范围，然后生成用于测试边界条件或迫使规约发生违例的硬编码的数据包或文件。
遗传算法：将测试用例的生成过程转化为一个利用遗传算法进行数值优化的问题，算法的搜索空间即为待测软件的输入域，其中最优解即为满足测试目标的测试用例。首先，使用初始数据和种子生成数据，然后对数据进行测试和评估，并监控测试过程，如果满足测试终止的条件，就输出测试结果，否则通过选择、杂交、变异生成新的数据。
错误注入与模糊启发式 
  
错误注入：指按照特定的故障模型，用人为的、有意识的方式产生故障，并施加特定故障于待测软件系统中，以加速该系统错误和失效的发生。 
    
通常可注入的错误类型：内存错误、处理器错误、通信错误、进程错误、消息错误、网络错误、程序代码错误等
 
模糊启发式：将模糊字串或模糊数值列表中包含的特定潜在危险值称作模糊启发式。 
    
边界整型值：整型值上溢、下溢、符号溢出等。
字符串重复：堆栈溢出等。
字段分隔符：将非字母数字字符如空格、制表符等随机地包含到模糊测试字符串中。
格式化字符串：最好选择 “%s”、"%n" 等包含到字符串中。
字符转换和翻译：特别关注对扩展字符的处理。
目录遍历：在URL中附加 “…/” 之类的符号将导致攻击者访问未授权的目录。
命令注入：向 “exec()”、“system()” 之类的 API 调用传递未经过滤的用户数据。
 
 
 
测试异常分析
 
在程序动态分析过程中，相关信息的获取途径有下面几种：
 
通过程序的正常输出获取信息
通过静态代码插桩获取信息
通过动态二进制插桩获取信息
通过虚拟机获取信息
通过调试接口或者调试器获取信息
 
模糊测试框架
 
模糊测试框架是一个通用的模糊器，可以对不同类型的目标进行模糊测试，它将一些单调的工作抽象化，并且将这些工作减少到最低程度。通常模糊测试框架都包含以下几个部分：
 
模糊测试数据生成模块 
  
原始数据生成模块：可以直接读取一些手工构造的正常数据，也可以根据结构定义来自动生成正常的测试数据
畸形数据生成模块：在原始数据的基础上做一些修改和变形，从而生成最终的畸形数据
 
动态调试模块：利用操作系统提供的调试接口来实现动态调试功能，以捕获被调试程序产生的异常信息
执行监控模块：在动态调试模块的基础上，在被调试程序运行过程中，实现对被调试程序执行状态的监控，从而决定什么时候终止被调试程序的运行
自动脚本模块：在执行监控模块的基础上，提供更复杂的监控功能
异常过滤模块：在动态调试模块的基础上，对异常产生的结果实时过滤
测试结果管理模块：测试结果数据库中除了异常信息之外，产生异常的畸形数据也会被保存。利用测试结果数据库，可以实现回归测试。
 
参考资料
 
Fuzzing
Awesome-Fuzzing