频道推荐

热点文章

测试应用：对定制软件应用执行安全测试(图)

中国市场调查网时间：2010年8月25日来源：IT168.com

　　早期修复VS 发布后修复

　　Gartner，IBM和NIST的研究表明在设计/开发阶段清除应用的安全漏洞要比在生产阶段清除这些漏洞少花费30-60倍的成本。在软件开发生命周期内(SDLC)整合安全进程的关键目标是确保我们能查找并修复早期安全漏洞。

　　许多企业不了解寻找和修复软件漏洞的成本，因为他们没有跟踪并权衡这项工作。如果他们有的话，可能会对开发软件的真正成本表示惊讶。查找和修复安全漏洞的过程中存在直接成本和间接成本。如果有漏洞被找到并利用在产品应用中，那么对品牌的损害将无法估量且难以弥补。

　　直接成本我们尚可以计算。而编写修复代码的平均成本是最易于计算的：

　　编写修复代码的平均成本=(程序员的人数×每人的日需成本)+ 修复的漏洞数量。除了这一成本，还有些额外成本需要考虑：

　　系统测试成本

　　执行成本

　　系统成本

　　后期成本

　　其他成本，如项目管理，文档和停工期成本等。

　　当涉及关键任务和受瞩目的应用时，这些成本也会水涨船高，可是却不能让使用互联网应用的客户看到这种变化，如网上银行的页面。

　　因此，对于企业而言，在发布进入生产环境之前就寻找和修复应用软件漏洞是更为明智的选择。虽然对威胁建模，设计还有架构有助于确保不会有设计以内的高级别漏洞出现，但是安全测试可以保障执行安全设计的时候不会有漏洞。有若干技巧可在测试某应用安全性时使用。这些技巧从简单的程序员驱动型单元测试，到专业安全团队的渗透测试不等。

　　测试阶段

　　典型的软件开发测试一般出现在多迭代阶段。这些阶段都可能存在安全和弹性测试，而且可以用下列词语来表述：

　　单元测试

　　整合性测试

　　质量保障测试

　　用户接受度测试

　　单元测试

　　程序员对自己编写的代码执行单元测试。单元测试是对代码的质量进行整体测试且具有一定的安全优势。单元测试有助于阻止漏洞进入更高级的测试阶段。由于程序员比其他人更了解自己的代码，所以简单的单元测试就足以保证测试的有效性。

　　程序员需要记录下自己的测试情况，因为手动测试的步骤很容易被忘记。程序员可以在单元测试中找到的以下内容：

　　边界条件

　　整数溢出/整数下溢

　　路径长度 (URL，文件)

　　缓冲溢出

　　用C语言编写代码和编写其内存管理事务时，所有相关计算都应该被测试

　　程序员也可以用模糊测试(Fuzzing)技巧执行直接的安全测试。模糊测试，简而言之，是将随机数据发送到程序所依赖的应用程序界面，再确定它是否会，何时会损坏软件。模糊测试通常通过多重迭代完成，而且如果在数据结构的关键部位有针对性的变化则可以获得更好的效果。模糊测试是许多程序员都乐于使用的方法。而它也是识别安全漏洞最便宜，最快捷和最有效的方法，即便是拿下具备成熟SDLC安全性和弹性的企业也是如此。

　　手动源代码审查

　　当开发进程中有足够的代码进行审查时可进行手动源代码审查。手动源代码审查通常仅限于寻找代码级的可能导致安全漏洞的疏漏。代码审查不是用来揭示以下内容：

　　有关业务需求却不能被安全执行的问题

　　有关应用特殊技术的选择事项

　　可能导致漏洞的设计事项

　　源代码审查通常不会担忧漏洞被人利用。从审查中找到的结果会被通过其他方式找到的结果一样对待。代码审查对可用于非安全查找，只要它们有可能影响代码的整体质量。代码审查通常不仅会导致安全认证的问题，而且会导致无作用程式码，冗余码，不必要的复杂性或其他问题。所有查找出的结果都遵循自己的优先性，而这些优先性通常都被定义为企业内部的“漏洞优先矩阵”。漏洞报告通常包含一个特定的补救推荐措施以便程序员可以适当对其进行修复。

　　手动代码审查的成本比较高，因为它设计许多手动操作且需要安全专家进行辅助审查。但是，就准确性和质量而言，手动审查物有所值。它们可以帮助我们识别自动静态代码分析器无法识别的逻辑漏洞。

　　源代码审查通常被称为“白盒”分析。这是因为这类审查对内部设计，威胁模式和其他有关应用的系统文档都十分了解。而“黑盒”分析是从旁观者的角度来审查应用，因此没有应用的内部情况有详细了解。“灰盒”分析是介于黑盒与白盒之间的一种分析，我们稍后会对此再做介绍。

　　代码审查进程

　　代码审查进程始于项目管理团队和开发团队，目的是确保有足够的时间和预算分配给SDLC来执行此类审查。所有程序员和审查员都应该有权使用有利于执行此类审查的工具。代码审查进程包括图8.1中列出的四个高级步骤：

　　图8.1

　　代码审查的第一步是了解被执行的应用，该应用的内部设计以及威胁模式。了解这些可以极大地帮助我们识别代码中的关键组件并将优先权分配给它们。事实上，我们并不能保证每次都有足够的时间对代码进行逐行审查。因此，非常有必要了解代码的关键所在并确保这些关键部分可以被全面审查。

　　第二步是在优先部分的基础上对识别的关键部分进行审查。这样的审查可以由不同团队程序员来执行。另一个方法是让相应开发团队的程序员对所有代码执行同级审查。不管代码审查是否完备，还是有必要将审查覆盖到关键部分从而使程序员和安全专家都有机会看到这些部分。所有识别出的漏洞必须用企业的漏洞管理工具记录在案，再对其分配合适的优先权。审查者必须将推荐的修复方案和这些漏洞一起记录下来以确保这些错误不会进入最后的生产代码中。

　　代码审查的第三部是与应用代码编写者进行协调，帮助他们执行修复。这其中可能涉及已有的，可重复的安全组件的整合，或者它会提出代码由简化繁的请求以及后续审查。

　　最后一步是学习审查周期，吸取改进的部分。这样可以让下次代码审查更有效。

　　要求进行深层驱动审查和分析的关键组件有：

　　用户身份验证和授权验证

　　数据保护

　　从受信任的数据源接受并处理数据

　　数据验证

　　涉及异常条件处理的代码

　　操作系统资源和网络的使用

　　低端架构代码

　　嵌入式软件组件

　　有问题的API的使用情况

　　由于手动分析耗时费力，企业还应该部署自动源代码分析工具作为补充(但是不能替代手动审查的作用)。

　　自动源代码分析

　　大中型企业不能保证每次执行代码审查时对所有应用都逐一排查。相反，许多审查可能都依赖于自动源代码分析器的帮助。

　　典型的软件开发优先项包括日程，功能和质量——在大多数情况下，它们的先后顺序就是如此。时间和市场的双重压力对软件之类和弹性都有负面影响，有时甚至会推迟软件新功能的增加。

　　负责软件开发的企业经理通常都相信：对软件质量的偏重会增加开发成本并延迟项目。对于软件质量的研究则证明了这是悖论。具备成熟SDLC进程的企业通常因软件质量和弹性所支付的额外费用并不多，而从代码改进中节约的成本要大于因提高质量而付出的成本。

　　静态源代码分析器支持用查找和列出代码库潜在安全漏洞的方式保护程序的开发。它们提供了大量有关代码库安全趋势的分析报告，而这些报告可作为一种有效机制来收集指示进程和软件安全成熟度的矩阵。源代码分析器的运行速度极快，可以节约大量人力。自动工具也为每个漏洞提供了风险级别，这样有助于企业对补救措施进行优先。

　　更重要的是，自动代码分析器可以帮企业在SDLC中早一点发现未覆盖的漏洞，这样便可以节省开支。

　　1 自动审查与手动审查作比较

　　尽管自动源代码分析器可以在减少额外成本的情况下执行审查，可以捕捉典型的漏洞，可以扩展代码还可以快速执行重复任务，但它仍然存在不足。自动工具会出现大量误报的情况。有时可能会让企业花上几个月来调试工具以减少误报，但是某些级别的误报还是会存在。源代码分析器在寻找业务逻辑漏洞方面的能力不足。某些自动分析不能查探出的攻击类型是复杂的信息泄露，设计漏洞，主观漏洞，如假冒的跨站点请求，居心不良的竞态条件和多步骤进程攻击。

　　2 有偿/免费的源代码分析器

　　下面是一些源代码分析器，包括有偿的，免费的和开源的软件。

　　有偿的软件——多语言

　　Armorize Codesecure——带网页界面的工具，多种嵌入式语言，支持ASP.NET, VB.NET, C#, JAVA/J2EE, JSP, EJB, PHP, Classic ASP和VBScript。

　　Coverity Software Integrity——识别安全漏洞和代码漏洞，支持C，C++，C#和Java。

　　Compuware Xpediter——适合基于主框架的应用，提供COBOL，PL/I，JCL， CICS，DB2，IMS和其他主流主框架语言的分析。

　　Fortigy 360——帮助程序员识别软件安全漏洞，支持C/C++，NET，Java, JSP, ASP.NET, ColdFusion, Classic ASP, PHP, VB6, VBScript, JavaScript, PL/SQL, T-SQL和COBOL以及配置文件。

　　KlockworkInsight和适合Java程序员的Klockwork ——提供安全漏洞的检查以及架构的分析，支持C，C++，C#和Java。

　　Ounce Labs——自动源代码分析，可以让企业识别并消除软件中的安全漏洞，支持Java，JSP，C/C++，C#，ASP.NET和VB.NET。

　　开源软件——多语言

　　以下是用于源代码分析的开源产品。

　　O2——开源模式集合，有助于Web应用安全专家最大化自己的努力，通过自动化应用安全知识和工作流程，可以快速获得应用安全文件的可视性。