软件开发生命周期各阶段的应用软件安全性测试
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
实施过程 中的投人
在这一层 , 我们可以开展诸如注人缺陷验证 ∃ 旁路验证以
及访问控制等方面的安全测试 , 来源于外部代码的安全审查结 果也应该以集成测试的方式加以确认
.4 2
发布阶段 ∋
验收测试
验收测试是软件产品交付客户之前的最后一个测试阶段 ,
是在真实的测试环境中 , 利用基于恶意事件的安全检测模板 , 测试在典型的渗透活动中可被识别的安全缺陷 验收测试的这
.3 2
验证阶段 ∋
集成测试
在集成层 , 软件的整体安全属性变得可见和可测试 , 使得
这一层的可测试属性数量相对单元层而言要多得多 , 但是对于
跨站脚本和网络服务器提供的一些服务 (例如安全套接层 S L 和 uR L 过滤) 的测试 , 存在一定的困难 我们可以将实际案 例和风险分析的结果作为组织集成测试的指南 集成测试要求测试人员通过安全测试培训 , 并且是有熟练 技术的软件开发人员
开发人员应该根据客户的功能需求来制定相应的安全规 约, 利用内建的明确的控制机制来降低安全风险 开发人员可
以根据风险评估的结果来确定测试项目: 软件能否可靠运行
Sa ( e t f y ) 以及软件运行结果是否可靠 ( Se cu i 动 r
软件开发生命周期 ( S DL ) 试 ∃ 集成测试和验收测试 中常用的测试方法有: 单元测
冲 . 分典每 T 护 3夕: 一 注文臼标 镶璐扒 1 文牵润每缸 7 4户 6 此丽(狈 o冲 பைடு நூலகம்咖 4书
Sa e t f y T ests O f A p p lieation S of twa e r dur i n g its E v e叮 P h ase o f D evelo p in g L if e C y ele
一特性 (基于安全检测模板) , 使得我们可以借助于强大的自 动化测试软件进行检测 , 并且可以用验收测试的结果来完善渗
透测试报告内容 , 从而有助于开发人员理解软件的脆弱性以及 针对软件脆弱性所采取的补救措施是否有效
2. ,
需求 ∃ 设计阶段 ∋
安全性分析
验收测试针对软件的外部 A P I , 因此不如单元测试和集成
更多公司让优秀的人才进行设计 , 仅有很少公司让优秀的人才 进行测试工作 实际的软件工程实践证明, 让对软件思想有深 刻理解的工程师进行软件测试 , 可以大幅度地提高软件质量l o 0 软件供应商还必须认识到组织测试人员进行 #安全进修 ∀ 对安
. 2 2
实施 阶段 ∋
单 元测试
受测试方式的影响 , 开发者对软件安全风险的评估不可能
s t e t s ;i n sPeet i on a n d a c eep 切 叮 ee t e st s :t i a r ni ng
;unitt e st s;
信息网络安全事件发生比例的不断攀升 ∃ 病毒利用软件漏 洞猖狂地传播使得人们越发认识到信息安全的重要性 一般认
为 , 传统的信息安全技术可以借助防火墙 (包括软件和硬件防 火墙) 审核通过网络的报文 ∃ 限定用户的访问权限等来防止非
件 开 发 商 都 存 在 解 决 安 全 威 胁 方 南 的 问 题 对 软 件 开 发 商 来
说 , 安全性是其核心要求 , 这是由市场力量所驱动 , 也是 由 保 护关 键基础 结构及建 立和保 持计算 的广泛信 任的需 要所决定
圈1
将安全侧试整合到软件开发生命周期 中
对于软件行业来说 , 要满足当今 提升安全性 的需要 , 软件 供应商必须转为采用一种更严格的 ∃ 更加关注安全性的软件开
C H EN 化朋 叩ut r a e n d C on回 C 必卿 o I C u 枷 U n i~ L in g - p in g 衍o f E !t n ∀ 沁 ∀兜 石 刀 司 雌 手G u 面 C u a n g打 # I硬 叉 对)
c∀ l e, a n a l 邓es t h e f son w a O r e develop-
授权用户对重要数据的访问, 但是这一观点是建立在软件安全
基础上的 网络应用软件需要暴露在网络环境下 , 并且授权外 部用户可以透过网络来访问此软件 通过网络 , 攻击者有机会
接 触到软件 , 如果软件本 身存在漏洞 , 那么所有的防火墙就形 同虚设 暴 露于网络的应用软件往往成为被攻击的 目 标 , 是网
I肠 st a et , r h e 耐 el r e pr o vi des insig ht si nt o a ser ies o f a c vi ies eoneem i t ng sa e t f y dur ing ever y pha e o s f s of twa e dev r ef o ping l e eyel f i e , s e t s f or h t 叫 ui e m en r s t h e su 脚 st t i on t h a t sa e t f y t es t h o s u l d be i n t e g 旧t ed into sof twa e r y t t s t e s m ea n s a l t o de e v l叩 i 嗯 l e f i f sa o e t f y t e st s t o t e st i ng 拌 r so n ne l, a n d sho w s w hy sa e f o eve 叮 p h a t e s
安全性考虑包括一系列 问题 , 例如访 问控制和授权 ∃ 敏感
软件的整体安全性 , 因此 , 如果改变会使得软件产生不可预知 的缺陷 , 针对这些缺陷的测试就应该在单元层或者集成层开
展 , 而不是在验收层
在验收层 , 我们可以测试针对解释性程序( s Q L , x pA TH ,
数据的适当处理 ∃ 数据和存储器访问的适当使用 , 以及加密方
法 一些安全性需求不是非功能的需求 , 如所实施的加密类型 另外 , 许多安全性需求是更直接地面向用例的, 并且需要定义 主要场景 , 以及定义备选路径和异常路径 在没有将功能的和 非功能的需求适当地定义及并入软件中的情况下 , 编码错误和
L 娜 等) 的注入式攻击 ∃ 跨站脚本攻击 ∃ 跨站请求伪造等 D 缓冲区溢出及格式化字符串等软件缺陷也可以在验收测试层得
除这些漏洞 用于处理来 自I nt er ne t 的输人 ∃ 控制可能被攻击
单元层的安全测试比较适合于防止缓冲区溢出, 格式化字
符串以及数据缺失的审核
的关键系统或处理个人身份信息的企业和消费者软件最需要实
施这种流程阎 在很多实际的软件开发项 目中 , 安全测试已经 成为 SD L 一个不可或缺的组成部分 , 并成为整个项 目过程中 的长期任务 黑盒 一 白盒测试方法往往执行在产品递交客户之
测试松散 , 并且只能测试当前已知且暴露的漏洞或者缺陷 非 定制的商业软件重新设计的关键功能或者其他改变都会影响到
在软件项 目 的设计过程中 , 人们往往只是关注系统的特性 和功能 , 而没有充分考虑其他重要的非功能问题 (例如性能 ∃ 可用性 ∃ 平台支持 ∃ 安全 , 及要在稍后的软件开发生命周期中 需要解决的安全性) , 导致了项目中许多不必要的波动和延迟 由于安全性分析影响了整个的设计和架构 , 因此应该在项 目 设 计阶段充分地审查和了解它们
前 , 但有的甚至在投人使用之后都未进行安全检测和风险评 估; 在一些安全性要求较高的项目中, 虽然将安全风险评估纳 人预算 , 但在实际操作中却对其并未作过多考虑 这样 , 所导
致的直接后果是在开发工作几近完成的情况下进行问题分析处
理所造成的成本将远远大于在软件开发阶段进行缺陷修改的成
本 即便是从充分利用现有的有限资金和资源的角度来考虑 , 也有必要将安全测试囊括到 SD L 中 这样做虽然不能取代软 件开发后期的渗透测试和脆弱性测试 , 却可以有效减少后者在
& 作者简介 陈玲萍(1 97 5 一) , 女. 广西桂林人, 桂林电子科技大学计算机与控制学院硕士研究生, 主要从事信息管理等方面的研究
14
发流程 这种流程 旨 在尽量减少设计 ∃ 编码和文档编写过程中
大量组件交互而引起的软件缺陷 , 利用此种方法无法检测
存在的 漏洞, 并在软件开 发生 命周期中 尽可能早地检 测到并消
应用技术
A pp l e d e eh nol T og y
企业科技与发展
E n te中 r i se S d e n e e A n d T ee h o o lo g y & D e v e O l Pm e t n
0 r 2 o 年第 8 期(总第 2 7 8 期) N0. 8, 2 0 10(Cum ul i vel t a y N0 . 278 )
软件开发生命周期各阶段的应用软件安全性测试
陈玲萍
(桂林电子科技大学 计算机与控制学院, 广西 桂林 541004)
缎 异 盆 梦 笼 馨 探髯澄 瑟黯寒众讹鹭蒙 级 粼 黑 篡 恭 装 豁 撰
件开发生牵月翔各个玲 段的重要性 一
s园卜 ( 安 伞 呼 娜 丙班 耳 像 讯斗 冬 娜 馋 势 舞 成 咖 今一 舞 收 侧 试 一 , 黔, 钾 砂角 妙;衅欣 生 , 娜
到检测
3
安全侧试 队伍
软件测试一度被认为是编程能力偏低的员工的工作 , 直到
设计缺陷会表现出关键的信息和操作处于危险 我们应该像对
待其他的需求那样处理安全性需求 , 并将安全性需求划分出优 先级 , 设定范围, 同时作为整体用例和功能需求的一部分进行
管理
今天 , 仍然有许多公司把优秀的人才安排在编码工作上 , 也有
2
软件开发生命周期流程(参见图 1 )
项 目 开始
络应用软件 安全 的重灾 区
美 国国家标 准与技术研究 院
单元 侧 试
(N IS T )2( ) 2 年的一项研究表明 , 美国花费在软件缺陷方面的 X 费用达到 59 5 亿美元同 公安部 仁0 0 8 年全国信息网络安全状 况与计算机病毒疫情调查分析报部 说明 , 在发生的安全事件 中, 未修补或防范软件漏洞仍然是导致安全事件发生的最主要
的 所有软件开发商面对的一个主要挑战就是创建更加安全的 软件 , 使其不需要频繁地通过修补程序进行更新 软件安全已
经成为评判软件质量的一个重要标准 , 软件安全测试则成为保 证软件产品能够符合这一标准的重要手段 软件的安全性测试 主要是测试在正常和非正常情况下 , 软件能否对数据进行安全 有效的操作
ing l e e界l f i e, e m x
int e 目 旧 o n
pl i 尔ng by t h e ea seo f SQ L i nt e孚 at i on.
[K ey w o 心 net w o浅appl iea i on sof t tw a e : Sof r twa e D evef r o pi ng 城 eyel e (SD L );s e 钾t f a e st s :pr o gr a m m ing t a s e
且在测试 软件时还要扮演攻击者 , 攻击 自己的系统 , 以此来 帮 助发现软件 的安全漏洞 安全测试并不会总是直接导致安全滋 出或者暴露可利用的漏洞 , 从而引出安全缺陷 要安全测试尽 可能地发挥作用 , 测试人员需具备较强的分析能力 , 而这更多
原 因l o ] %
1
安全侧试 的定义
安全测试是鉴别信息系统数据保护和功能维护的过程 安
一 ~ 一 一~ - - - - -
几 皇 位
验收测试
}安 全 侧 试} }
代码设计
一 安 全 ,试 } %
一一土一 项 目结 束
全测试需要涵盖的 6 个基本安全概念是 : 保密性 ∃ 完整性 ∃ 权限
(身份验证) ∃ 授权 (权限分配) ∃ 可提供性 ∃ 不可抵赖性门 软
面面俱到 最典型的就是在代码设计阶段 , 开发者可以通过单 元测试来检验代码行为 , 这些结果都是可以预知的 , 但是受到
范 围的局限 , 不能测试这些类或者模块集成后 的行为
全测试的成功实施至关重要 在这些情况下 , 软件供应商必须 负责对其工程人员进行适当教育 根据组织的规模和可用的资
源 , 拥有大批工程人员的组织可建立一个内部计划对其工程师 进行在职安全培训 , 而小型组织则可能需要依赖外部培训阳飞 测试人员要像攻击者那样带有 #恶意的 ∀ 想法去思考 , 而
在这一层 , 我们可以开展诸如注人缺陷验证 ∃ 旁路验证以
及访问控制等方面的安全测试 , 来源于外部代码的安全审查结 果也应该以集成测试的方式加以确认
.4 2
发布阶段 ∋
验收测试
验收测试是软件产品交付客户之前的最后一个测试阶段 ,
是在真实的测试环境中 , 利用基于恶意事件的安全检测模板 , 测试在典型的渗透活动中可被识别的安全缺陷 验收测试的这
.3 2
验证阶段 ∋
集成测试
在集成层 , 软件的整体安全属性变得可见和可测试 , 使得
这一层的可测试属性数量相对单元层而言要多得多 , 但是对于
跨站脚本和网络服务器提供的一些服务 (例如安全套接层 S L 和 uR L 过滤) 的测试 , 存在一定的困难 我们可以将实际案 例和风险分析的结果作为组织集成测试的指南 集成测试要求测试人员通过安全测试培训 , 并且是有熟练 技术的软件开发人员
开发人员应该根据客户的功能需求来制定相应的安全规 约, 利用内建的明确的控制机制来降低安全风险 开发人员可
以根据风险评估的结果来确定测试项目: 软件能否可靠运行
Sa ( e t f y ) 以及软件运行结果是否可靠 ( Se cu i 动 r
软件开发生命周期 ( S DL ) 试 ∃ 集成测试和验收测试 中常用的测试方法有: 单元测
冲 . 分典每 T 护 3夕: 一 注文臼标 镶璐扒 1 文牵润每缸 7 4户 6 此丽(狈 o冲 பைடு நூலகம்咖 4书
Sa e t f y T ests O f A p p lieation S of twa e r dur i n g its E v e叮 P h ase o f D evelo p in g L if e C y ele
一特性 (基于安全检测模板) , 使得我们可以借助于强大的自 动化测试软件进行检测 , 并且可以用验收测试的结果来完善渗
透测试报告内容 , 从而有助于开发人员理解软件的脆弱性以及 针对软件脆弱性所采取的补救措施是否有效
2. ,
需求 ∃ 设计阶段 ∋
安全性分析
验收测试针对软件的外部 A P I , 因此不如单元测试和集成
更多公司让优秀的人才进行设计 , 仅有很少公司让优秀的人才 进行测试工作 实际的软件工程实践证明, 让对软件思想有深 刻理解的工程师进行软件测试 , 可以大幅度地提高软件质量l o 0 软件供应商还必须认识到组织测试人员进行 #安全进修 ∀ 对安
. 2 2
实施 阶段 ∋
单 元测试
受测试方式的影响 , 开发者对软件安全风险的评估不可能
s t e t s ;i n sPeet i on a n d a c eep 切 叮 ee t e st s :t i a r ni ng
;unitt e st s;
信息网络安全事件发生比例的不断攀升 ∃ 病毒利用软件漏 洞猖狂地传播使得人们越发认识到信息安全的重要性 一般认
为 , 传统的信息安全技术可以借助防火墙 (包括软件和硬件防 火墙) 审核通过网络的报文 ∃ 限定用户的访问权限等来防止非
件 开 发 商 都 存 在 解 决 安 全 威 胁 方 南 的 问 题 对 软 件 开 发 商 来
说 , 安全性是其核心要求 , 这是由市场力量所驱动 , 也是 由 保 护关 键基础 结构及建 立和保 持计算 的广泛信 任的需 要所决定
圈1
将安全侧试整合到软件开发生命周期 中
对于软件行业来说 , 要满足当今 提升安全性 的需要 , 软件 供应商必须转为采用一种更严格的 ∃ 更加关注安全性的软件开
C H EN 化朋 叩ut r a e n d C on回 C 必卿 o I C u 枷 U n i~ L in g - p in g 衍o f E !t n ∀ 沁 ∀兜 石 刀 司 雌 手G u 面 C u a n g打 # I硬 叉 对)
c∀ l e, a n a l 邓es t h e f son w a O r e develop-
授权用户对重要数据的访问, 但是这一观点是建立在软件安全
基础上的 网络应用软件需要暴露在网络环境下 , 并且授权外 部用户可以透过网络来访问此软件 通过网络 , 攻击者有机会
接 触到软件 , 如果软件本 身存在漏洞 , 那么所有的防火墙就形 同虚设 暴 露于网络的应用软件往往成为被攻击的 目 标 , 是网
I肠 st a et , r h e 耐 el r e pr o vi des insig ht si nt o a ser ies o f a c vi ies eoneem i t ng sa e t f y dur ing ever y pha e o s f s of twa e dev r ef o ping l e eyel f i e , s e t s f or h t 叫 ui e m en r s t h e su 脚 st t i on t h a t sa e t f y t es t h o s u l d be i n t e g 旧t ed into sof twa e r y t t s t e s m ea n s a l t o de e v l叩 i 嗯 l e f i f sa o e t f y t e st s t o t e st i ng 拌 r so n ne l, a n d sho w s w hy sa e f o eve 叮 p h a t e s
安全性考虑包括一系列 问题 , 例如访 问控制和授权 ∃ 敏感
软件的整体安全性 , 因此 , 如果改变会使得软件产生不可预知 的缺陷 , 针对这些缺陷的测试就应该在单元层或者集成层开
展 , 而不是在验收层
在验收层 , 我们可以测试针对解释性程序( s Q L , x pA TH ,
数据的适当处理 ∃ 数据和存储器访问的适当使用 , 以及加密方
法 一些安全性需求不是非功能的需求 , 如所实施的加密类型 另外 , 许多安全性需求是更直接地面向用例的, 并且需要定义 主要场景 , 以及定义备选路径和异常路径 在没有将功能的和 非功能的需求适当地定义及并入软件中的情况下 , 编码错误和
L 娜 等) 的注入式攻击 ∃ 跨站脚本攻击 ∃ 跨站请求伪造等 D 缓冲区溢出及格式化字符串等软件缺陷也可以在验收测试层得
除这些漏洞 用于处理来 自I nt er ne t 的输人 ∃ 控制可能被攻击
单元层的安全测试比较适合于防止缓冲区溢出, 格式化字
符串以及数据缺失的审核
的关键系统或处理个人身份信息的企业和消费者软件最需要实
施这种流程阎 在很多实际的软件开发项 目中 , 安全测试已经 成为 SD L 一个不可或缺的组成部分 , 并成为整个项 目过程中 的长期任务 黑盒 一 白盒测试方法往往执行在产品递交客户之
测试松散 , 并且只能测试当前已知且暴露的漏洞或者缺陷 非 定制的商业软件重新设计的关键功能或者其他改变都会影响到
在软件项 目 的设计过程中 , 人们往往只是关注系统的特性 和功能 , 而没有充分考虑其他重要的非功能问题 (例如性能 ∃ 可用性 ∃ 平台支持 ∃ 安全 , 及要在稍后的软件开发生命周期中 需要解决的安全性) , 导致了项目中许多不必要的波动和延迟 由于安全性分析影响了整个的设计和架构 , 因此应该在项 目 设 计阶段充分地审查和了解它们
前 , 但有的甚至在投人使用之后都未进行安全检测和风险评 估; 在一些安全性要求较高的项目中, 虽然将安全风险评估纳 人预算 , 但在实际操作中却对其并未作过多考虑 这样 , 所导
致的直接后果是在开发工作几近完成的情况下进行问题分析处
理所造成的成本将远远大于在软件开发阶段进行缺陷修改的成
本 即便是从充分利用现有的有限资金和资源的角度来考虑 , 也有必要将安全测试囊括到 SD L 中 这样做虽然不能取代软 件开发后期的渗透测试和脆弱性测试 , 却可以有效减少后者在
& 作者简介 陈玲萍(1 97 5 一) , 女. 广西桂林人, 桂林电子科技大学计算机与控制学院硕士研究生, 主要从事信息管理等方面的研究
14
发流程 这种流程 旨 在尽量减少设计 ∃ 编码和文档编写过程中
大量组件交互而引起的软件缺陷 , 利用此种方法无法检测
存在的 漏洞, 并在软件开 发生 命周期中 尽可能早地检 测到并消
应用技术
A pp l e d e eh nol T og y
企业科技与发展
E n te中 r i se S d e n e e A n d T ee h o o lo g y & D e v e O l Pm e t n
0 r 2 o 年第 8 期(总第 2 7 8 期) N0. 8, 2 0 10(Cum ul i vel t a y N0 . 278 )
软件开发生命周期各阶段的应用软件安全性测试
陈玲萍
(桂林电子科技大学 计算机与控制学院, 广西 桂林 541004)
缎 异 盆 梦 笼 馨 探髯澄 瑟黯寒众讹鹭蒙 级 粼 黑 篡 恭 装 豁 撰
件开发生牵月翔各个玲 段的重要性 一
s园卜 ( 安 伞 呼 娜 丙班 耳 像 讯斗 冬 娜 馋 势 舞 成 咖 今一 舞 收 侧 试 一 , 黔, 钾 砂角 妙;衅欣 生 , 娜
到检测
3
安全侧试 队伍
软件测试一度被认为是编程能力偏低的员工的工作 , 直到
设计缺陷会表现出关键的信息和操作处于危险 我们应该像对
待其他的需求那样处理安全性需求 , 并将安全性需求划分出优 先级 , 设定范围, 同时作为整体用例和功能需求的一部分进行
管理
今天 , 仍然有许多公司把优秀的人才安排在编码工作上 , 也有
2
软件开发生命周期流程(参见图 1 )
项 目 开始
络应用软件 安全 的重灾 区
美 国国家标 准与技术研究 院
单元 侧 试
(N IS T )2( ) 2 年的一项研究表明 , 美国花费在软件缺陷方面的 X 费用达到 59 5 亿美元同 公安部 仁0 0 8 年全国信息网络安全状 况与计算机病毒疫情调查分析报部 说明 , 在发生的安全事件 中, 未修补或防范软件漏洞仍然是导致安全事件发生的最主要
的 所有软件开发商面对的一个主要挑战就是创建更加安全的 软件 , 使其不需要频繁地通过修补程序进行更新 软件安全已
经成为评判软件质量的一个重要标准 , 软件安全测试则成为保 证软件产品能够符合这一标准的重要手段 软件的安全性测试 主要是测试在正常和非正常情况下 , 软件能否对数据进行安全 有效的操作
ing l e e界l f i e, e m x
int e 目 旧 o n
pl i 尔ng by t h e ea seo f SQ L i nt e孚 at i on.
[K ey w o 心 net w o浅appl iea i on sof t tw a e : Sof r twa e D evef r o pi ng 城 eyel e (SD L );s e 钾t f a e st s :pr o gr a m m ing t a s e
且在测试 软件时还要扮演攻击者 , 攻击 自己的系统 , 以此来 帮 助发现软件 的安全漏洞 安全测试并不会总是直接导致安全滋 出或者暴露可利用的漏洞 , 从而引出安全缺陷 要安全测试尽 可能地发挥作用 , 测试人员需具备较强的分析能力 , 而这更多
原 因l o ] %
1
安全侧试 的定义
安全测试是鉴别信息系统数据保护和功能维护的过程 安
一 ~ 一 一~ - - - - -
几 皇 位
验收测试
}安 全 侧 试} }
代码设计
一 安 全 ,试 } %
一一土一 项 目结 束
全测试需要涵盖的 6 个基本安全概念是 : 保密性 ∃ 完整性 ∃ 权限
(身份验证) ∃ 授权 (权限分配) ∃ 可提供性 ∃ 不可抵赖性门 软
面面俱到 最典型的就是在代码设计阶段 , 开发者可以通过单 元测试来检验代码行为 , 这些结果都是可以预知的 , 但是受到
范 围的局限 , 不能测试这些类或者模块集成后 的行为
全测试的成功实施至关重要 在这些情况下 , 软件供应商必须 负责对其工程人员进行适当教育 根据组织的规模和可用的资
源 , 拥有大批工程人员的组织可建立一个内部计划对其工程师 进行在职安全培训 , 而小型组织则可能需要依赖外部培训阳飞 测试人员要像攻击者那样带有 #恶意的 ∀ 想法去思考 , 而