当前位置:   article > 正文

(转)[太原理工大学] 大三下 软件安全技术考试复习_软件安全bsi模型

软件安全bsi模型

从一位同学那里要到的以前的复习资料,比较精简,大家搭配我前一个看看

  • 软件安全概述
  1. 零日漏洞:未被公开披露的软件漏洞。并不是指软件发布后被立即发现的漏洞
  2. 软件漏洞:是指在软件开发的生命周期中与安全相关的设计错误、编码缺陷及运行故障等
  3. 恶意代码:是在未被授权的情况下以破坏软硬件设备、窃取用户信息、干扰用户正常使用、扰乱用户心理为目的而编写的软件或代码片段。
  4. 软件安全:在面临蓄意威胁其可靠性的时间的情形下依然能够提供所需功能的能力
  5. CIA:保密性:防止非法泄露、完整性:未经授权不能改变、可用性:允许授权用户按需访问
  6. 其他安全属性:可认证性、授权、可审计性和可审查性、抗抵赖性、可控性、可存活性
  7. 软件的“可信”是指软件系统的动态欣慰及其结果总是符合人们的预期
  8. 软件定义安全时将物理及虚拟的网络安全设备预期接入模式、部署方式、实现功能进行解耦,底层抽象为安全资源池李的资源,顶层统一通过软件编程的方式进行智能化、自动化的业务编排和管理,以完成响应的安全功能,从而实现一种灵活的安全防护
  9. 软件定义安全可以分解为软件定义流量、软件定义资源、软件定义威胁模型
  10. PDRR:保护、检测、响应、恢复
  11. PPDR:安全策略、保护、检测、响应
  12. 软件安全防护围绕漏洞的消除展开,目前有两种基本方法:
  1. 采用多种检测、分析及挖掘技术对安全错误或安全漏洞进行发现、分析与评价,然后采取多种安全控制措施进行错误修复和风险控制
  2. 分析软件安全错误发生的原因,将安全错误的修正嵌入到软件开发生命周期的整个阶段
  1. 软件安全防护的主要技术:软件安全属性认知、信息系统安全工程、软件安全开发
  2. 软件安全开发的核心思想:软件安全开发关注的是如何运用系统安全工程的思想,以软件的安全性为核心,将安全要素嵌入软件开发生命周期的全过程,有效的减少软件产品潜在的漏洞数量或控制在一个风险可接受水平内、提高软件系统的整体安全性。

  • 软件漏洞概述
  1. 软件漏洞:是指在软件开发的生命周期中与安全相关的设计错误、编码缺陷及运行故障等
  2. 软件漏洞特点:持久型与时效性、广泛性与具体性、可利用性与隐蔽性
  3. 软件漏洞成因:计算机系统结构决定了漏洞的必然性;软件趋于大型化,第三方扩展增多;新技术、新应用产生之初即缺乏安全性考虑;软件使用场景更具威胁;对软件安全开发重视不够,软件安全开发者缺乏安全知识
  4. 软件漏洞的分级:

按照漏洞严重等级进行分级:严重、重要、中等、低

利用通用漏洞评分系统(CVSS)进行分级:

  1. 软件漏洞管理国际标准:CVE、CVSS、CWE、CWSS、CPE、OVAL

  • Windows系统典型漏洞分析

Win32系统中,进程使用的内存按功能可以分为4个区域:代码区、数据区、堆区、栈区

  1. 栈帧是操作系统为进程中的每个函数调用划分的一个空间
  2. Win32系统提供了两个特殊的寄存器来标识当前栈帧:

ESP(扩展栈指针寄存器):存放的指针指向当前栈帧的栈顶

EBP(扩展基址指针寄存器):存放的指针指向当前栈帧的栈底

EIP(扩展指令指针寄存器):存放指向下一条将要执行的指令

  1. 函数调用的步骤:  函数A(主调函数)调用函数B(被掉函数)

参数入栈。将被掉函数的实际参数从左到右依次压入主调函数的函数栈中

返回地址RET入栈。将当前指令的下一条指令地址压入主调函数的函数栈中

代码区跳转。CPU从当前代码区跳转到被掉用函数的入口,EIP指向被调用函数的入口处

将当前栈帧调整为被调用函数的栈帧:

主调函数的栈底指针EBP入栈,以便调用函数返回时恢复主调函数的栈帧

更新当前栈底:将主调函数的栈顶指针ESP的值赋值给EBP,作为被调函数的栈底

为新栈帧分配空间:ESP减去适当的值,作为新的当前栈帧的栈顶

  1. 栈溢出攻击:

通过覆盖程序中的函数返回地址和函数指针等值,攻击者直接将程序跳转到其预先设定的或已经注入到目标程序的代码上执行。

目的在于扰乱具有某些特权运行的程序的功能,使得攻击者取得程序的控制权,如果该程序有足够的权限,那么整个主机将被控制

方法: JMP ESP覆盖方法是覆盖函数返回地址的一种攻击方式

SEH覆盖方法是覆盖异常处理程序地址的一种攻击方法

  1. 格式化字符串漏洞:
  2. Windows安全漏洞保护机制:栈溢出检测选项/GS、数据执行保护DEP、地址空间布局随机化ASLR、安全结构化异常处理SafeSEH、增强缓解体验工具包EMET。
  3. 地址空间布局随机化ASLR保护机制:

原理:通过对堆、栈和共享映射库等线性区域布局的随机化,增加攻击者预测目的地址的难度,防止攻击者直接定位攻击代码位置

ASLR进行随机化的对象主要有:映像随机化、堆随机化、栈随机化

缺陷:对本地攻击者无能为力,造成内存碎片增多

绕过:利用没有采用/DYNAMICBASE保护的模块作为跳板

  1. SafeSEH保护机制:防止SEH机制被攻击者利用

原理:编译器在链接生成二进制IMAGE时,把所有合法的异常处理函数的地址解析出来制成一张安全的SEH表,保存在程序的IMAGE数据块里面,当程序调用异常处理函数时会见函数地址与安全的SEH表中的地址进行匹配,检查调用的异常处理函数是否在表中。

  • Web漏洞分析
  1. 一次Web访问过程:DNS域名解析、TCP连接、HTTP请求、处理请求返回HTTP响应、页面渲染和关闭连接
  2. Web漏洞:Web应用程序在需求、设计、实现、配置、维护和使用等过程中,有意或无意产生的缺陷,这些缺陷一旦被攻击者利用,就会造成对网站或用户的安全损害,从而影响构建于Web应用之上正常服务的运行,危害网站或用户的安全属性。
  3. SQL注入漏洞

原理:利用现有的Web应用程序,将恶意的数据插入SQL查询中,提交到后台数据库引擎执行非授权操作

注入点选择:表单提交、URL参数提交、Cookie参数提交、HTTP请求头部的一些可修改的值

数字型注入:输入的参数为整数时

字符型注入:输入的参数为字符串时

实验

  1. 存储型XSS比反射型XSS的危害更大

  • 软件安全开发模型
  1. 软件安全开发模型:

微软的软件安全开发模型:安全开发生命周期SDL、敏捷SDL

McGraw的软件内建安全开发模型:内建安全BSI

NIST的软甲安全开发生命周期模型

OWASP的软件安全开发模型:综合的轻量级应用安全过程CLASP、软件保证成熟度模型SAMM

  1. SDL模型7个阶段:安全培训、安全需求分析、安全设计、安全实施、安全验证、安全发布、安全响应

  1. SDL模型实施的基本原则SD3+C原则,基本内容:安全设计、安全配置、安全部署、沟通
  2. 敏捷SDL适用于软件产品开发时间紧迫
  3. BSI安全开发模型的核心思想:对软件全生命周期各个阶段产品的安全性进行评估、测试、验证及操作控制,实现面向过程的全生命周期安全质量控制方法
  4. BSI模型以风险管理、软件安全接触点、安全知识作为软件安全的三根支柱
  5. 软件保证成熟度模型SAMM,面向安全保证4个核心业务职能:治理、构造、验证、部署
  6. SDL模型适用于大型机构使用;
  7. BSI认为软件安全有3根支柱:风险管理、软件安全接触点和安全知识,强调了在软件生命周期中风险管理的重要性,并要求风险管理框架贯穿整个开发过程;
  8. CLASP所采用的流程属于轻量级,也能够与多种软件开发模型相结合,因此,对小型软件企业更具有吸引力;
  9. SAMM的目标在于制定简单、有良好定义,且可测量的软件安全开发模型,其对安全知识的要求更低,更适于非安全专家使用。

  • 软件安全需求分析
  1. 软件安全需求分析的目的:描述为了实现信息安全的目的,软件系统应该做什么,才能有效的提高软件产品的安全质量,减少进而消减软件安全漏洞。
  2. 软件安全需求分析的作用:

没有考虑安全需求,导致所开发的应用系统存在大量的漏洞。

一个缺少安全需求分析的软件开发项目,将威胁到信息的保密性、完整性和可用性,以及其他一些重要安全属性。

软件产品被攻破可能就只是一个时间早晚的问题,而不是条件的问题,这取决于攻击者对于这个软件系统价值的判断。

  1. 软件安全需求分析与软件需求分析的区别
    1. 软件安全需求的客观性。安全需求与一般需求的一个主要不同之处在于:安全需求并不是从使用者的要求和兴趣出发,而是由系统的客观属性所决定。
    2. 软件安全需求的系统性。软件安全需求分析不能只从软件本身出发,必须从系统角度进行分析
    3. 经济性和适用性。软件安全的需求内容非常丰富,并不是所有可以的应用安全需求控制都要采纳和实施。组织应当根据具体业务的重要性,对安全措施进行成本控制。安全控制的成本应该与软件所有者或者管理部门要求的目标水平相当。
  2. 软件安全需求分析阶段的主要工作
    1. 确定目标系统的业务运行环境、规则环境以及技术环境
    2. 在了解各类软件安全需求内容的基础上,通过一定的安群需求获取过程,对软件应该包含的安全需求进行分析
  3. 软件安全需求来源分类:
    1. 外部安全需求:法律法规等遵从性需求
    2. 内部安全需求:组织内部需要遵守的政策、标准、指南、实践模式;与软件业务功能相关的安全需求
  4. 软件安全遵从性需求
  5. 软件安全需求的获取方法:头脑风暴、问卷调查和访谈、策略分解、数据分类、主客体关系矩阵、使用用例和滥用案例建模、软件安全需求跟踪矩阵。

  • 软件安全设计
  1. 软件安全设计的主要工作包括软件架构安全性设计、软件架构安全性分析、软件安全功能设计
  2. 13条安全设计原则
    1. 减少软件受攻击面原则

软件受攻击面是指,用户或其他程序以及潜在的攻击者都能够访问到的所有功能和代码的总和,它是一个混合体,不仅包括代码、接口、服务,也包括对所有用户提供服务的协议,尤其是那些未被验证的或远程用户都可以访问到的协议。

一个软件的攻击面越大,安全风险就越大。减少软件受攻击面就是去除、禁止一切不需要使用的模块、协议和服务,其目的是减少攻击可以利用的漏洞。

举例:

重要性低的功能可取消;

重要等级为中的功能可设置为非默认开启,需要用户配置后才予以开启;

重要性高的功能则关闭或增加一些安全措施进行限制。

重用那些经过测试、已证明安全的现有库和通用组件,而不是用户自己开发的共享库。

苹果公司的iOS不支持Java和Flash,一个重要原因就是相对于Mac OS X(或其他智能手机)减小了iOS的受攻击面。

    1. 最小授权原则

最小授权原则是指,系统仅授予实体(用户、管理员、进程、应用和系统等)完成规定任务所必需的最小权限,并且该权限的持续时间也尽可能短。

举例:

将超级用户的权限划分为一组细粒度的权限,分别授予不同的系统操作员/管理员。对管理员账户分配安全资源的访问权限也要设置为受限访问,而不是超级用户权限。

采用高内聚、低耦合的模块化编程方法,也就是模块之间的依赖关系是弱链接(低耦合),每一个模块只负责执行一个独立的功能(高内聚)。

Windows系统用户账户控制(User Account Control,UAC),实际上就是最小授权原则的运用。

    1. 权限分离原则

权限分离原则在软件设计中是指,将软件功能设计为需要在两个或更多条件下才能实现,以防止一旦出现问题,整个软件都可能面临风险。

实际上这一原则也是最小权限原则的一种体现。

举例:

清晰的模块划分,将风险分散到各个模块中。

不允许程序员检查自己编写的代码。

Linux将敏感操作(如超级用户的权利)分成26个特权,由一些特权用户分别掌握这些特权,每个特权用户都无法独立完成所有的敏感操作。

    1. 纵深防御原则

纵深防御又称为分层防御是指,在软件设计中加入层次化安全控制和风险缓解/防御方法。

纵深防御原则有助于减少系统的单一失效点。

举例:

在使用预处理语句和存储过程的同时应用输入验证功能,不允许使用用户输入的动态查询结构,以防止注入攻击。

不允许活动脚本与输出编码、输入或请求验证相结合,以防止跨站脚本攻击XSS。

使用安全域,根据被授权访问的软件或者人员级别来划分不同的访问域。

    1. 完全控制原则

完全控制原则是指,要求每一次访问受保护对象的行为都应当进行尽可能细粒度地检查。

举例:

应该避免仅仅依赖于客户端或者基于Cookie缓存的认证凭证进行身份验证。

不允许没有经过访问权限验证的浏览器进行数据回传。

    1. 默认安全配置原则

默认安全配置原则是指,为系统提供默认的安全措施,包括默认权限、默认策略等,尽可能让用户不需要额外配置就可以安全地应用。默认安全原则也是保持系统简单化的重要方式。

举例:

对任何请求默认加以拒绝。

不经常使用的功能在默认情况下关闭。

默认检查口令的复杂性。

当达到最大登录尝试次数后,默认状态下拒绝用户访问,锁定账户。

    1. 开放设计原则

软件的开放设计原则是指,软件设计本身应该是开放的,安全防御机制的实现应该不依赖于设计本身。

举例:

软件的安全性不应该依赖于设计的保密。

保护机制的设计应该对团队成员的审查工作开放,让一个团队成员发现系统漏洞总比让攻击者发现要好。

应用于加密设计的柯克霍夫(Kerckhoff)原则,即密码的安全性不依赖于对加密系统或算法的保密,而依赖于密钥。利用经过公开审查的、已经证明的、经过测试的行业标准,而不是仅采用用户自己开发的保护机制是值得推荐的做法。

    1. 保护最弱一环原则

是指保护软件系统中的最弱组件。

该原则类似于“木桶原理”,描述了软件抵御攻击时的弹性主要依赖于最弱组件的安全性,它们可能是代码、服务或者接口。

与最弱链接相关的一个概念是“单点失效”,在软件安全问题中,最弱链接常常是多个单点故障的超集。

软件必须被设计为不存在单点的完全失效。当软件被设计为纵深防御时,可以降低最弱链接和单点失效带来的风险。

举例:

进行风险分析,标识出系统最薄弱的组件。

对开发人员或者用户进行充分的安全告知、培训和教育。

    1. 最少共用机制原则

最少共用机制原则是指,尽量减少依赖于一个以上用户甚至于所有用户的通用机制。

设计应该根据用户角色来划分功能或隔离代码,因为这可以限制软件的暴露概率,提高安全性。

举例:

不使用成员与管理员和非管理员之间共享的函数或库,而推荐使用两个互相区分的功能,每一个功能为每一个具体的角色服务。

使诸如文件以及变量等共享资源尽可能的少。

    1. 安全机制的经济性原则

安全机制的经济性原则是指,以较低的开发成本和资源消耗获得具有较高安全质量的软件产品和系统保障。

保证代码与设计尽可能简单、紧凑是经济性原则的体现。

安全机制的经济性原则并不是要求压缩安全上的投入。

    1. 安全机制心理可接受原则

安全机制心理可接受原则是指,安全保护机制设计得要简单,要让用户易用,要确保用户对资源的可访问,以及安全机制对用户透明,用户才会使用这些保护机制。

举例:

配置和执行一个程序应该尽可能的简单和直观,输出应该直接而且有用。

通过明确的错误信息和标注通知用户,例如消息框提示、帮助对话框以及直观的用户界面。

    1. 平衡安全设计原则

以上介绍的这些安全设计原则每一项都有自己的侧重点,将所有这些安全原则都设计到软件中是不可能的,因此有必要在这些安全原则间进行决策折中,即平衡安全设计原则。

  1. 软件设计模式

是对软件设计中普遍存在、反复出现的各种问题,根据多次处理的经验,提出的一套能够快速、准确响应此类问题的解决方案。设计模式描述在各种不同情况下,应如何解决共性问题。

使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。

  1. 基于安全模式的软件安全设计方法的过程可分为3个阶段:风险确定阶段、系统安全架构阶段、系统设计细化阶段
  2. 软件威胁建模是指,通过抽象的概念模型对影响软件系统的威胁进行系统地识别和评价。
  3. 为什么要威胁建模

  1. 如何进行威胁建模:(简答)

1)确定安全目标

包括确定软件系统涉及的资产,以及围绕这些资产的业务目标和安全目标。

2)创建应用程序概况图

实际上是应用程序的图形化表示过程

3)分解应用程序

通过分解应用程序的结构来确定信任边界、数据流、数据入口点和数据出口点。

4)确定威胁

确定可能影响应用程序和危及安全目标的威胁的最大难题是系统性和全面性

5)威胁评估

6)确定威胁缓解计划或策略

假冒、篡改、否认、信息泄露、拒绝服务、提权提升

7)验证威胁

验证的内容包括威胁模型、列举的威胁、缓解措施等

8)威胁建档

威胁和控制可以用图表记录或以文本的方式存档。威胁归档时,建议使用模板保持威胁文档的一致性。

  • 安全编码
  1. 安全编码的主要工作:选择安全的编程语言、版本(配置)管理、代码检测、安全编译
  2. CERTain安全编码的10条建议:验证输入、留意编译器警告、安全策略的架构和设计、保持简单性、默认拒绝、坚持最小权限原则、清洁发送给其他系统的数据、纵深防御、使用有效的质量保证技术、采用安全编码标准
  3. Java语言安全编码

语言层安全

语言层安全是通过编译器的编译来实现,即编译成功则说明达到了语言层安全性。Java在语言层提供如下安全机制:

通过某些关键字(如private、protected)定义代码的可见性范围(即权限)。

通过类型规则确保程序运行时变量的值始终与声明的类型一致,在函数或方法调用时形参与实参的类型匹配。

Java还采用自动内存管理、垃圾收集站、字符串和数组的范围检查等方法,来确保Java语言的安全性。

字节码层安全

在字节码层次,Java提供两种保障安全的机制:

类加载器:类加载器主要分为四类:启动类加载器、标准扩展类加载器、路径类加载器和网络类加载器。

字节码验证器:验证分成静态和动态两个阶段。

应用层安全

   一旦类加载器加载了一个类并由字节码验证器验证了它,Java平台的第3种安全机制,即安全管理器就开始运行:

安全管理器是一个由Java API提供的类,即:java.lang. SecurityManager类,它的作用是说明一个安全策略以及实施这个安全策略。

安全策略描述了哪些代码允许做哪些操作。由安全管理器对象定义的安全检查方法构成了当前系统的安全策略。当这些检查方法被调用时,安全策略就得以实施。

  • 软件安全测试
  1. 软件安全测试的目标

验证软件系统的安全功能是否满足安全需求。

发现系统的安全漏洞,并最终把这些漏洞的数量降到最低。

评估软件的其他质量属性,包括可靠性、可存活性等。

  1. 软件安全测试的内容

软件安全功能测试。

软件安全漏洞测试。

  1. 软件安全测试的原则

应尽早进行软件安全测试,越晚发现漏洞,修复的成本越高。

在有限的时间和资源下进行测试,找出软件所有的错误和缺陷是不可能的,软件测试不能无限进行下去,应适时终止。在软件安全测试中同样如此,应该通过威胁建模等方法,优先测试高风险模块。

软件安全没有银弹。

程序员应避免检查自己的程序。同样,软件安全测试也应该如此。

尽量避免测试的随意性。

  1. 软件测试与软件安全测试的区别(简答)

软件测试主要是从最终用户的角度出发发现缺陷并修复,保证软件满足最终用户的要求。

软件安全测试则是从攻击者的角度出发发现漏洞并修复,保证软件不被恶意攻击者破坏。

  1. 软件安全测试的方法

  1. 模糊测试技术的核心思想

通过监视非预期输入可能产生的异常结果来发现软件问题。

就是使用大量半有效的数据作为应用程序的输入,以程序是否出现异常作为标志,来发现应用程序中可能存在的安全漏洞。

所谓半有效的数据是指,对应用程序来说,测试用例的必要标识部分和大部分数据是有效的,这样待测程序就会认为这是一个有效的数据,但同时该数据的其他部分是无效的。这样,应用程序就有可能发生错误,这种错误可能导致应用程序的崩溃或者触发相应的安全漏洞。

  1. 模糊测试的方法

1)预生成测试用例

2)随机生成输入

3)手工协议变异测试

4)变异或强制性测试

5)自动协议生成测试

  1. 模糊测试的过程

 版权归原作者所有,我只是搬运,侵删。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/木道寻08/article/detail/743814
推荐阅读
相关标签
  

闽ICP备14008679号