OWASP 测试指南 4.0-安全需求测试推导

        如果你想要有一个成功的测试项目，你需要知道测试的目的是什么。这些目的由安全要求指定。这章详细讨论了如何通过从适用标准和准则和积极和消极应用程序要求中推导出安全测试并记录安全测试要求。它也谈论安全要求如何有效地在SDLC期间使用安全测试，如何使用安全测验数据有效地处理软件安全风险。

0x01 测试目的

      安全测试的目的之一是确认安全控制能如预期一样起作用。 安全需求 文献描述了安全控制的功能。在高水平角度看，这意味证明数据和服务的机密性、完整性和可用性。另一个目的确认安全控制是在很少或没有弱点的情况下安装的。存在一些共同的弱点，例如OWASP十大漏洞和之前在SDLC期间进行安全评估所确认的漏洞，例如软件威胁建模，原代码分析和渗透测试。

0x02 安全需求文档

        安全要求文档的第一步是明白 业务需求 。一个业务需求文献能够提供最原始的、高水平的应用的期望功能的资料。例如，应用的主要目的或许可以为顾客提供金融服务或从在在线的物品目录上购物和购买物品。企业要求的安全部分应该突出表现为需要保护的顾客数据并且符合可适用的安全文献的要求，例如章程(Regulations)、标准(Standards)和政策(Policies)。
       一般一个合适的章程，标准和政策清单适合初步的Web应用安全合规性分析。例如，可以根据检查企业部门的信息和应用运行/经营的国家或者州的信息来确定是否符合章程。其中一些合规性指南和章程或许在安全控制所需要的特定技术要求上有所转换。例如，在财政应用情况下，遵照FFIEC指南认证方面[15]要求财政机关安装拥有多层控制和多因素认证功能的应用软件来应对弱认证(带来的)风险。

        可适用的安全业界标准需要由一般安全要求清单决定。举个例子，在处理顾客信用卡数据的应用情况下，遵照PCIDSS[16]标准禁止PIN和CVV2数据存贮，并且要求客户通过加密存储和传输和保密显示的方法保护磁条数据。这样通过原代码分析PCIDSS安全要求才能生效。

        清单的另一个部分需要加强对符合组织信息安全标准和政策一般要求。从功能要求来看，安全控制要求需要在信息安全标准中的一个具体章节占有一席之地。这样要求的例子可以是：“必须由应用使用的认证控制强制执行六个字母或数字字符的复杂密码。“当安全要求存在于合规性规则中时，安全测试能确认发现的合规性风险。如果发现违反信息安全标准和政策行为，就导致一些能被记录并且必须处理的风险(即，处理)。为此，因为这些安全合规性要求是可执行的，他们需要与安全测试一起记录在案并产生效果。

 

0x03 安全需求验证

        从功能上来看，安全测试的主要目标是确认安全要求。但是从风险管理角度看，确认安全要求却是信息安全评估的目标。从更高层次考虑，信息安全评估的主要目标是确认安全控制中的差异，例如缺乏基本验证、授权或者加密控制。更深入分析，安全评估宗旨是风险分析，例如在安全控制中找出潜在的弱点就保证了数据保密性，完整性和有效性。再例如，当应用程序处理了个人可识别的信息(Personal Identifiable Information,PII)和敏感数据，安全要求会按照公司信息安全策略的要求对这些数据在传输和存储过程中加密。如果加密是为了保护数据安全，那么加密算法和关键字长度需要符合组织加密标准。这也许会要求只能使用某些算法和关键词长度。例如，能通过安全测试的一条安全要求说明：只允许规定最小密钥长度的加密算法(如，对称加密长度必须超过128位和不对称的加密长度必须超过1024位)。(如，SHA-1、RSA，3DES算法)。

       从安全评估角度看，在SDLC的不同阶段，使用不同的测试工具和测试方法能证实安全要求。例如，威胁模型在设计阶段能识别安全漏洞，安全代码分析和审查能在发展阶段在源代码中发现安全问题，渗透测试能在测试/确认时在应用阶段发现漏洞。

       在SDLC较早阶段发现的安全问题需要在测试计划中记录下来，以便能使用安全测试证实这些安全问题。通过结合各种测试技术的检测结果，就能得到更好的安全测试案例，同时增加安全需求的可信度。

      例如，结合渗透测试和源代码分析的结果能区分真正的漏洞和未被利用的漏洞。例如，在了解到SQL注入漏洞的安全测试后，黑盒测试能最先使用应用扫描去发现漏洞。发现潜在SQL注入漏洞存的第一个证据就是产生了SQL exception。进一步检测SQL漏洞也许需要利用手工注入攻击载体去修改导致信息泄露的SQL查询的语法。这也许需要多次反复试验分析，直到恶意查询执行为止。如果测试者有源代码，她就能从源代码中分析出如何构建能发现漏洞的SQL攻击载体（如执行恶意查询能使未授权用户得到机密数据）。

 

0x04 威胁和对策分类

         威胁和对策分类 考虑了弱点产生根源，是证明安全控制在设计，编码和建立的重要因素。因此，利用这些漏洞所产生的    影响已经缓和。在Web应用案例中，针对普通漏洞的安全控制措施，如OWASP TOP Ten，是获得一般安全要求的一个好的开始。更具体地说，web应用安全框架[17]提供了漏洞的分类，以便能按照不同的指南和标准记载这些漏洞，在以后的安全测试中能确认这些漏洞。

      威胁和对策分类的焦点是根据威胁和弱点的起因定义安全要求。威胁可以使用STRIDE分类[18]，例如，欺骗(Spoofing)，窜改(Tempering)，否认（Repudiation），信息透露(Information Disclosure)、拒绝服务（Denial ofService）和特权提升（Elevation of Privilege）。弱点起因可以分为设计阶段的安全漏洞，编码阶段的安全漏洞，或不安全配置问题。例如：当数据在客户和应用的服务器层的可信任界外时，微弱认证漏洞的起因可能是由于缺乏互相认证。安全要求在架构设计审查阶段获得的认可威胁，并允许记录对策要求（即：互相认证）。而这些对策能在后来的安全测试中得到确认。

       弱点的威胁和对策分类同样能用于记录关于安全编码的安全要求。如，安全编码标准。认证控制中一个共同编码错误的例子包含应用Hash功能加密密码，而不是seed增加价值。从安全编码角度看来，漏洞利用编码错误中的漏洞起因影响了认证加密。既然漏洞起因是不安全编码，安全要求会在安全编码标准中记载并通过在SDLC的发展阶段进行安全编码审查确认。

0x05 安全测试和风险分析

       安全要求需要考虑到弱点的严重性从而支持一个 风险缓和 的策略。假设某组织维护一个在应用系统中发现的漏洞数据库，即：漏洞知识库，安全事件可以通过类型，事件，缓和和起因报告出来并映像到它们被发现的应用系统中。在整个SDLC过程中，这样的漏洞知识库可以也用于测量分析安全测试的有效性。

      例如，考虑到输入的验证事件，如SQL注入就是通过源代码分析被识别，并且回报错误编码起因和输入验证的漏洞类别。这样漏洞发现可以通过渗透测试评估到，即从几个SQL注入攻击矢量探测输入领域。这个测试能验证击特殊字符在到达数据库之前被过滤掉。通过结合源代码分析和渗透测试，就可能确定弱点的相似性及漏洞泄露，并计算出弱点的风险等级。通过报告研究结果中的弱点风险等级(如，测试报告)就可能决策出缓和战略。例如，高等及中等风险漏洞需优先被修补，而低风险的漏洞则可以在更后面的发布中被修补。

       通过利用普通弱点的安全威胁方案，来识别需要进行安全测试的应用程序安全控制中潜在的风险。比如，OWASP名列前十的弱点可以被映像到的攻击例如：钓鱼(Phishing)，侵害隐私(Privacy Violations)，身份盗窃(Identity Theft)、系统破坏(System Compromise)、数据更改或者数据破坏、金融损失(Financial)及名誉损失(ReputationLoss)。这些事件应该归类到威胁方案中的一部分。在考虑到安全威胁和弱点时，可以构想出一系列测试来模仿攻击情景。

       理想地说，组织的弱点知识库可以通过获得安全风险被动测试案例来验证最有可能的攻击方案。例如，如果盗用身份被确认为高风险，消极测试(Negative Test)方案就能验证密码控制、输入检验和授权控制等领域的漏洞而产生的影响的缓和方案。

 

0x06 功能和非功能测试需求

功能性安全需求

      从功能安全要求角度透视，适当的标准、政策和管理条例推动了安全控制的类型的需求和控制功能性的发展。这些要求同时被称为“正面的要求”，因为他们阐述的预期的功能性可以通过安全测试验证。正面要求的例子是：“6次登录失败后，应用系统将会锁住用户”，或者“密码必须至少6个字符，字母数字型”。正面要求的验证是由断言的预期功能组成，它能在重建的测试条件中进行测试；并根据预定义的输入运行测试断言预期的输出情况是“失败/正常”条件。为了安全需求能通过安全测试验证，安全需求必须是功能驱动的，并且突出预期的功能(做什么)以及隐含的实现(如何做)。用于认证的高级安全设计要求的例子：

保护用户认证信息和共享的传输中和存储中的秘密；
在现实中隐藏所有保密信息(即，密码，帐户)；
在一定数量的登录失败后，锁定用户帐号；
用户登录失败后不显示具体失败信息；
只允许输入由字母数字并且包含特殊字符组成的至少六个字符的密码，以限制攻击层面；
用户要修改密码，必须通过旧密码、新密码、对密码问题的回答的验证，以防止通过密码修改功能对密码进行穷举(Brute Force)搜索攻击。
采用密码重置功能时，系统将临时密码发送到你指定的邮箱之前，需验证用户注册时的用户名和邮箱地址。该临时密码只能使用一次。一个密码重置的网页链接将发送给用户。密码重置网页应该验证用户的临时密码，新密码，以及用户对密码问题的回答。

 

风险驱动的安全需求

      安全测试也是需要风险控制的，也就是他们需要验证非预期的行为。这些也称为“负面要求”，因为他们指定应用系统什么不应该做。“不应该做”(负面)要求的例子：
应用系统不允许修改或毁坏数据；
应用系统不允许被破坏或者被恶意用户用于未认证的金融交易事务。
      负面要求更难测试，因为找不到预期的行为。这就要求一个安全威胁分析员能应对不可预知的输入条件、起因和影响。这就是安全测试中的需要控制的风险分析和威胁模型。关键是将安全方案文档化并将对抗措施功能作为一个缓和安全威胁的因素。
例如，在认证控制的情况下，以下安全要求可以从威胁和对抗措施透视中文档化：
加密在传输和存储过程中的认证数据，以缓和信息泄露和认证协议攻击的危险；
使用不可反向解密方式加密密码，如使用一个摘要(digest)(如HASH)和一个种子(seed)防止字典攻击；
在达到一定数量的登录失败后锁牢帐户，并增强密码的复杂性来缓和穷举密码攻击的风险；
在身份验证错误输入显示笼统的错误信息，以缓和帐户的捕获/列举风险；
客户端和服务器相互认证防止非否认和中间人(ManintheMidle,MiTM)攻击。
        软件威胁建模的加工物，如威胁树(threat trees)和攻击库(attack libraries)对于推导出负面测试案例是很有效的。一个威胁树假设一个根源攻击(即，攻击者可能读取到其它用户的信息)，然后识别所采用的不同的的安全控制类型(例如，由于SQL注入漏洞而使数据验证实效)和必要的对抗措施(例如，实现数据验证和参数化查询(parameterized queries))，这样做就能有效地缓和这种攻击。

 

0x07 安全需求在使用和误用中的衍生

       在描述应用系统功能之前必须了解的是：应用系统是用来做什么的，怎样做的。这些可以从描述的使用案例中了解到。 使用案例 ，在软件工程中常以图解形式使用，展示执行者间的互作用与相互关系，帮助识别应用系统中的执行者身份、关系、每个方案行为的设想结果、可选择的行为、特殊要求，前期和后期条件。

        相似于使用案例， 误用和滥用案件 [19]描述应用系统中的未计划与恶意使用方案。这些误用案例提供一个方案描述攻击者怎样误用和滥用应用系统。通过审阅使用案例中的各个步骤并思考是如何被恶意利用的，就能发现未被很定义好的潜在漏洞和应用系统部分。关键是描述所有可能性，或至少描述最重要的使用和误用方案。

        误用方案中允许从攻击者的观点分析应用系统，并且致力于识别潜在漏洞和对抗措施,这些对抗措施是用于缓和由这些潜在漏洞泄漏引起的冲击。在所有使用和滥用案例中，非常关键的一点是分析并确定他们之中哪些是最关键的部分并且需要写入安全要求。最重要的使用和滥用案例识别促使了安全要求的文档化和控制缓和风险的必要性。

       从使用和滥用案例[20]中要获得的安全要求时，重要的是定义功能情景和消极情景，并建成图解形式。在安全要求验证的衍生的案例中，可以根据以下方法逐步学习。
        第1步：描述功能情景：用户通过提供用户名和密码认证。用户通过应用系统的身份认证访问系统，当认证失败时为用户提供具体的错误信息。
        第2步：描述消极情景：在应用系统中，攻击者通过穷举或字典攻击密码与账户捕获漏洞破解认证。验证失败时提供的具体信息使攻击者能猜测到哪些帐户实际上是合法的注册账户(用户名)。然后。穷举攻击者能在有限的次数内成功破解至少，攻击者将试着穷举破解一个合法的帐户的密码。穷举攻击者能在有限的次数内成功破解至少4位数长度的全数字密码。
        第3步：在使用和用案例中描述功能和消极情景：在如下的图解中，显示了通过使用和误用案例的衍生安全要求。功能情景包括用户行为(输入用户名和密码)和应用行为(认证用户或提供认证失败信息)。误用案例包括攻击者行为，即：设法通过字典攻击穷举破解密码以攻破认证，并从提示的错误信息中猜测合法的用户名。通过图解可以看到用户操作可能造成的威胁(误用)，就有可能通过对抗措施缓和应用行动可能带来的威胁。

      第4步：安全需求总结：在这种情况下，可以获得用于认证的安全要求：
1. 密码必须是由字母（大小写）和数字组成的七个字符以上的字符串组成
2. 五次登录尝试失败以后，账户锁定
3. 登录失败信息不具体显示
    这些安全要求需要文档化和经过测试。

 

 

 

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