产品安全性测试管理安全性测试是安全的软件住命周期屮一个重要的环节。进行安全测试需要精湛的攻击技术、敏锐的黑客思维和丰富的开发经验。这些测试人员往往被称作TigerTeam>EthicHacker^Penetrationtester或者Pen-testero大型的软件公司一般都有自己的产品安全部专职负责软件的安全测试，有时也会雇仰来自于安全咨询公司的安全专家实施攻击测试。一次安全性测试实际上就是一轮多角度、全方位的攻击。由于系统安全所特有的“木桶效应”，测试的全面性对安全测试人员的要求更高，他们不能像攻击者那样止步于一个漏洞，而是婆抢在攻击者Z前尽可能多地找到产品中的“所有”漏洞，以减少产品遭到攻击的町能性。与攻击者比起来，安全测试人员也有一定优势，就是他们能够获得更多的技术支持，比如来自开发团队的技术文档等。如果软件牛命周期中没有安排安全性测试环节，也不用担心这些漏洞发现不了——攻击者会为您的产品做这类测试，只是测试的结果和攻击代码可能会肓接向全世界公布出来，用Oday曝光的方式毁掉公司的声誉。普通的功能性测试的主要冃的是“确保软件能够完成预先设计的功能”；而安全性测试的主耍n的是“确保软件不会去完成没有预先设计的功能”。安全性测试非常灵活，需要像黑客一样思考，有时英至需要一点灵感，因此没有固定的步骤可以遵循。这里给出一些通用的思路和方法，希望这些归纳出的攻击思路能够抛砖引玉，启发您设计出恰当的测试方案。(1)畸形的文件结构：畸形的Word文档结构、畸形的mp3文件结构等都可能触发软件屮的漏洞。FileFuzz是测试这类漏洞的好方法。(2)畸形的数据包：软件中存在客户端和服务器端的时候，往往会遵守一定的协议进行通信。程序员在实现时往往会假定用户总是使用官方的软件，数据结构总是遵导预先设计的格式。试着白己实现一个伪造的客户端，更改协议中的一些约定，向服务器发送畸形的数据包，也许能发现不少问题;反Z,客户端在受到“出乎意料”的服务器端的数据包时，也可能遇到问题。(3)用户输入的验证：所有的用户输入都应该进行限制，如长字符串的截断、转义字符的过滤等。在Web应用中应该格外注意SQL注入和XSS注入问题，SQL命令、空格、引号等敏感字符都需耍得到恰当的处理。(4)验证资源Z间的依赖关系：程序员往往会假设某个"1文件是存在的，某个注册表项的值符合一定格式等。当这些依赖关系无法满足时，软件往往会做出意想不到的事情。例如，我曾遇到过某些软件把身份验证函数放在-•个dll文件中，当程序找不到这个文件时，身份验证过程将被跳过！⑸伪造程序输入和输出时使用的文件：包括dll文件、配置文件、数据文件、临时文件等。检杳程序在使用这些外部的资源时是否采取了恰当的文件校验机制。(6)古怪的路径表达方式：有时软件会禁止访问某种资源，程序员在实现这种功能时可能会简单地禁用该资源所在的路径不被访问。但是‘Windows的路径表示方式多种多样，很容易漏掉一些路径。例如，表17-3-1列出了一些对WindowsXP下计算器程序访问的路径表达方式。表17-3-1WindowsXP下计算器程序访问的路径访间WindowsXP下计算器程序的不同方式说明C:\WINDOWS\system32\calc.exe普通的绝对路径C:/WINDOWS/system32/calc.exeUNIX路径恪式\\?\c:\WINDOWS\system32\calc.exe通过浏览器或ru门访间file://C:\WINDOWS\system32\calc.exe通过浏览器或HJ门访间%windir%\system32\calc.exe通过环境变壘访间\\127.0.0.1\C$\WINDOWS\system32\calc.exe卄*=■广舸•1«U3-i.丄、」*-1111C:\WINDOWS\..\WINDOWS\.\system32\calc.exe路径回溯C:\WINDOWS\.\system32\calc.exe路径回溯在使用了UTF-8编码Z后的CRL路径更加五花八门，在做安全测试时应该确认被禁止使用的资源能够彻底被禁用。(7)异常处理：确保系统的异常能够得到恰当的处理。在Web丿应用中应当着重确保服务器不会把错课信息未经处理地显示给客户端，因为错课信息的肓接反馈很可能会造成敏感信息泄露，为注入攻击者提供深度入侵的线索。以我个人的经验，没有经过安全测试的网站很容易岀现这个问题。(8)访问控制与信息泄露：很多Web开发人员会假设用户不知道Web目录结构，并总是首先访问Web根目录下...