模糊测试（fuzz testing）是一类安全性测试的方法。说起安全性测试，大部分人头脑中浮现出的可能是一个标准的“黑客”场景：某个不修边幅、脸色苍白的年轻人，坐在黑暗的房间中，正在熟练地使用各种工具尝试进入某个系统。这种由安全人员“模拟黑客进入系统”的测试方法的确是安全性测试中的一种有效测试手段，名叫“渗透测试”。渗透测试方法完全依靠测试执行者的能力，能力强的“白客”能够发现有价值的安全性漏洞，而不具备很强的攻击能力的测试者就无法有效发现系统中的安全性漏洞。必须承认，渗透测试是一种有效的安全性测试手段，当然，前提是你要能够找到足够好的测试执行者。
渗透测试是一种有效的测试方法，但由于它对执行者的能力要求太高，因此很难被大规模应用。站在测试的角度，我们是否能够用“自动化测试”这个强有力的武器帮助降低安全性测试的门槛呢？一个容易想到的“录制/回放”方法是：将渗透测试的执行者们的操作录制下来，形成脚本，期望这些脚本可以在不加修改或是稍加修改时应用在对其他应用的安全性测试中。但由于渗透测试的过程并不具有可重复的特点（测试执行主要依赖执行者的经验，类似调试），这种想法在真实的安全性测试环境下完全不可行。完全自动化的工具通常只能发现那些可被用标准化方式发现的特定安全漏洞（如简单的SQL注入漏洞）。
模糊测试是一种介于完全的手工渗透测试与完全的自动化测试之间的安全性测试类型。它充分利用了机器的能力：随机生成和发送数据；同时，也尝试将安全专家在安全性方面的经验引入进来。从执行过程来说，模糊测试的执行过程非常简单：
- 测试工具通过随机或是半随机的方式生成大量数据；
- 测试工具将生成的数据发送给被测试的系统（输入）；
- 测试工具检测被测系统的状态（如是否能够响应，响应是否正确等）；
- 根据被测系统的状态判断是否存在潜在的安全漏洞。
显然，模糊测试的整个执行过程是依靠工具进行的自动化测试。但是，看起来它完全是一个类似MonkeyTest工具的随机数据生成器嘛，这怎么能和安全专家的经验结合起来呢？别着急，我们用一个例子来演示一下。
为了简单起见，假定我们要测试的应用是一个C/S应用的服务端程序。这个程序运行在Unix平台上，名字叫做TgServer。我们唯一知道的信息就是客户端和TgServer之间使用基于TCP/IP的自定义协议进行通讯。这种情况下，我们该如何尝试找到应用系统中可能的漏洞？
方法1：
如果我们手头上有TgServer的源代码，通过代码审查显然可以找到可能的漏洞。就算没有源代码，通过逆向工程方式，用代码审查的方式也可以达到找到漏洞的目的。当然，这必然要求审查者具有足够好的技能，而且，被测应用规模越大，需要付出的成本也就越高。
方法2：
尝试抓取到客户端和服务器之间的通信数据，根据这些数据分析出客户端与服务器之间的通信协议，然后根据协议的定义，自行编造数据发起攻击，尝试找到可能的漏洞。
方法2在成本上比方法1要低，而且由于方法2关注的是协议层面的攻击，效率会更高。但是，稍微想一下，方法2还是存在一些问题：
- 完整的协议分析难度很大；
- 人工编造数据的成本很高；
在方法2的基础上，我们尝试引入模糊测试的概念，由于机器生成和发送数据的能力足够强，因此我们完全可以把生成数据的任务交给机器去完成。当然，协议的分析主要还是依赖人工来进行，模糊测试领域内有一些自动化的协议分析手段（《模糊测试》一书中有专门的章节描述），但从效率和效果上来说，在面对复杂协议的时候，人工分析的方式更为有效。
假如根据抓取到的数据包，我们发现被测应用使用的协议如下（|仅表示字段间的分割，不是实际的数据内容）：
|00 01| GET | 11 | user:dennis
- 2字节的包头（00 01）
- 10字节定长的命令（GET）
- 一个1字节的数据，表示命令参数的长度
- 不定长的命令参数
根据这些信息，使用模糊测试方法，我们就可以借助通用的模糊测试工具（如Spike），用模板方式将协议描述出来，并让模糊测试工具自动填充可变字段的内容，生成大量的测试用例并发送给TgServer。同时，通过模糊测试工具提供的功能监视TgServer，一旦TgServer出现可被识别的问题（如性能下降，不再响应，或是返回异常数据等），我们就可以停止模糊测试，并通过日志找到导致问题的请求，进而确认问题。
简单的说，模糊测试尝试降低安全性测试的门槛，通过半随机方式的数据发送来找出被测系统的漏洞。显然，测试这对被测应用越了解，模糊测试的生成就能越准确。但与渗透测试或是代码审查相比，模糊测试显然更加易于进行。而且，通过自动化工具，模糊测试可以把安全方面的经验积累到工具中，为组织持续的安全性测试提供帮助。
这是本系列的第一篇，后续还将写两篇来介绍不同类型应用的模糊测试，以及常用的模糊测试工具。
《模糊测试——强制发掘安全漏洞的利器》这本书全面覆盖了模糊测试这一技术。