OWASP 测试指南 4.0-测试原则

对于开发一个剔除软件安全漏洞的测试方法，存在一些常见的误解。本章所涉及一些基本原则，专业人士在进行软件安全漏洞测试时应加以考虑。

0x01 没有银弹(SilverBullet)

      当你试图思考安全扫描器或应用防火墙既不能提供各类攻击防御和辨别各类安全问题的时候，实际上不存在一下子就能解决不安全软件问题的方法。应用程序安全评估软件，只能作为发现伸手就能摘到的果实的第一张通行证，通常并不能充分覆盖到应用的各个层面，从而不能提供成熟有效的详细评估。切记：安全是一个过程，不是某个产品。

0x02 战略性思考，而非策略

        在过去几年中，安全专家已经逐渐认识到90年代深入信息安全界的“补丁-渗透”测试模型存在的缺陷。该测试模型将提交一个错误报告，但并不会经过适当的调查以明确问题所在的根源。这种测试模型通常与下图中显示的安全漏洞相关联。全球通用软件中漏洞的演变表明了该测试模型的无效性。欲了解更多有关安全漏洞的信息，请参阅[6]。脆弱性研究[7]显示随着世界范围内的攻击者的反应时间增快，典型的安全漏洞并没有提供足够的时间安装补丁程序，因为安全漏洞的修补与自动攻击工具的开发之间的时间差在逐年减少。
         还有一些对“补丁-渗透”测试模型的错误猜想：补丁干扰正常运作，并可能破坏现有的应用程序，并不是所有的用户都能（最终）意识到了补丁的可用性。因此并非所有的产品的用户将适用于安装补丁，或者是由于以上这个问题或者是因为他们对补丁的存在缺乏了解。

        为了防止一个应用程序再次发生安全问题，将安全融入到软件开发生命周期（SDLC）每一个阶段，并通过制定适合有效的开发方法标准，策略和指导方针是十分必要的。威胁建模与其它技术应该用来帮助区分系统中的哪些部分的特定资源是危险的。

0x03 SDLC才是王道

       软件开发生命周期是每一个开发人员都非常了解的一个过程。通过将安全的概念纳入到软件开发生命周期中的各个阶段，可以对应用安全采用综合方法以实现该组织内各程序的平衡。不同阶段的名称可能会根据各组织所采用的SDLC模型的改变而改变，每一个原始SDLC的概念阶段都将被用来开发应用（例如，定义，设计，开发，部署，维护）。每个阶段的安全考虑都应当成为现行进程的一部分，以确保安全计划全面有效。

      现在存在多个SDLC框架，提供了描述性的和规范性的建议。无论你想选择描述性建议或者规范性建议依赖于SDLC过程的成熟度。一般的，规范性建议展示了安全SDLC过程如何发生作用，描述性建议则展示了他如何在实际生活中应用。两者都有各自不同的发挥作用的地方。例如，如果你不知道如何开始一个SDLC，那么规范性的框架提供一系列潜在安全控制手段供你选择。描述性建议通过展示其他组织如何工作的来帮你更好的做决定。描述性安全SDLC包括BSIMM-V，规范性安全SDLC包括OWASP的开发软件成熟度模型（OpenSAMM）和ISO/IEC 27034中的1-8部分，部分章节还在开发中。

0x04 及早测试、频繁测试

        漏洞及早在软件开发生命周期中被查出，它可以迅速被修补并花费较低的成本。在这里，安全漏洞可被等价看作一个功能或基于性能的漏洞。实现这个目标最关键的一步在于教育开发部门和QA部门关于常见的安全问题以及发现和防范的方法。虽然最新的图书、工具或者语言也许帮助设计更好的计划(产生少量的漏洞)，然而新的威胁频繁出现，它们的开发者必须认识到这些新威胁对他们所开发的软件所带来的影响。安全测试的教育将帮助开发者从攻击者的渗透行为中获取适用的应用程序测试思路。每个企业或组织都应将安全问题作为他们现有的责任的一部分。

0x05 理解安全的范围

        了解项目所需的安全范围非常重要。需要被保护的资料和资产应予以分类以明确它们应该被如何处理（例如，保密(Confidential)，秘密(Secret)，绝密(TopSecret)）。应就此事项与法律委员会共同讨论，以确保任何特定的安全需求都能够得到满足。在美国，像Gramn-Leach-Bliley法案[8]这样的联邦法案，如美国加州SB-1386[9]这样的州级法律都有相关的要求。对欧盟国家的组织或企业而言，国家具体法规和欧盟指引都适用。例如，96/46/EC4指引[10]强制要求，凡是涉及个人数据处理的应用应予以适当保护，而不论该应用是什么。

0x06 树立正确的思想

       成功地测试一个应用程序的安全漏洞需要超越性的思维。在正常模式下对应用程序的正常行为进行测试仅仅适用于用户按照你所预期的规则来使用应用程序。然后，良好的安全测试需要超越你的期望并像那些试图破坏该应用程序的攻击者一样思考。创新思想能够帮助你了解到在不安全的使用方式下哪些意想不到的数据可能会导致应用失败。它还可以帮你发现网络开发人员所做那些的假设往往并非总是正确的，同时了解它们如何能被破坏殆尽。这就是为什么自动化测试工具在自动进行漏洞检测时所带来的局限性：这种创造性的思维的建立必须根据案例不同而不同，同时大多数Web应用程序都采取其独特的方式进行开发的（即使他们使用普遍的框架）。

0x07 认识测试主体

         一个良好的安全计划中的第一个非常重要的步骤就是在对应用程序进行了解并准确地记录下来。其结构，数据流程图，使用情况等，都应记录为正式的书面文件并使其适于审查。技术规格和申请文件应不仅包括允许使用的情况，同时应包括下不允许使用的特殊情况。最后，至少有一个基本的安全设施是件好事，可以实时监测并应对针对组织或企业的应用及网络所发起的攻击（例如，入侵检测系统）。

0x08 使用合适的工具

  虽然我们已经说过没有万能工具，但是工具在总体安全计划中确实发挥重要的作用。有一系列的开源工具和商业工具，可以自动完成许多例行的安全工作。这些工具可以协助安全人员简化和加快安全任务进程。最重要的是理解这些工具能做什幺不能做什幺以防止他们过量销售和使用不当。

0x09 难在细节

至关重要的是不要执行表面的应用安全检查并认为这样就使完成了检测任务。这将导致一种安全假象，这与不做安全检查一样危险。仔细审核检测结果并剔除检测报告中可能存在的错误是很重要的。安全检测结果的不准确性往往也破坏了安全报告其余部分的有效信息。应当注意，确认一切可能的应用逻辑部分都已经过测试，并对每种使用情况都进行了漏洞检测。

0x010 适当情况下请使用源代码

虽然黑盒渗透测试的结果对说明产品中所暴露的弱点十分形象有效，但是它们并不是确保应用安全最为有效的方式。在适当的情况下，程序的源代码应考虑移交给安全人员以协助他们在履行其测试工作。通过这种方式可能发现黑盒渗透测试无法发现的应用漏洞。

0x11 开发指标

      一个良好的安全计划的重要组成部分就是确定事情是否能够好转的能力。跟踪测试约定结果以及开发指标十分重要，这些指标能显示组织或企业内的应用程序的安全趋势。
这些好的指标指标可以是：

是否需要更多的教育和培训；
是否存在一个对开发没有明确理解的特殊的安全机制；
发现与安全有关的问题总数是否每个月正在下降。
      从现有的源代码中可以自动产生连贯的数据，将有助于增强该组织或企业在评估机制中减少软件开发过程中的安全漏洞的有效性。指标的建立并不容易，因此使用OWASP指标项目以及其它标准组织所提供的标准指标将是一个良好的开端。

0x12 对测试结果进行文档记录

         为完成测试过程，产生一个正式的报告以记录谁、什么时间、采取了什么测试行为、以及详细的测试结果是非常重要的。明智的做法是通过商定一个所有相关方面，包括开发者，项目管理部门，企业所有者，IT部门，审计部门和执行部门都可以接受的报告模式。该报告必须清楚地为企业所有者指出存在脆弱点，以支持他们以后的漏洞排查行为。该报告必须清楚地为开发人员明确指出脆弱点所带来的影响，并附以开发人员可理解的解决方案（没有双关语意）。最后，安全测试工程师的报告写作不应过于繁琐，安全测试工程师一般并不具有非常出色的创作技巧，因此，商定一项复杂的检测报告可能会导致测试结果并不能真实地反应于报告中。使用安全测试报告模板能节约时间，并且保证测试结果能正确一致地记录，也适合阅读。

欢迎大家分享更好的思路，热切期待^^_^^ !