测试空间中的安全性准则

 

测试空间中的安全性准则

测试空间属于软件基础性知识，下面介绍一些关于测试空间方面的安全性准则，这些准则可用于软件安全性设计、软件接口设计、安全性测试等方面。

1 安全性准则1：测试空间必须尽量小且容易构造

软件所有的安全性方面的缺陷都来自测试空间，一个有安全性需求的软件，必须让测试空间在满足需求的情况下尽可能的小。测试空间过大，遗留未测的空间就随之增大，这会给攻击者留下许多攻击的余地。例如，一个界面中输入的字符串，如果实际情况下字符串的长度最多不超过16字节的话，那么就可以在界面中限制输入的字符串长度不超过16字节。这样就限制了测试空间的大小，否则测试时就要测试超过16字节长度以上的各种异常情况。超过16字节长度后，通常会发生缓冲区溢出，缓冲区溢出后的情况就很复杂了，如果一个登录程序发生缓冲区溢出，那么其他无授权用户的人员可以利用这个缓冲区溢出漏洞登录进去。

测试空间光小还不行，还得容易构造，这样测试起来代价才小，而且容易达到较高的覆盖率。如果构造难度大的话，测试时难以将测试空间覆盖全，会给攻击者留下余地。因此许多黑盒测试时难以构造的测试数据都需要在白盒测试时构造出来进行测试。

2 安全性准则2：在测试空间和设计空间之间建立最严格的转换规则

即使设计空间已经做到了满足需要情况下的最小化，如果在测试空间向设计空间的转换过程中，如果转换后的空间比设计空间大很多，那么在多出的空间里，攻击者将可以仍然利用合法手段来进行攻击。

unix系统中就存在着PATH环境变量欺骗的问题，普通用户可以利用一些系统调用或调用外部命令的程序来达到变成超级用户的目的。主要的原因就是因为那些程序执行外部命令时依赖于PATH环境变量，攻击者将PATH环境变量改变后，将会导致执行攻击者指定目录下的同名程序。这种对执行的外部程序没有进行严格的校验给攻击者提供了机会。

所以建立最严格的转换规则是很有必要的，一旦转换规则不严格，异常空间可能就会成为攻击的温床。

3 安全性准则3：在外部输入层进行设计空间转换规则校验

所有的攻击数据都必须通过外部输入层才能进入程序内部，所以必须对外部输入层的数据进行设计空间转换规则校验，让符合设计空间条件的数据通过，拒绝掉那些异常空间内的数据。这样将使得在异常空间内发生攻击的几率大大降低。例如一个程序需要接受一个0～100的整数输入，那么在输入界面上就应该校验输入的数据是否在0～100范围内，如果不在范围则提示输入错误，让用户重新输入。

在转换的过程中还需要保证类型安全，否则转换过程中存在缺陷也会给攻击者提供机会。

4 安全性准则4：测试空间各层异常空间的交集要尽可能的小

测试空间各层的异常空间交集要尽可能的小。换句话说就是测试空间中的外部输入层，接口层，实现层的交集必须尽可能地向设计空间靠近。如下图所示：

图10-1-1 测试空间各层交集示意图

为什么需要保证各层异常空间的交集尽可能小呢？因为各层空间在向设计空间的转换过程中都有可能存在遗漏，而遗漏发生在它们的交集的话，那么交集将变成攻击者的突破口。如果它们的交集和设计空间的差别很小的话，那么留给攻击者最容易进行攻击的异常空间也将变得很小。

需要说明的是非交集部分的异常空间也是可能被攻击的，因为测试空间转换为设计空间的代码可能存在缺陷，从而使得在非交集里发生攻击成为可能。

5 安全性准则5：设计空间必须在满足需求情况下尽可能的小

设计空间如果过大的话，给攻击者留下的余地则更多，因为攻击者可以通过合法的途径来构造攻击手段，这种攻击将是防不胜防。

著名的DoS攻击就是这方面的实例，之所以可以进行DoS攻击，原因之一就是Internet上没有建立公平流量规则以及服务器中没有对短时间内的大量连接进行拒绝的机制。专业点地说就是网络传输数据的设计空间没有最小化造成的。

设计空间缩小的前提是满足需求，如果不满足需求而将设计空间定得过小的话，同样会造成严重问题，比如千年虫问题就是将设计空间定得过小而满足不了需求。千年虫问题在20世纪未成为了世界性的大问题，成为计算机历史里的最重要事件之一，就是因为少了两个字节的设计空间。

设计空间过小一般会因为满足不了需求而造成溢出，比如内存越界，数值溢出等情况。所以设计合理的设计空间对提高软件的安全性有很大帮助。

6 安全性准则6：各层的测试空间都必须大于设计空间

软件中由于需求缺陷或设计缺陷等原因，有时会出现局部的测试空间小于对应的设计空间的情况：比如一个命令行程序，用户输入的命令及参数可以超过1024字节的合法字符串，但在实现的过程中，接受用户输入部分的程序使用的缓冲区大小为4096字节，但是到了命令的具体处理函数里面，却将其拷贝到一个只有1024字节大小的字符数组里，那么就会造成内部实现层的测试空间小于设计空间的情况。

一旦出现测试空间小于设计空间的情况，要么程序内出现溢出性错误或计算错误，要么需求得不到满足。就象上面例子中，如果命令具体处理函数里拷贝字符串时没有校验源字符串长度，将造成缓冲区溢出错误，而如果校验了长度的话，则功能无法得到实现，需求无法得到满足。

7 安全性准则7：测试空间高覆盖率原则

缺陷空间在未完全测试时是无法知道的，这个问题在第3章《测试用例设计方法》里会仔细讨论。但是由于测试空间巨大又无法对软件进行完全的测试。如何让选择的测试用例达到很高的测试空间覆盖率呢？在这里先了解一下相关的话题。

首先在分析出已知的缺陷空间里，测试用例要达到100％的已知缺陷空间覆盖率。然后在此基础上继续添加新的用例：对于边界条件来说，各种边界都要考虑；对于等价类来说，可以在各个等价类里各自随机选取一些数据作为测试数据；对于分类推理法来说，分类分得越细越好。

添加了新的测试用例后，对已知的缺陷空间来说，覆盖率仍然是100％，并没有提高，但是对整个缺陷空间来说，添加的测试用例覆盖它的概率大大增加了，整个测试空间的覆盖率自然也大大增加了。当然到底需要添加多少用例，取决于软件对安全性需求的程度与软件所能取得的经济效益。不能无限制地添加用例使得开发测试的总成本超过所能取得的收益。

所以需要在满足一定经济成本的前提下尽可能地提高测试空间的覆盖率，以增加软件的安全性。

8 安全性原则8：异常空间内的处理要尽量简单

软件中对异常空间的处理一般要尽量简单，如果已经判断出属于异常空间内的数据应该以最简单的方式处理它。否则对异常数据的处理过程可能存在漏洞被攻击者利用。

如果是网络服务器软件，收到客户端异常数据应该马上关闭网络连接。尽量不要给客户端任何响应信息，最多在规定时间内只响应一次，否则很容易被利用来进行攻击。著名的Ping flood攻击就是Internet上的差错与控制报文协议引起的问题。

以上讲的是软件安全性方面的一些基本准则，属于软件安全的必要条件但不是充分条件，仅仅满足以上准则并不能代表软件是安全的。第1章中讲过软件测试就是一个寻找测试空间、设计空间与缺陷空间，验证设计空间是否得到正确实现，验证异常空间是否引起问题的一个过程。验证设计空间是否得到实现是一个很重要的内容，设计空间的验证不仅是验证数据合法性，还包括过程中是否存在问题。软件在处理可测数据的整个过程里仍然可能存在许多漏洞，导致软件遭受攻击成为可能。

本文摘自《软件测试实践》，周伟明著