关于软件测试中产品的安全性测试

　    安全性测试是安全的软件生命周期中一个重要的环节。
　　进行安全测试需要精湛的攻击技术、敏锐的黑客思维和丰富的开发经验。这些测试人员往往被称作Tiger Team、Ethic Hacker、Penetration tester或者Pen-tester。大型的软件公司一般都有自己的产品安全部专职负责软件的安全测试，有时也会雇佣来自于安全咨询公司的安全专家实施攻击测试。

　　一次安全性测试实际上是一轮多角度、全方位的攻击。由于系统安全所特有的“木桶效应”，测试的全面性对安全测试人员的要求更高，他们不能像攻击者那样止步于一个漏洞，而是要抢在攻击者之前尽可能多地找到产品中的“所有”漏洞，以减少产品遭到攻击的可能性。与攻击者比起来，安全测试人员也有一定优势，是他们能够获得更多的技术支持，比如来自开发团队的技术文档等。

　　如果软件生命周期中没有安排安全性测试环节，也不用担心这些漏洞发现不了??攻击者会为您的产品做这类测试，只是测试的结果和攻击代码可能会直接向全世界公布出来，用0day曝光的方式毁掉公司的声誉。

　　普通的功能性测试的主要目的是“确保软件能够完成预先设计的功能”；而安全性测试的主要目的是“确保软件不会去完成没有预先设计的功能”。

　　安全性测试非常灵活，需要像黑客一样思考，有时甚至需要一点灵感，因此没有固定的步骤可以遵循。这里给出一些通用的思路和方法，希望这些归纳出的攻击思路能够抛砖引玉，启发您设计出恰当的测试方案。

　　（1）畸形的文件结构：畸形的Word文档结构、畸形的mp3文件结构等都可能触发软件中的漏洞。File Fuzz是测试这类漏洞的好方法。

　　（2）畸形的数据包：软件中存在客户端和服务器端的时候，往往会遵守一定的协议进行通信。程序员在实现时往往会假定用户总是使用官方的软件，数据结构总是遵守预先设计的格式。试着自己实现一个伪造的客户端，更改协议中的一些约定，向服务器发送畸形的数据包，也许能发现不少问题；反之，客户端在受到“出乎意料”的服务器端的数据包时，也可能遇到问题。

　　（3）用户输入的验证：所有的用户输入都应该进行限制，如长字符串的截断、转义字符的过滤等。在Web应用中应该格外注意SQL注入和XSS注入问题，SQL命令、空格、引号等敏感字符都需要得到恰当的处理。

　　（4）验证资源之间的依赖关系：程序员往往会假设某个dll文件是存在的，某个注册表项的值符合一定格式等。当这些依赖关系无法满足时，软件往往会做出意想不到的事情。例如，我曾遇到过某些软件把身份验证函数放在一个dll文件中，当程序找不到这个文件时，身份验证过程将被跳过！

　　（5）伪造程序输入和输出时使用的文件：包括dll文件、配置文件、数据文件、临时文件等。检查程序在使用这些外部的资源时是否采取了恰当的文件校验机制。

　　（6）古怪的路径表达方式：有时软件会禁止访问某种资源，程序员在实现这种功能时可能会简单地禁用该资源所在的路径不被访问。但是，Windows的路径表示方式多种多样，很容易漏掉一些路径。例如，表17-3-1列出了一些对Windows XP下计算器程序访问的路径表达方式。

　　表17-3-1　Windows XP下计算器程序访问的路径

访问Windows XP下计算器程序的不同方式 说明
C:WINDOWSsystem32calc.exe 普通的路径
C:/WINDOWS/system32/calc.exe UNIX路径格式
\?c:WINDOWSsystem32calc.exe 通过浏览器或run访问
file://C:WINDOWSsystem32calc.exe 通过浏览器或run访问
%windir%system32calc.exe 通过环境变量访问
\127.0.0.1C$WINDOWSsystem32calc.exe 需要共享C盘
C:WINDOWS..WINDOWS.system32calc.exe 路径回溯
C:WINDOWS.system32calc.exe 路径回溯

　　在使用了UTF-8编码之后的URL路径更加五花八门，在做安全测试时应该确认被禁止使用的资源能够彻底被禁用。

　　（7）异常处理：确保系统的异常能够得到恰当的处理。