模糊测试实践

介绍

模糊测试是渗透测试中最为常用的一种测试方法，在业界被公认为是强制发掘安全漏洞的利器。它是一种构造大量非法或者随机输入来让软件系统暴露问题的艺术和科学，通过向应用提供非预期的输入并监控输出中的异常来发现软件中的故障(faults)的方法。所以它并不是很多人眼中的简单的随机测试，而是有规律可循，并且可以建立模型的专项测试。模糊测试能发现多种不同类型的安全漏洞，其中包括 SQL 注入，目录遍历/弱访问控制，弱认证，弱回话管理，缓冲区溢出，XSS 攻击，远程代码注入，远程命令执行，DoS 等各种常见的安全漏洞。比如针对 SQL 注入，运用模糊测试去构建大量常规或者变异的注入字符串，并使用其对于被测系统进行攻击，并通过脚本过滤特定的返回值，从而可以判断被测系统是否存在 SQL 注入漏洞。这个方法同样适用于命令注入和代码注入。对于其他目录遍历/弱访问控制，弱认证，弱回话管理，缓冲区溢等漏洞，模糊测试也是针对其特定的漏洞来构建大量攻击字符串，比如用各种已知文件名或目录名去访问服务器，用各种密码字典去登陆，用各种不同值的 session id 去重用会话等。从而达到发现安全漏洞的目的。

实施步骤

第一步:

做模糊测试需要确定“攻击面”和“攻击向量”，并针对“攻击面”和“攻击向量”进行优先级分类。优先级的制定可以根据 OWASP Top 10 等社区制定的危险等级来确定，也可以根据项目威胁建模的风险等级来确定。在确定优先级以后，在资源允许的情况下至少要把高优先级的“攻击面”和“攻击向量”都测试一遍。如果还有多余资源，还可以对中等级别的“攻击面”和“攻击向量”进行测试。其中“攻击面-Attack Surface“是指可以执行并进而攻击的代码，比如邮件服务器的协议解析器和客户端程序的处理代码，或者服务器端解析 JSON 并将其中某个字段的值存入数据库等。而“攻击向量 - Attack Vector”是指执行攻击的方法，比如发送一封电子邮件，发送一个 HTTP POST 等。

第二步:

需要生成有效的测试数据。由于模糊测试中最为关键的部分就是数据生产，所以它的好坏直接关系到模糊测试有效性。其中数据生成可以分为三类：● 变异数据变异数据是将对被测系统的正常测试数据进行特定的改变，即变异。这种特定的变化一般不会改变测试数据的结构，而是改变测试数据的类型，值以及长度等。可以通过手动生成变异数据，也可以自动化生成变异数据。● 模型生成数据基于模型生成数据，是通过分析系统的数据模型，构建一套基于系统数据模型的测试数据生成系统或者工具，然后自动生成测试数据来做自动化模糊测试。● 随机生成数据有时需要快速进行模糊测试，或者数据模型很难构建，然后就可以直接通过随机的方法来生成测试数据。不过这种方法可能构建出不符合数据结构或者数据模型的测试数据，导致测试数据的有效性很差，直接影响到模糊测试的有效性和测试效率。不过这种方式却可能发现一些很难以发现的漏洞。

第三步:

需要对测试结果和日志进行分析，并从中找到可能存在漏洞的用例数据。然后再深入研究，并再确认这个用例攻击的有效性。对于有效攻击用例，需要根据其危险级别生成不同级别的安全漏洞卡，然后最终交与开发人员进行修复。

在模糊测试的整个流程中，自动化主要是加速测试用例的执行速度以及日志过滤等工作，减少大量重复的手动工作。除了自动化之外，人工仍然需要做大量的“攻击面”风险分析和选取，“攻击向量”制定，以及测试数据模型的建立以及日志分析等工作。其中对于一些常规的“攻击面”和“攻击向量”会存在一些通用的数据模型或者数据，它们可以在大量的安全社区找到。但是对于系统特有的“攻击面”和“攻击向量”，是需要测试人员通过深入了解业务需求，业务和技术架构以及数据流图等之后自己定制化的。

实例

实例 1，服务器系统中的 SQL 注入

我是一个 Web 系统的管理员，但是我忘记了管理员密码。然后我想试试通过找到一个 SQL 注入漏洞来重置或者找到我的密码。首先通过 Chrome 打开 Web 系统的登陆界面，然后通过 Chrome Developer Tool 获得登陆的 post 请求数据包。分析数据包并确定数据包结构，并通过 WebFuzz 构造模糊数据发送登录数据，比如：UserName=[SQL]&sPassword&btnLogin=Log+In。通常登录错误应该提示非法用户，但是有些模糊请求返回，比如：There was an error while attempting to log in: Error=80040E14 ErrorMessage=IDispatch error #3091 Description=MicrosoftSQL Server。看起来这些模糊数据被成功提交到了数据库，所以应该存在 SQL 注入。

实例 2，模糊测试 Android 手机上的 Chrome

Chrome 是 Android 系统中的默认浏览器，所以如果它存在安全问题，那么大量的 Android 手机也就存在安全问题。而 Chrome 一只都在发展和进化，不停的又新功能加入。而新功能存在漏洞的可能性往往比老功能更大。所以在这个测试中选取了 HTML5 的类型数组作为攻击面，比如 Uint8Array，Float64Array。然后随机生成测试数据，比如 x=new Float64Array({length: 0x24924925})。搭建一个 HTTP 服务器能提供包含这些测试数据或者数据生成代码以及 JS 代码的页面，并通过模糊测试工具 BrowserFuzz 运行 Chrome 去访问包含测试数据的页面。最后使用 adb 调用 logcat 获取系统日志来监控崩溃日志，并通过分析崩溃日志就有可能发现 Chrome 的缓冲区溢出等这样的安全漏洞。

现在业界已经拥有许多商用或者免费的自动化模糊测试框架和工具，比如 SPIKE，Autodafe，Peach 具 BrowserFuzz，ZAP，WebFuzz 等，更多的模糊工具可以参考 http://www.fuzzing.org/。

总结

对于模糊测试一般需要分为以下四步：

1. 首先确定攻击面，攻击向量以及数据生成方式，并生产有效的测试数据。

2. 其次使用生成的数据对被测系统进行自动化模糊测试，并收集所有的测试日志。

3. 然后检测系统的异常输出或者日志等。

4. 最后分析异常输出和日志，并确定是否可能存在漏洞。如果可能存在漏洞，就需要进一步分析确认，比如重新构造特定数据进行测试，或者和开发人员结对分析系统代码等方法。

   
   

   虽然模糊测试可以发现很多难以发现的安全漏洞，但是常规的安全测试也需要做的。所以模糊测试可以作为常规安全的是的补充，从而尽可能的发现更多的安全漏洞，让软件系统更为安全。

展望

模糊测试通过其特定的测试方法和测试工具，从而可以发现程序代码中隐藏的，很难通过常规测试方法发现的错误和漏洞，所以在现实中的意义是非常大的。现在大量的模糊测试主要是在软件开发的测试阶段进行实施的，甚至不少模糊测试是在软件系统发布上线以后，由专门的安全测试工程师等在产品环境实施的。其实这样大大的延长了问题和漏洞被发现的时间，从而增长了软件研发的周期的可能，也增加了软件由于这些问题和漏洞而产生损失的概率。所以应该学习测试左移动的概念，将模糊测左移到软件开发的前期，让模糊测试的各种不同类型的工作嵌入到软件开发的全生命周期里面去。比如在分析阶段开发分析本软件系统是不是有可能存在大量的攻击面，从而是不是需要实施模糊测试；在设计阶段，通过分析软件架构等各种技术和业务细节，确定攻击面以及以及攻击向量，以及数据类型等，并设计好模糊测试方案；在开发编码阶段，开发可以对某些重点的复杂的模块，基于单元级别进行全自动的模糊测试，比如内存的模糊测试（参见《模糊测试第 19 章》）；在测试阶段，基于已经设计好的模糊测试方案，实施大规模的模糊测试；在维护阶段，需要持续关注软件系统的可能存在的新漏洞，比如第三方组件出现的新漏洞，尝试新的模糊测试方法和工具。如果有资源，还可以在特定的环境中针对发布的软件版本实施持续的模糊测试。随着大量的商用模糊测试工具的问世，说明业界对于模糊测试的需求还是很大，并且随着商业模糊测试工具的发展，一定会倒逼开源模糊测试工具进一步的发展。其次，未来还可以将模糊测试与其他技术和方法组合起来使用，比如将源代码分析技术和模糊测试技术组合起来使用，从而可以更为高效和精确的实施模糊测试，从而节约模糊测试的时间成本。最后，模糊测试工具未来需要进一步集成到各大测试平台中，从而提供统一的模糊测试基础设施，节约测试成功。总之，模糊测试未来可期。