基于模糊测试的分布式数据库安全研究(一)——模糊测试背景知识

前言

模糊测试是当今主流的软件系统的安全性测试技术,通过模糊测试能挖掘出软件所存在的漏洞和攻击面,便于人发人员对软件系统进行良好的维护。
希望做这个课题的同时记录自己的学习历程,与各位共同进步~
本篇文章主要对模糊测试的背景知识做简要总结。


一、白盒测试

白盒测试是指从软件系统的内部进行测试,该方法是对源代码进行剖析,从而查找软件当前所存在的漏洞。它需要测试人员获取到全部源代码,从而清晰地了解软件的实现结构、对所有资源进行充分地访问,如软件的完整源代码、设计规约,甚至软件开发者本人。

1.白盒测试优点

(1)覆盖能力强:由于白盒测试能获取到所有的源代码,因此代码评审时能完整覆盖整个软件系统,所有可能的执行路径都能被查询到,以发现潜在的安全隐患(如栈溢出等)。

2.白盒测试缺点

(1)复杂性高:重要的软件项目包含的源代码可能有数万行,如果采用白盒测试的方式来查询软件的潜在隐患,需要大量的时间成本。

(2)可用性低:不能获取全部源代码时,则无法进行测试。这种情况普遍存在于商业软件。

二、黑盒测试

黑盒测试是从软件系统的外部进行观察。作为用户终端,我们只能控制每一次的输入,获取每次程序执行完毕时的输出,通过观察输出结果、比较输出与预期之间的差距,来进行测试。黑盒测试的典型特点是不知道软件的内部实现,且看不到每次输入后数据的处理过程。

1.黑盒测试优点

(1)可用性和可重现性高:黑盒测试在所有情况下都是可用的,并且每次黑盒测试的时候不需要提前对测试目标做假设。以文本传输协议(FTP)为例,黑盒测试很容易被定制成能测试其他任何FTP服务器的测试用例。

(2)简单:黑盒测试是测试的最基本层次,不用了解软件内部实现就可以进行。

2.黑盒测试缺点

(1)覆盖能力不清晰:黑盒测试的最大挑战便是,如何确定测试何时结束以及测试的有效性?

(2)理解力:黑盒测试最适合那些安全漏洞由一个单独的输人向量所引起的场景。然而, 复杂的攻击需要多种攻击向量, 其中的一些攻击将目标应用程序置人一种脆弱状态, 其他攻击向量进一步触发漏洞。此类攻击需要深刻理解应用程序的底层逻辑, 某些典型场景下更需要通过人工代码评审和逆向代码工程(RCE)才能发现漏洞。

三、灰盒测试

灰盒测试是存在与白盒测试与黑盒测试两个极端之间的一种“均衡”测试方案,它包括了传统的黑盒测试方案,同时外加一些代码逆向工程的观察结果(通过对可用的二进制文件的逆向工程,获得额外的分析信息)。

四、模糊测试

模糊测试是通过利用非预期的输入,来监视软件的异常结果,从而发现软件漏洞的方法。模糊测试一般是一个自动化或半自动化的技术,它会反复操作目标软件并为其提供测试输入。

将模糊测试类比为如何闯进一幢房子。假设犯罪人员要破门进人某人的家, 如果采用纯白盒的方法, 那么在实施破门之前应该能够得到关于这个家的所有信息,包括房屋设计图、各种锁的制造商列表、房屋建筑材料的详情等。 如果采用一种纯的黑盒测试方法来完成破门的话, 那么应该在黑夜的掩盖下逐步靠近这个房子, 悄悄地尝试所有的门和窗户是否有漏洞, 向房子内窥视以决定哪里可能是最好的突破口。最后, 如果选择采用模糊测试来完成突破的话, 便可以不必研究设计图更不用人工测试各种锁,要做的就是让破门而入的过程自动化,这就是强制性的漏洞发掘方法。

1、模糊测试的阶段综述

(开始)
识别目标
识别输入
生成模糊测试数据
执行模糊测试数据
监视程序异常
确定可利用性
(结束)
(1)识别目标

确定需要进行安全测试的目标应用程序、更细化的以及目标文件或目标库,尤其是被多个应用程序共享的库,这些库的用户多,出错的概率也较大。

(2)识别输入

几乎所有可被人利用的漏洞都是因为应用程序接受了用户的输入并且在处理输入数据时没有首先清除非法数据或执行确认例程。枚举输入向量对模糊测试的成功至关重要。
任何从客户端发往目标应用程序的输入都应该被认为是输入向量。这些输入包括消息头、文件名、环境变量、注册键值等等,他们都可以是模糊测试变量。

(3)生成模糊测试数据

不管是哪种目标应用程序及其数据格式,都应提前确定如何使用预先确定的模糊测试输入向量、如何变异已有的数据以及动态生成新的数据,引入自动化生成模糊测试的输入向量的技术在这一步至关重要。

(4)执行模糊测试数据

执行过程包括发送数据包给目标应用程序、打开一个文件或发起一个应用进程等,同上一步,此处也需要自动化执行。

(5)监视程序异常

模糊测试的过程中,必须对程序的执行进行持续的监视,需要明确记录是哪一次的测试向量使程序崩溃。

(6)确定可利用性

这是一个人工的过程。当故障被识别到后,因审核的目标不同,需要进一步判断该这个故障是否可被进一步利用。

2、模糊器的分类

模糊器总体来看可以分类两大类:基于变异的模糊器(mutation-based fuzzer)基于生成的模糊器(generation-based fuzzer) 。基于变异的模糊器是对已有的数据样本应用各种变异技术对初始输入数据进行变异,来创建各种不同的测试用例;而基于生成的模糊器则是通过对目标协议或文件格式建模的方法从头开始产生测试用例。
细化后,模糊器可以分为以下5类。

(1)预先生成测试用例

这是PROTOS框架所采用的方法。
测试用例的开发始于对一个专门规约的研究, 其目的是为了理解所有被支持的数据结构和每种数据结构可接受的取值范围。硬编码的数据包或文件随后被生成, 以测试边界条件或迫使规约发生违例,这些测试用例可用于检验目标系统实现规约的精确程度。
创建这些测试用例需要事先完成大量的工作,但是其优点是在测试相同协议的多个实现或文件格式时用例能够被一致地重用。预先生成测试用例的一个缺点是,这种方式下的模糊测试存在固有的局限性。由于没有引入随机机制, 一旦测试用例表中的用例被用完,模糊测试只能结束。

(2)随机方法

这种方法是迄今为止最低效的,它只是简单地大量产生伪随机数据给目标软件,希望得到最好或最坏的结果。

(3)协议变异人工测试

在该方法中,研究者本人就是模糊器。加载完应用程序后,研究者仅仅通过输入不恰当的数据来试图让服务器崩溃或使其产生非预期结果。该方法的优点在于可以直接发挥出安全研究人员的经验和直觉,该方法最常用于Web应用程序的测试。

(4)变异或强制性测试

这里所说的强制性, 是指模糊器从一个有效的协议或数据格式样本开始, 持续不断地打乱数据包或文件中的每一个字节、字、双字或字符串。这是一个相当早期的方法, 因为这种方法几乎不需要事先对被测软件进行任何研究, 实现一个基本的强制性模糊器也相对简单直接,模糊器要做的全部事情就是修改数据然后传递它。
此种方法具有低效性, 许多CUP 周期被浪费在数据生成上, 并且这些数据并不能立刻得到解释。但这些问题所带来的挑战在一定程度上可以得到缓解, 因为测试数据生成和发送的全过程都可以自动完成。使用强制性方法的代码覆盖依赖于已知的经过测试的良好的数据包或文件。大部分协议规约或文件定义都比较复杂, 即使对它进行表面的测试覆盖也需要相当数量的样本。
强制性文件格式模糊器的例子包括FileFuzz 和notSPIKEfile , 分别对应Windows 和Linux 平台。

(5)自动协议生成测试

自动协议生成测试是一种更高级的强制性测试方法。在这种方法中, 需要进行前期的研究,首先要理解和解释协议规约或文件定义。然而, 与前一种方法不同, 这种方法并不创建硬编码的测试用例, 而是创建一个描述协议规约如何工作的文法。为了达到这个目的, 需要识别数据包或文件中的静态部分和动态部分, 后者代表了可被模糊的变量。之后, 模糊器动态解析这些模板, 生成模糊测试数据, 然后向被测目标发送模糊后产生的包或文件。
这种方法的成功依赖研究者的能力, 研究者需要指出规约中最容易导致目标软件在解析时发生故障的位置。此类模糊器的例子包括SPIKE 和SPIKEfileo 这两个模糊器都以SPIKE 脚本来描述目标协议或文件格式,并使用一个模糊引擎来创建模糊后的数据。这种方法的不足之处是需要耗费一定的时间来产生文法或数据格式的定义。

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 游动-白 设计师:白松林 返回首页