OWASP测试指南 4.0

OWASP的宗旨:技术的开放与协作

preface

  1. OWASP各个指南

  • 开发指南:指导设计和开发安全的应用程序
  • 代码检测指南:如何为代码做安全检测
  • 测试指南(目前正在看的这个):指导如何验证应用程序的安全性
  1. 不同角色需要这份指南

  • 开发者:确保编写代码的安全性,这些测试应成为实例代码的一部分
  • 软件测试人员和QA人员:使用该指南扩充测试案例,期望更早找到漏洞,节约时间
  • 安全专家:将指南与技术结合确保没有遗留的安全漏洞
  • PM:思考这份指南的意义,确保能够界定设计和编码中的bug是安全问题
    应用安全测试应在有限的时间内尽可能覆盖应用程序的各个方面,通过建立安全威胁模型确定公司最关心的安全问题是什么,最终得到一份包含优先次序的待测试安全清单
  1. 关于自动化工具

工具无法使软件更安全,只能缩小整个过程,并帮助加强策略。

工具并不针对特定的自定义代码,即使能找出部分问题,但并没有对应用程序足够的了解,无法对可能存在的大多数安全漏洞进行检测
最严重的问题往往不具有代表性,而是隐藏在业务逻辑和应用设计中的

1、测试指南简介

  1. OWASP测试项目

    希望OWASP项目帮助人们了解自己的应用程序、什么是测试、为什么要测试、什么时候、从哪及如何开始测试Web应用程序
    发布一个完整的测试框架,而不是checklist

  2. 什么是测试

    测试指的是将一套系统/应用程序的状况与一系列标准进行比对的过程,而在安全界,测试的标准通常没有明确的定义和架构

  3. 为什么要实施测试

    该指南可以作为参考方法衡量当前的做法与行业最佳做法的差距

  4. 什么时候测试

    通用软件开发生命周期模型: Define->Design->Develop->Deploy->Maintain
    每一个阶段往后,测试的成本会越来越高
    最佳做法之一:将安全测试融入软件开发生命周期(SDLC)每一个阶段

  5. 测试什么

    有效的测试计划组成:

  • 人员:确保其经历足够的知识水平和意识
  • 过程:确保有足够的政策和标准,人们知道如何遵循这些政策
  • 技术:确保某一进程已被有效执行
  1. 测试技术解释

人工检查及复查、软件威胁建模、代码复查、渗透测试

  1. 人工检查及复查:文件分析或与设计师或系统所有者进行访谈
    包括:文件、代码安全策略、安全要求、架构设计
  • 优点:无需支持技术
    可应用于各种不同的情况
    灵活
    促进团队协助
    在软件开发生命周早期
  • 缺点:
    可能非常耗时
    支持材料并不容易找到
    需要大量的思考及技巧才能非常有效
  1. 软件威胁建模:
  • 采取NIST的800-30标准风险评估办法制定威胁模型
    分解应用程序:通过人工检查理解应用程序如何运作,资产、功能、连接
    界定和归类资产:将资产分为有形和无形资产,并根据业务的重要性进行排名
    探索潜在的弱点:技术、运营、管理
    探索潜在的威胁:通过使用威胁情景或攻击树,从攻击者角度制定一个切合实际的潜在攻击矢量图
    建立迁移战略:为每一个可能演变成破坏的威胁制定迁移战略
  • 优点:
    采用攻击者的思想对系统进行模拟攻击
    灵活
    软件开发生命周期早期
  • 缺点:
    相对新型的技术
    良好的威胁模型并不意味着自动产生良好的软件
  1. 代码复查:
    检查Web应用程序的源码可能存在的安全问题
    有利于发现的安全问题:并发、业务逻辑、访问控制、加密的弱点、后门、木马、彩蛋、定时炸弹、逻辑炸弹
    业务流程同样需要检查
  • 优点:
    完整性和有效性
    准确
    快速(对具有高能力的复查者而言)
  • 缺点:
    需要高度熟练的安全开发者
    可能错过存在于已编译好的类库中的问题
    无法检测运行时产生的错误
    真实环境中的源代码可能与此处已分析的源代码不同
  1. 渗透测试
    作为网络安全通用的测试技术,也成为黑盒测试
  • 优点:
    可以快速进行(因此便宜)
    需要较低技能,相对于代码复查而言
    测试实际运行的程序
  • 缺点:
    软件开发生命周期晚期
    仅仅测试前部影响
  1. 方法平衡的需求

    以往许多公司都只采取渗透测试进行测试,对于SDLC而言,渗透测试过于简单和迟来
    正确的做法是采取多种技术以达到平衡,方法平衡确保覆盖SDLC的各个阶段

  2. 安全需求测试推导

    1. 测试的目的
      数据和服务的CIA
    2. 安全需求文档
      业务需求
      Web应用安全合规性分析
      安全业界标准
      信息安全标准和政策一般要求
    3. 安全需求验证
    4. 威胁和策略分类
      OWASP Top 10
      STRIDE
    5. 安全测试和风险分析
    • 维护一个漏洞知识库,安全事件也可以通过类型、事件、程度和起因报告出来并映射到被发现的应用系统中,在整个SDLC中漏洞知识库也可以用来测量分析安全测试的有效性
      • 通过利用普通弱点的安全威胁方案,来识别需要进行安全测试的应用程序安全控制中潜在的风险,如OWASP Top 10可以映射到的攻击:钓鱼、侵害隐私、身份盗窃、系统破坏、数据更改或破坏、金融损失及名誉损失等
    1. 功能和非功能测试需求
      1. 功能性安全需求
        为了安全需求能通过安全测试验证,安全需求必须是功能驱动的,并且突出预期的功能(做什么)以及隐含的实现(如何做):
        保护用户认证信息和共享的传输中和存储中的秘密
        在现实中隐藏所有保密信息(账户、秘密)
        在一定数量的登陆失败后,锁定用户账号
        只允许输入由字母数字并且包含特殊字符组成的至少六个字符的密码,以限制攻击层面
        用户要修改密码,必须通过旧密码、新密码、对密码问题的回答验证,以防止通过密码修改功能对密码进行穷举搜索攻击
        采用密码重置功能时,系统将临时密码发送到指定邮箱之前,需要验证用户注册时的用户名和邮箱地址,临时密码只能使用一次,一个密码重置链接将发送给用户,重置密码时应该验证用户的临时密码,新密码,密保问题
      2. 风险驱动的安全需求
        安全测试也需要风险控制
        不应该做的例子:
        应用系统不允许修改或毁坏数据
        应用系统不允许被破坏或被恶意用户用于为认证的金融交易事务
        认证控制的安全要求:
        加密在传输和存储过程中的认证数据,以减少信息泄露和认证协议攻击的危险
        使用不可反向解密方式加密密码,如摘要(digest)和一个种子(seed)防止字典攻击
        在达到一定数量的登录失败后锁定账户,并增强密码的复杂性减少暴力破解的风险
        在身份认证错误输入现实笼统的错误信息,以减少账户的获取/列举风险
        客户端和服务器相互认证防止否认和中间人攻击(MitM)
      3. 安全需求在使用和误用中的衍生
        误用方案允许从攻击者的观点分析应用系统,并致力于识别潜在漏洞和对抗措施

  • 第1步:描述功能情景,用户通过提供用户名和密码认证,用户通过应用系统的身份认证访问系统,当认证失败时为用户提供具体的错误信息
  • 第2步:描述消极情景,在应用系统中,攻击者通过穷举或字典攻击密码与账户寻找漏洞来破解认证,验证失败时提供的具体信息使攻击者能猜测到哪些账户实际上是合法的注册用户(用户名),攻击者将暴力破解用户密码,并且能够在有限次数内成功破解至少4位数密码长度的全数字密码
  • 第3步:在使用和用案例中描述功能和消极情景,如图所示,显示了通过使用和误用案例的衍生安全要求,功能情景包括用户行为(输入用户名和密码)和应用行为(认证用户或提供认证失败信息),误用案例包括攻击者行为,即:设法通过字典攻击穷举破解密码以攻破认证,并从提示的错误信息中猜测合法的用户名,通过图解可以看到用户操作可能造成的威胁(误用),就有可能通过对抗措施缓和应用行动可能带来的威胁
  • 第4步:安全需求总结,在这种情况下,可以获得用于认证的安全要求:
    密码必须是由字母(大小写)和数字组成的七个字符以上的字符串组成
    五次登录尝试失败以后,账户锁定
    登录失败信息不具体显示

    1. 安全测试集成于开发者与测试者工作流
      1. 开发者的安全测试工作流
        在SLDC发展阶段的安全测试,保证开发者所开发的组件在集成前进行安全测试,应用集成前的源码测试通常是高级开发者的责任,这些高级开发者通常也是软件安全专家,具有领导代码检查,决定是否接受在当前发布的应用中添加即将发布的代码或需要更多的更改和测试。
      2. 测试者的安全测试工作流
        应用层的安全测试包括白盒测试和黑盒测试。
        安全测试的唯一特异性就是安全测试者可以决定是否利用漏洞或泄露让应用面临实际的风险,包括普通的Web应用程序弱点,早期在SDLC中已识别的安全事件、安全威胁模型、源代码分析、安全代码审查
        测试工程师需要很多安全知识,Web应用漏洞、白盒、黑盒测试技术、安全需求验证
      3. 开发者的安全测试
        • 编制阶段的安全测试:单位测试
          开发者必须遵从安全编码标准中的安全要求,同时通过静态和动态分析验证
          安全测试案例:
          认证与访问控制
          输入验证码与编码
          加密
          用户和会话管理
          错误和异常处理
          设计和日志记录
        • 功能者的安全测试,集成和验证阶段的安全测试:集成系统测试和操作测试
          集成测试宗旨是验证“纵深防御”概念
          安全测试的下一个层次是系统集成测试后在用户验收环境(UAT)下演示安全测试
    2. 安全测试数据分析和报告
      1. 安全测试指标和测量的目标
      2. 报告要求
        包含以下信息:
        每个漏洞的类型分类
        问题引起的安全威胁
        漏洞的起因
        用于发现的测试技术
        漏洞的修复措施
        漏洞的风险等级(高、中、低或CVSS评分)
      3. 商业案例

Leave a Reply

Your email address will not be published. Required fields are marked *