模糊测试 对代码质量影响深远的技术

用校验和进行的模糊试验

    能够保护程序抵御模糊攻击的最简单的方法是将一个检验和添加到数据中。例如，可以将文件中所有的字节都累加起来，然后取其除以 256 的余数。将得到的值存储到文件尾部的一个额外字节中。然后，在输入数据前，先验证检验和是否匹配。这项简单模式将未被发现的意外故障的风险降低到约 1/256 。

    健壮的校验和算法如 MD5 和 SHA 并不仅仅取其除以 256 的余数，它完成的要多得多。在 Java 语言中，java.security.DigestInputStream 和 java.security.DigestOutputStream 类为将一个校验和附属到数据中提供了便捷的方式。使用这些校验和算法中的一种可以将程序遭受意外破坏的机率降低到少于十亿分之一（尽管故意攻击仍有可能）。

XML 存储及验证

   将数据以 XML 形式存储是一种避免数据损坏的好方法。XML 最初即着力于 Web 页面、书籍、诗歌、文章及相似文档，它几乎在每个领域都获取了巨大的成功，从金融数据到矢量图形到序列化对象等等。

不切实际的限定 如果真想要破坏一个 XML 解析器，有几种方法可以试试。例如，大多数 XML 解析器服从于特定的最大尺寸。如果一个元素名长度超过 22 亿字符（Java String 的最大尺寸），SAX 解析器将会失败。尽管如此，在实践中这些极限值如此之高，以至于在达到之前内存就已经耗尽。

    使 XML 格式抵制模糊攻击的关键特征是一个对输入不做任何 假设的解析器。这就是真正想在一个健壮的文件格式中所获得的。设计 XML 解析器是为了让任何输入（格式良好的或无格式的，有效的或无效的）都以定义好的形式处理。XML 解析器能够处理任何 字节流。如果数据首先通过了 XML 解析器，则仅需要准备好接受解析器所能提供的东西。例如，不需要检查数据是否包含空字符，因为 XML 解析器绝不会传送一个空值。如果 XML 解析器在其输入中看到一个空字符，它就会发出异常并停止处理。当然还需要处理这个异常，但编写一个 catch 块来处理检测到的错误比起编写代码来检测所有可能的错误来说要简单得多。

    为使程序更加安全，可以用 DTD 和/或模式来验证文档。这不仅检查了 XML 是否格式良好，而且至少与所预期更加接近。验证并不会告知关于文档所需了解的一切，但它却使编写大量简单检查变得很简单。用 XML，很明显能够将所接受的文档严格地限定为能够处理的格式。

    尽管如此，还有多段代码不能用 DTD 或模式进行验证。例如，不能测试发票上商品的价格是否和数据库中库存商品的价格一致。当从客户接收到一份包含价格的订单文档时，不论其是 XML 格式或是其他格式，在提交前通常都会检查一下，以确保客户并未修改价格。可以用定制代码实现这些最后的检查。

基于语法的格式

    使 XML 能够对模糊攻击具有如此的抵御能力的是其使用巴科斯-诺尔范式（Backus-Naur Form，BNF）语法仔细且标准地定义的格式。许多解析器都是使用如 JavaCC 或 Bison 等解析器-生成器工具直接从此语法中构建的。这种工具的实质是阅读一个任意的输入流并确定其是否符合此语法。

    如果 XML 并不适合于您的文件格式，您仍可以从基于解析器的解决方案的健壮性中获益。您必须为文件格式自行编写语法，随后开发自己的解析器来阅读它。相比使用唾手可得的 XML 解析器，开发自己的解析器需要更多的工作。然而它是一个更为健壮的解决方案，而不是不根据语法正式地进行验证就将数据简单地装载到内存中。

Java 代码验证

    由模糊测试导致的许多故障都是内存分配错误及缓冲器溢出的结果。用一种安全的垃圾收集语言（在如 Java 或 managed C# 等虚拟机上执行的）来编写应用程序避免了许多潜在问题。即使用 C 或 C++ 来编写代码，还是需要使用一个可靠的垃圾收集库。在 2006 年，台式机程序员或服务器程序员不应该还需要管理内存。

    Java 运行时对其自身的代码起到了额外保护层的作用。在将一个 .class 文件装载到虚拟机之前，该文件要由一个字节符验证器或一个可选的 SecurityManager 进行验证。Java 并不假设创建 .class 文件的编译器没有 bug 且运转正常。设计 Java 语言之初就是为了允许在一个安全沙箱中运行不信任的、潜在恶意的代码。它甚至不信任其自身编译过的代码。毕竟，也许有人已经用十六进制编辑器手工修改了字节符，试图触发缓冲器溢出。我们大家都应该对我们的程序也有对输入这样的偏执。

以敌人的角度思考

    之前介绍的每项技术都在阻止意外破坏方面造诣颇深。将它们综合起来恰当地实现，会将未被发现的非蓄意破坏发生的可能性几乎减少到零。（当然，并不会减少到零，但其发生的可能性就如同一束偏离轨道的宇宙射线将您 CPU 运算 1+1 的结果变为 3 的可能性一样微乎其微。）但不是所有的数据损坏都是非蓄意的。如果有人故意引入坏数据来破坏程序的安全性又该如何呢？以一个攻击者的角度进行思考是防护代码的下一个步骤。

     转回到一个攻击者的角度进行思考，假设要攻击的应用程序是用 Java 编程语言编写的、使用非本地代码且将所有额外数据都以 XML（在接受前经过彻底验证）形式存储，还能成功攻击吗？是的，能。但用随机改变文件字节的低级方法显然不行。需要一种更为复杂的方法来说明程序自身的错误检测机制及路径。

    当测试一个抵御模糊攻击的应用程序时，不可能做纯黑盒测试，但通过一些明显的修改，基本的想法还是可以应用的。例如，考虑校验和，如果文件格式包含一个校验和，在将文件传至应用程序前仅仅修改此校验和就可以使其同随机数据相匹配。

    对于 XML，试着模糊单独的元素内容和属性值，而不是从文档中挑选一部分随机的字节进行替换。一定要用合法的 XML 字符替换数据，而不要用随机字节，因为即使一百字节的随机数据也一定是畸形的。也可以改变元素名称和属性名称，只要细心地确保得到的文档格式仍是正确的就可以了。如果该 XML 文档是由一个限制非常严格的模式进行检查的，还需要计算出该模式没有 检查什么，以决定在哪里进行有效的模糊。

    一个结合了对剩余数据进行代码级验证的真正严格的模式也许不会留下可操纵的空间。这就是作为一个开发人员所需要追求的。应用程序应能够处理所发送的任何有意义的字节流，而不会因权利上（ de jure ） 无效而拒绝。

结束语

    模糊测试能够说明 bug 在程序中的出现。并不证明不存在这样的 bug。而且，通过模糊测试会极大地提高您对应用程序的健壮性及抵御意外输入的安全性的自信心。如果您用 24 小时对程序进行模糊测试而其依然无事，那么随后同种类型的攻击就不大可能再危及到它。（并不是不可能，提醒您，只是可能性很小。）如果模糊测试揭示出程序中的 bug，就应该进行修正，而不是当 bug 随机出现时再对付它们。模糊测试通过明智地使用校验和、XML、垃圾收集和/或基于语法的文件格式，更有效地从根本上加固了文件格式。

    模糊测试是一项用于验证程序中真实错误的重要工具，也是所有意识到安全性问题且着力于程序健壮性的程序员们的工具箱中所必备的工具。

关于作者

		Elliotte Rusty Harold 来自新奥尔良， 现在他还定期回老家喝一碗美味的秋葵汤。不过目前，他和妻子 Beth 定居在纽约临近布鲁克林的 Prospect Heights，同住的还有他的猫咪 Charm（取自夸克）和 Marjorie（取自他岳母的名字）。他是 Polytechnic 大学计算机科学的副教授，他在该校讲授 Java 和面向对象编程。他的 Web 站点 Cafe au Lait 已经成为 Internet 上最流行的独立 Java 站点之一，它的姊妹站点 Cafe con Leche 已经成为最流行的 XML 站点之一。他的书包括 Effective XML、 Processing XML with Java、 Java Network Programming 和 The XML 1.1 Bible。他目前在从事处理 XML 的 XOM API、Jaxen XPath 引擎和 Jester 测试覆盖率工具的开发工作。

查看本文来源