2.2 实施阶段—单元测试

　　受测试方式的影响，开发者对软件安全风险的评估不可能面面俱到。最典型的就是在代码设计阶段，开发者可以通过单元测试来检验代码行为，这些结果都是可以预知的，但是受到范围的局限，不能测试这些类或者模块集成后的行为。

　　实施单元测试可以从软件基本单位（单个类）的检测上保证输人的有效性；在可能出现恶意攻击的地方，也可以利用这一思想来组织针对单个类或者方法的单元测试，从而组织起软件内部的纵深防御策略，防止恶意行为对软件安全造成的损害。但是，这一方法将软件各组件进行强制孤立，因此对于因大量组件交互而引起的软件缺陷，利用此种方法无法检测。

　　单元层的安全测试比较适合于防止缓冲区溢出，格式化字符串以及数据缺失的审核。

　　2.3 验证阶段—集成测试

　　在集成层，软件的整体安全属性变得可见和可测试，使得这一层的可测试属性数量相对单元层而言要多得多，但是对于跨站脚本和网络服务器提供的一些服务（例如安全套接层SsL和URL过滤）的测试，存在一定的困难。我们可以将实际案例和风险分析的结果作为组织集成测试的指南。

　　集成测试要求测试人员通过安全测试培训，并且是有熟练技术的软件开发人员。

　　在这一层，我们可以开展诸如注人缺陷验证、旁路验证以及访问控制等方面的安全测试，来源于外部代码的安全审查结果也应该以集成测试的方式加以确认。

　　2.4 发布阶段—验收测试

　　验收测试是软件产品交付客户之前的最后一个测试阶段，是在真实的测试环境中，利用基于恶意事件的安全检测模板，测试在典型的渗透活动中可被识别的安全缺陷。验收测试的这一特性（基于安全检测模板），使得我们可以借助于强大的自动化测试软件进行检测，并且可以用验收测试的结果来完善渗透测试报告内容，从而有助于开发人员理解软件的脆弱性以及针对软件脆弱性所采取的补救措施是否有效。

　　验收测试针对软件的外部API，因此不如单元测试和集成测试松散，并且只能测试当前已知且暴露的漏洞或者缺陷。非定制的商业软件重新设计的关键功能或者其他改变都会影响到软件的整体安全性，因此，如果改变会使得软件产生不可预知的缺陷，针对这些缺陷的测试就应该在单元层或者集成层开展，而不是在验收层。

　　在验收层，我们可以测试针对解释性程序（SQL， XPATH，LDAP等）的注人式攻击、跨站脚本攻击、跨站请求伪造等。缓冲区溢出及格式化字符串等软件缺陷也可以在验收测试层得到检测。

　　3、安全测试队伍

　　软件测试一度被认为是编程能力偏低的员工的工作，直到今天，仍然有许多公司把优秀的人才安排在编码工作上，也有更多公司让优秀的人才进行设计，仅有很少公司让优秀的人才进行测试工作。实际的软件工程实践证明，让对软件思想有深刻理解的工程师进行软件测试，可以大幅度地提高软件质量软件供应商还必须认识到组织测试人员进行“安全进修”对安全测试的成功实施至关重要。在这些情况下，软件供应商必须负责对其工程人员进行适当教育。根据组织的规模和可用的资源，拥有大批工程人员的组织可建立一个内部计划对其工程师进行在职安全培训，而小型组织则可能需要依赖外部培训。

　　测试人员要像攻击者那样带有“恶意的”想法去思考，而且在测试软件时还要扮演攻击者，攻击自己的系统，以此来帮助发现软件的安全漏洞。安全测试并不会总是直接导致安全溢出或者暴露可利用的漏洞，从而引出安全缺陷。要安全测试尽可能地发挥作用，测试人员需具备较强的分析能力，而这更多的是依靠熟练的开发技术和开发经验。

　　4、漏洞举例：一个SQL的注入式漏洞

　　有几种情形使得SQL注人攻击成为可能。最常见的原因是，使用拼接形成的SQL语句去操作数据库。譬如，传入用户输人的管理员用户名和密码，把这2个参数拼接形成SQL语句，通过执行该SQL语句，以便验证用户输人的管理员用户名和密码的正确性。具体过程如下：