什么是威胁建模 威胁建模详细介绍
威胁建模介绍
Who? What? When? Why? How?
1 谁做/需要做威胁建模?
- 软件开发和测试
- 架构师、操作员和管理员
- 客户
- 安全专家
2 什么是威胁建模
利用抽象来帮助思考风险
威胁建模是通过识别目标和漏洞来优化系统安全,然后定义防范或减轻系统威胁的对策的过程。
威胁建模是分析应用程序安全性的一种方法。这是一种结构化的方法,使您能够识别,量化和解决与应用程序相关的安全风险。威胁建模不是代码审查方法,但却是对安全代码审查过程的补充。在 SDLC 中包含威胁建模可以帮助确保从一开始就以内置的安全性开发应用程序。这与作为威胁建模过程一部分的文档相结合,可以使审阅者更好地理解系统。这使得审阅者可以看到应用程序的入口点以及每个入口点的相关威胁。威胁建模的概念并不新鲜,但近年来有了明显的思维转变。现代威胁建模从潜在的攻击者的角度来看待系统,而不是防御者的观点。微软在过去的几年里一直是这个过程的强有力的倡导者。他们已经将威胁建模作为其SDLC的核心组件,他们声称这是近年来产品安全性提高的原因之一。
当在SDLC之外执行源代码分析时(例如在现有的应用程序上),威胁建模的结果通过推广深度优先方法与宽度优先方法来帮助降低源代码分析的复杂性。您可以不用同等重点地审查所有源代码,而是将安全代码评估放在优先级上,这些组件的威胁建模已经排在高风险威胁之下。
3 在软件开发安全生命周期中进行威胁建模
威胁建模可以在软件设计和在线运行时进行, 按照“需求-设计-开发-测试-部署-运行-结束”的软件开发生命周期,威胁建模在新系统/新功能开发的设计阶段,增加安全需求说明,通过威胁建模满足软件安全设计工作;如果系统已经在上线运行,可以通过威胁建模发现新的风险,作为渗透测试的辅助工作,尽可能的发现所有的漏洞。
4 为什么要做威胁建模?
- 在早期发现 Bug
- 理解安全需求
- 建造和交付更好的产品
- 标记其他技术不能发现的问题
5 如何做威胁建模
5.1 图表
- 理解上下文环境
根据业务需求和开发框架理解业务遭受的威胁环境 - 设定攻击场景
- 画流程图
5.2 威胁分析
- STRIDE 介绍
- 欺骗(Spoofing threats)
身份欺骗的一个例子是非法访问,如使用其他用户的身份验证信息(用户名和密码)进行认证。 - 篡改(Tampering threats)
数据篡改涉及恶意修改数据。示例包括未经授权的对持久性数据(例如数据库中的数据)所做的更改以及在两台计算机之间通过互联网等开放网络进行传输中的数据更改。 - 否认(Repudiation threats)
拒绝威胁与拒绝执行操作的用户相关联,并且没有其他方面有任何证明的方式 - 例如,用户在系统中执行非法操作,该系统不能追踪被禁止的操作。不可否认是指系统有抵制否认威胁的能力。例如,用户使用了转账业务,但是随后不承认转账过,系统需要证明用户的行为。 - 信息泄露(Information disclosure threats)
- 拒绝服务(Denial of service threats)
拒绝服务(DoS)攻击会拒绝有效用户的服务,例如,使Web服务器暂时不可用。必须防止某些类型的DoS威胁,以提高系统可用性和可靠性。 - 提权(Elevation of privilege threats)
在这种类型的威胁中,非特权用户获得特权访问权限,从而有足够的权限来妥协或破坏整个系统。提升特权威胁包括攻击者已经有效地渗透所有系统防御措施,成为可信系统本身的一部分。
元素与 STDRE 的关系:
- 欺骗(Spoofing threats)
- 隐私威胁
除了微软的典型的STRIDE分析方法,现在同样需要考虑隐私威胁,国内可以参考国标GBT 35273-2017《信息安全技术个人信息安全规范》,业务数据如果涉及了个人信息要考虑对隐私数据的威胁和保护。 - 攻击树
示例见下图:
攻击树可以根据组织业务经验进行积累,如组织同类型业务早期的攻击树分析,近期攻击者利用的漏洞、使用的技术等。
5.3 缓解措施
缓解模式,举些例子:
- 认证缓解欺骗
- 认证:
- 基本&摘要认证
- LiveID身份验证
- Cookie认证
- Windows身份验证(NTLM)
- Kerberos身份验证
- PKI系统,如SSL / TLS和证书
- 安全
- 数字签名的数据包
- 验证代码或数据
- 数字签名
- 消息认证码
- 哈希
- 认证:
- 完整性缓解篡改
- Windows强制完整性控制
- 访问控制列表
- 数字签名
- 消息认证码
- 不可否认性缓解否认
- 强认证
- 安全的日志记录和审计
- 数字签名
- 保护时间戳
- 值得信赖的第三方
- 加密缓解信息泄露
- 加密
- 访问控制
- 可用性缓解拒绝服务
- 访问控制
- 过滤
- 配额
- 授权
- 高可用性设计
- 授权缓解提权
- 访问控制
- 组或角色成员资格
- 特权管理
- 输入验证
- 缓解隐私威胁
- 数据清洗
- 数据脱敏
- 传输/存储加密
- 访问控制
- 授权
5.4 威胁建模过程
- 微软提供的方法
过程如下图:
- 预设场景
- 场景,会哪里使用该产品?
- 使用案例
- 为场景/用例增加安全性
- 结构化的方式来思考“你告诉客户有关产品的安全性?”
- 图表化场景/过程
- 识别威胁
- 如果不知道从哪开始,可以从外部实体或驱动动作的事件开始
- 不要忽略每一个威胁,因为你可能不知道它的利用方法
- 聚焦易实现的威胁
- 提供每个威胁的缓解措施
- 验证所有威胁和缓解措施
- 图表是否匹配最终的代码?
- 列举的威胁是?
- 最小化:触及信任边界的每个元素的STRIDE
- 有测试检查模型?
- 创建适当的测试计划
- 测试者的方法经常发现与TM或问题的细节
- 每个威胁是否得到缓解?
- 缓解措施是否正确
另外有套类似风险评估的方法,需要计算每个风险的值,以区分风险级别
过程见下图: - 识别资产:确定哪些是包含敏感或隐私信息的关键资产/信息/文件/位置
- 创建体系结构概述:创建体系结构图以清楚地了解建议的应用程序及其托管环境
- 分解应用程序:分解体系结构图以识别各种进入和退出标准
- 识别威胁:使用STRIDE(欺骗,篡改,拒绝,信息披露,拒绝服务和特权提升)以及可能发生这些威胁的可能威胁
- 记录威胁:识别各种资产,威胁和控制。捕获缺少安全控制的威胁列表,并为每个威胁提供适当的修复建议
- 评估威胁:在与相应的客户/客户进行讨论之后,遵循DREAD(潜在损害,可重复性,可利用性,受影响的用户,可发现性)模型来对每个已识别的威胁
详细可以参考:https://msdn.microsoft.com/en-us/library/ff648644.aspx
- 预设场景
- OWASP 过程
- 分解应用程序。威胁建模过程的第一步是关注如何理解应用程序以及如何与外部实体交互。这包括创建用例来了解应用程序的使用方式,确定入口点以查看潜在攻击者可以与应用程序交互的位置,识别资产(即攻击者感兴趣的项目/区域),以及识别代表应用程序将授予外部实体的访问权限。此信息记录在“威胁模型”文档中,也用于为应用程序生成数据流图(DFD)。 DFD 显示通过系统的不同路径,突出特权边界。
- 确定并排列威胁。识别威胁的关键在于使用威胁分类方法。可以使用诸如 STRIDE 的威胁分类,或定义诸如审计和日志记录,认证,授权,配置管理,存储和传输中的数据保护,数据验证,例外管理等威胁类别的应用安全框架(ASF)。威胁分类的目标是帮助识别来自攻击者(STRIDE)和防御角度(ASF)的威胁。在步骤1中生成的DFD有助于从攻击者的角度确定潜在的威胁目标,例如数据源,进程,数据流和与用户的交互。这些威胁可以进一步确定为威胁树的根源;每个威胁目标都有一棵树。从防御的角度来看,ASF 分类有助于将威胁识别为这种威胁的安全控制的弱点。常见的威胁列表和例子可以帮助识别这些威胁。使用和滥用案例可以说明现有的保护措施可以被绕过,或者缺乏这种保护措施。可以使用诸如 DREAD 的基于价值的风险模型或基于一般风险因素(例如可能性和影响)的较不主观的定性风险模型来确定每个威胁的安全风险。
- 确定对策和缓解措施。缺乏对威胁的保护可能意味着可以通过实施对策来减轻风险。这种对策可以使用威胁对策映射列表来识别。一旦将风险等级分配给威胁,就可以将威胁从最高风险分类到最低风险,并且优先化缓解工作,例如通过应用所识别的对策来对这些威胁进行响应。风险缓解策略可能涉及评估这些威胁所带来的业务影响,并降低风险。其他选择可能包括承担风险,假设业务影响是可接受的,因为补偿性控制,通知用户威胁,完全消除威胁构成的风险,或者是最不可取的选择,即什么都不做。
OWASP的方法也是介绍了风险值的计算方法,详细说明见:https://www.owasp.org/index.php/Application_Threat_Modeling
6 实际的威胁建模示例
以简单的用户登录情况示例
- 设定场景
用户使用浏览器登录Web应用系统,登录时检查是否为HTTPS请求,如果不是重定向到HTTPS,用户提交用户名和密码到应用服务器,应用服务网从后台数据库查询是否为正确的输入,如果用户名和密码正确,则认证成功,登录用户自己的首页界面。 - 图表化过程
使用微软的建模工具辅助作图,过程见下图:
- 识别威胁
结合本文 STRIDE 介绍部分,外部实体 User 可能存在欺骗、否认的威胁,否认可能是用户否认某次登录请求。
过程“提交登录请求”可能存在篡改、拒绝服务威胁,篡改可以是拦截非 HTTPS 请求重定向到一个钓鱼站点。 - 缓解措施
根据识别的威胁分析可以实施的缓解措施,最后整理成报告格式,可以用表格描述(下图只是个示例)
7 威胁建模工具
- 通用工具
白板 + 纸 - 开源工具
微软开源的威胁建模工具github - 商业工具
https://www.continuumsecurity.net/threat-modeling-tool/
8 攻击库
- 检查清单
- CAPEC
- OWASP
https://www.owasp.org/index.php/Threat_Modeling_Cheat_Sheet - 建立自己的威胁库
参考
- https://blogs.msdn.microsoft.com/ptorr/2005/02/22/guerrilla-threat-modelling-or-threat-modeling-if-youre-american/
- https://msdn.microsoft.com/en-us/library/ff648644.aspx
- https://www.infoq.com/articles/developer-driven-threat-modeling
- https://www.owasp.org/index.php/Application_Threat_Modeling
威胁建模的使用场景有2个部分:
- 在业务需求生成后,软件设计前进行,形成软件开发的安全需求文档。这个需要跟业务和开发部门沟通配合,如果从0开始,可以考虑从一些不重要的或者开发时间充裕的需求开始。让参与的业务和开发了解项目开发可能遇到的风险,通过头脑风暴的会议讨论形成威胁建模报告,可能第一次考虑不全,但是只要一直继续下去,效果会越来越好。
- 另一个场景是业务已经在线上运行,安全人员可以通过梳理业务功能,通过威胁建模的方式发现可能存在的风险点,结合渗透测试,查看是否有控制措施,控制措施是否有效,并能减少渗透测试遗漏的测试点。这个与其他部门沟通的工作较少,主要是能够全面了解组织的业务,安全人员可以自己来做。
威胁建模不算是风险评估,比实际的风险评估工作的范围和工作量要小,是 SDLC 过程的一部分,不要觉得很难很麻烦就不做,实际做起来要比想象中的难度小,同样威胁建模的工作过程也是对开发和业务的安全意识培训,有条件的话约早执行越好。
外包开发工作,加入一个安全需求的要求就行,要求甲方安全人员参与和监督威胁建模的执行,审核软件开发的安全需求,确定好关系人员和责任。
文章来源:https://xz.aliyun.com/t/2061
-----------下面的威胁建模的介绍来源另一篇文章------------
威胁建模是一个不断循环的动态模型,随着时间的推移不断更改,以适应发现的新型威胁与攻击。还要能够适应应用程序为适应业务变更而不断完善与更改的自然发展过程。从整个企业安全能力视图来看,威胁建模工作可以在业务系统需求管理和安全设计阶段发挥作用。考虑到方法论本身具有较强的复用性,在别的阶段和领域都会有用武之地。威胁建模的动态性体现在安全需求和安全设计的不断迭代过程中。
文章目录
一、威胁建模简史
说起威胁建模,可以追溯到本世纪初,2004年微软公司就已经从流程管理、技术措施、人员组织和考量指标四个方面清晰地定义了威胁建模能力。
威胁:
是一种不希望发生的事件。它是潜在事件,通常将它最佳形容为一种可能损坏资产或目标,或者危及其安全的影响力。从本质上看,它可能是恶意的,也可能不是恶意的。From:Microsoft
威胁建模:
是一项工程技术,可以使用它来帮助确定会对您的应用程序造成影响的威胁、攻击、漏洞和对策。您可以使用威胁建模来形成应用程序的设计、实现公司的安全目标以及降低风险。From:GBT20984
威胁建模是一个不断循环的动态模型,随着时间的推移不断更改,以适应发现的新型威胁与攻击。还要能够适应应用程序为适应业务变更而不断完善与更改的自然发展过程。微软针对威胁建模能力提供了1个流程,2个模型,1个支撑工具,多名角色定义及多个评价指标:
安全能力要素 | 描述 |
流程管理 | 第1步:标识资源;第2步:创建总体体系结构;第3步:分解应用程序;第4步:识别威胁;
第5步:记录威胁;第6步:评价威胁。 |
技术措施 | STRIDE模型:威胁识别模型;DREAD模型:威胁评价模型;
Microsoft Threat Modeling Tool:威胁建模技术工具。 |
人员组织 | 开发人员:威胁建模确认及处置者,利用威胁建模降低风险;设计人员:威胁建模发起和组织者,利用威胁建模进行技术和功能方面的安全设计并进行选择决策;
测试人员:威胁建模参与者。利用威胁建模编写测试案例 |
考量指标 | 威胁评价公式:危险 = 发生的概率×潜在的损失;威胁评价表:对威胁进行定性评价,指导威胁处置优先级;
评估报告及处置建议:明确威胁及威胁后续处置建议。 |
威胁建模能力表
2008年11月,微软宣布安全性开发生命周期(SDL)威胁建模工具的通用版本,并提供免费下载。工具的发布是微软威胁建模发展的关键点。将威胁建模能力工具化。通过在软件上绘制流程业务数据流程图(下表中的前三步),工具便会基于STRIDE模型进行威胁识别和威胁评价
序号 | 名称 | 说明 |
第1步 | 标识资源 | 找出系统必须保护的有价值的资源 |
第2步 | 创建总体体系结构 | 利用简单的图表来记录应用程序的体系结构,包括子系统、信任边界和数据流 |
第3步 | 分解应用程序 | 分解应用程序的体系结构,包括基本的网络和主机基础结构的设计,从而为应用程序创建安全配置文件。安全配置文件的目的是发现应用程序的设计、实现或部署配置中的缺陷 |
第4步 | 识别威胁 | 牢记攻击者的目标,利用对应用程序的体系结构和潜在缺陷的了解,找出可能影响应用程序的威胁 |
第5步 | 记录威胁 | 利用通用威胁模板记录每种威胁,该模板定义了一套要捕获的各种威胁的核心属性 |
第6步 | 评价威胁 | 对威胁进行评价以区分优先顺序,并首先处理最重要的威胁。这些威胁带来的危险最大。评价过程要权衡威胁的可能性,以及攻击发生时可能造成的危害。评价的结果可能是:通过对比威胁带来的风险与为使威胁得到减少所花费的成本,对于某些威胁采取的行动是不值得的 |
威胁建模流程表
从2008年至2016年,历经8年的时间,威胁建模的方法论基本没有更新。在2016年,微软公司对威胁建模工具进行了扩展性更新,主要更新了如下三个方面,其中模板编辑是个突破性的变化,使用者可以通过自定义威胁集合,识别出符合企业业务特性的威胁。
1、全新的威胁列表视图,可以基于列进行筛选和归类操作,便于定位和查看关注的威胁信息;
2、模板编辑功能,使用者可自定义威胁,扩展工具预置的威胁集;
3、可以迁移已经存在的数据流图,向下兼容2014版本文件。
二、威胁建模应用场景
从整个企业安全能力视图来看,威胁建模工作可以在业务系统需求管理和安全设计阶段发挥作用。考虑到方法论本身具有较强的复用性,在别的阶段和领域都会有用武之地。威胁建模的动态性体现在安全需求和安全设计的不断迭代过程中。
安全策略 | 企业安全策略构建 | |||||||
企业安全能力 | 规划 | 建设 | 运维 | 合规 | ||||
安全规划能力 | 现状评价能力 | 安全需求管理能力 | 安全需求识别能力 | 事件感知能力 | 威胁情报构建 | 安全标准解读能力 | 安全标准解读 | |
蓝图设计能力 | 安全需求评审能力 | |||||||
项目推导能力 | 威胁建模能力 | 漏洞感知 | 安全标准转化能力 | 等保测评协助 | ||||
项目设计能力 | 安全设计能力 | 安全域设计 | 安全检测/发现能力 | 渗透测试 | ISMS测评协助 | |||
安全基线设计 | 漏洞扫描 | 银联ADSS审计 | ||||||
应用安全设计 | 配置检查 | 电子银行评估 | ||||||
网络架构安全设计 | 业务安全分析 | 信息科技风险合规 | ||||||
安全开发能力 | 安全组件开发 | 网络架构分析 | 安全迎检能力 | 工信部检查 | ||||
安全编码制定 | 事件分析能力 | 安全日志分析 | 新业务评估 | |||||
安全部署能力 | 承载环境部署 | 安全监控 | 银监会检查 | |||||
应用环境部署 | 漏洞深度分析 | 证监会检查 | ||||||
网络环境部署 | 安全响应能力 | 应急处置 | 保监会检查 | |||||
安全发布能力 | 上线前评估 | 攻击溯源 | ||||||
安全加固 | 安全防护能力 | 安全架构 | ||||||
安全验收 | 安全策略优化 | |||||||
应急响应设计能力 | 应急体系设计 | |||||||
保障机制 | 流程管理 | 技术措施 | 人员组织 | 考量指标 | ||||
安全研究能力 | 安全课题研究 | 安全积累能力 | 知识库构建 | 安全人员培训能力 | 培训体系设计 | 安全度量能力 | 安全运营数据分析 | |
安全能力设计 | 工具集构建 | 安全培训 | 安全度量指标设计 | |||||
体系框架设计 | CTF竞赛 | |||||||
攻防演练 | ||||||||
红蓝对抗 | ||||||||
安全组织治理能力 | 安全组织架构设计 |
企业安全能力视图
场景一:安全需求识别
企业安全需求管理能力中关键活动是“安全需求识别“。下图为某企业安全需求识别流程,前期对业务系统进行场景识别,并对场景对应的安全需求进行识别,形成安全需求知识库。遇到未识别场景时,通过威胁建模方式进行威胁识别。进而导出补充安全需求。最后,整合到整体安全需求中。
安全需求识别流程图
此场景下威胁建模最大的问题是业务需求提供的资料不足以进行细粒度的威胁建模。导致安全威胁识别存在较多不适用项,准确度不高。可以通过后期的安全测试进行校验。
场景二:应用安全设计验证
安全设计阶段开展威胁建模最大的优势是具有充分的资料和相关角色辅助完成威胁建模工作。在概要设计或详细设计文档参考下,通过访谈架构师及开发人员可以准确识别资源,了解应用架构,并快速分解应用程序。进而绘制出详尽的数据流程图,识别出存在的安全威胁。设计阶段开展威胁建模工作可以依照威胁建模结果评价现有安全需求是否全面、现有安全设计在细粒度和有效性方面是否与安全目标相符。下面截取部分微软威胁建模工具生成的威胁报告:
部分数据流图
威胁列表:
- Spoofing the Browser External Entity [State: Not Started] [Priority: High]
Category: | Spoofing |
Description: | Browser may be spoofed by an attacker and this may lead to unauthorized access to Web Server. Consider using a standard authentication mechanism to identify the external entity. |
Justification: | <no mitigation provided> |
Short Description: | Spoofing is when a process or entity is something other than its claimed identity. Examples include substituting a process, a file, website or a network address. |
- Cross Site Scripting [State: Not Started] [Priority: High]
Category: | Tampering |
Description: | The web server ‘Web Server’ could be a subject to a cross-site scripting attack because it does not sanitize untrusted input. |
Justification: | <no mitigation provided> |
Short Description: | Tampering is the act of altering the bits. Tampering with a process involves changing bits in the running process. Similarly, Tampering with a data flow involves changing bits on the wire or between two running processes. |
- Elevation Using Impersonation [State: Not Started] [Priority: High]
Category: | Elevation Of Privilege |
Description: | Web Server may be able to impersonate the context of Browser in order to gain additional privilege. |
Justification: | <no mitigation provided> |
Short Description: | A user subject gains increased capability or privilege by taking advantage of an implementation bug. |
三、威胁建模方法分析
1、微软公司威胁建模方法论成熟,具有较强的落地性;
2、2014版以及之前版本威胁建模工具威胁识别结果不具有针对性,例如:web应用威胁方面,建模结果不如研究组织威胁列表具有指导性;
3、2016版本威胁建模工具通过自定义模板可弥补针对性不强缺点。但是,需要将威胁场景化并开发针对性的威胁模板。
四、威胁列表推导法
随着B/S架构应用成为主流,各大安全研究组织都对web应用的威胁进行了归纳总结。只是不同机构描述的视角有所不同。有些机构从“攻击“视角,有些机构从”测试“视角。但是都可以通过描述方式的转变转化为”威胁“视角。即形成威胁列表。威胁列表本身不是一个方法论,而是一些相关工作结果。可以以威胁列表为输入,结合业务场景分析,将业务场景与威胁建立起关联,就是威胁列表推导威胁的过程。
我们先来看看The Web Application Security Consortium (WASC)的威胁列表。
威胁项 | 描述 |
功能滥用 | 一种使用 Web 站点的自身特性和功能来对访问控制机制进行消耗、欺骗或规避的攻击方法。 |
蛮力攻击 | 猜测个人的用户名、密码、信用卡号或密钥所使用的自动化反复试验过程。 |
缓冲区溢出 | 通过覆盖内存中超过所分配缓冲区大小的部分的数据来修改应用程序流的攻击。 |
内容电子欺骗 | 一种用于诱使用户相信 Web 站点上出现的特定内容合法而不是来自外部源的攻击方法。 |
凭证/会话预测 | 一种通过推断或猜测用于识别特定会话或用户的唯一值来盗取或仿冒 Web 站点用户的方法。 |
跨站点脚本编制 | 一种强制 Web 站点回传攻击者提供的可执行代码(装入到用户浏览器中)的攻击方法。 |
跨站点请求伪造 | 一种涉及强制受害者在目标不知情或无意愿的情况下向其发送 HTTP 请求,以便以受害者身份执行操作的攻击。 |
拒绝服务 | 一种旨在阻止 Web 站点为正常用户活动提供服务的攻击方法。 |
指纹 | 攻击者的最常用方法是首先占用目标的 Web 范围,然后枚举尽可能多的信息。通过此信息,攻击者可以制定将有效利用目标主机所使用的软件类型/版本中的漏洞的准确攻击方案。 |
格式字符串 | 通过使用字符串格式化库功能访问其他内存空间来修改应用程序流的攻击。 |
HTTP 响应走私 | 一种通过期望(或允许)来自服务器的单个响应的中间 HTTP 设备将来自该服务器的 2 个 HTTP 响应“走私”到客户机的方法。 |
HTTP 响应分割 | HTTP 响应分割的实质是攻击者能够发送会强制 Web 服务器形成输出流的单个 HTTP 请求,然后该输出流由目标解释为两个而不是一个 HTTP 响应。 |
HTTP 请求走私 | 一种滥用两台 HTTP 设备之间的非 RFC 兼容 HTTP 请求的解析差异来“通过”第一台设备将请求走私到第二台设备的攻击方法。 |
HTTP 请求分割 | HTTP 请求分割是一种实现强制浏览器发送任意 HTTP 请求,从而施加 XSS 和毒害浏览器缓存的攻击。 |
整数溢出 | 当算术运算(如乘法或加法)的结果超过用于存储该运算的整数类型的最大大小时发生的情况。 |
LDAP 注入 | 一种用于对通过用户提供的输入来构建 LDAP 语句的 Web 站点加以利用的攻击方法。 |
邮件命令注入 | 一种用于对通过用户提供的未适当清理的输入来构造 IMAP/SMTP 语句的邮件服务器和 Web 邮件应用程序加以利用的攻击方法。 |
空字节注入 | 一种用于通过将 URL 编码的空字节字符添加到用户提供的数据来绕过 Web 基础结构中的清理检查过滤器的主动攻击方法。 |
操作系统命令 | 一种用于通过操纵应用程序输入来执行操作系统命令,从而对 Web 站点加以利用的攻击方法。 |
路径遍历 | 这是一种强制对可能驻留在 Web 文档根目录外的文件、目录和命令进行访问的方法。 |
可预测的资源位置 (Predictable Resource Location) | 一种用于通过做出有根据的猜测来显露所隐藏 Web 站点内容和功能的攻击方法。 |
远程文件包含 | 一种用于利用 Web 应用程序中的“动态文件包含”机制骗取应用程序包含具有恶意代码的远程文件的攻击方法。 |
路由迂回 | 一种可以注入或“劫持”中介以将敏感信息路由到外部位置的“中间人”攻击。 |
会话定置 | 将用户的会话标识强制变为显式值的一种攻击方法。在用户的会话标识定置后,攻击者会等待其登录。一旦用户进行登录,攻击者就会使用预定义的会话标识值来夺取其在线身份。 |
弱密码恢复验证 | 当 Web 站点允许攻击者非法获取、更改或恢复其他用户的密码时发生。 |
SOAP 数组滥用 | 一种期望数组可以是 XML DoS 攻击目标的 Web Service,方法是强制 SOAP 服务器在机器内存中构建巨大的数组,从而因内存预分配而在机器上施加 DoS 条件。 |
SSI 注入 | 一种服务器端利用技术,攻击者通过它可以将代码发送到 Web 应用程序中,Web 服务器稍后将在本地执行此代码。 |
SQL 注入 | 一种用于对通过用户提供的输入来构建 SQL 语句的 Web 站点加以利用的攻击方法。 |
URL 重定向器滥用 | URL 重定向器表示 Web 站点采用的将入局请求转发到备用资源的常见功能,并且可在钓鱼攻击中使用。 |
XPath 注入 | 一种用于对通过用户提供的输入来构建 XPath 查询的 Web 站点加以利用的攻击方法。 |
XML 属性爆发 | 一种针对 XML 解析器的拒绝服务攻击。 |
XML 外部实体 | 此方法利用 XML 的功能在处理时动态构建文档。XML 消息可以显式或者通过指向数据存在的 URI 来提供数据。在此攻击方法中,外部实体可以将实体值替换为恶意数据或备用引荐,或者可能危害服务器/XML 应用程序有权访问的数据的安全性。 |
XML 实体扩展 | 此方法对 XML DTD 中允许创建可在文档各处使用的定制宏(称为实体)的功能加以利用。通过以递归方式定义文档顶部的定制实体集,攻击者可以淹没尝试强制实体几乎无限迭代这些递归定义来完全解析实体的解析器。 |
XML 注入 | 一种用于操纵或破坏 XML 应用程序或服务的逻辑的攻击方法。将非意图 XML 内容和/或结构注入到 XML 消息中会变更应用程序的意图逻辑。此外,XML 注入还可导致将恶意内容插入到产生的消息/文档中。 |
XQuery 注入 | XQuery 注入是针对 XML XQuery 语言的经典 SQL 注入攻击的变体。XQuery 注入使用传递到 XQuery 命令的未适当验证的数据。 |
再来看看,根据web应用安全测试经验反推出来的威胁列表。
分类 | 威胁项 | |
信息探测 | 错误代码利用 | 错误页面信息利用 |
robots、爬虫攻击 | ||
配置攻击 | FTP匿名访问 | 第三方不可控脚本/URL利用 |
中间件配置攻击 | 过时的、用于备份的以及未被引用的文件利用 | |
默认页面检测 | Flash跨域访问 | |
默认管理后台探测 | SSL/TLS攻击 | |
管理后台默认口令攻击/默认后台弱口令攻击 | 数据库监听攻击 | |
不安全的HTTP方法攻击 | 文件扩展名处理攻击 | |
第三方开源插件探测 | 密码规则检查 | |
认证攻击 | 弱口令攻击 | 密码修改逻辑攻击 |
弱锁定机制恶意利用 | 密码重置逻辑攻击 | |
短信炸弹 | SSO认证攻击 | |
垃圾邮件攻击 | 加密信道证书传输 | |
认证绕过 | 用户枚举攻击 | |
暴力破解 | 用户账户猜测(遍历) | |
竞争条件攻击/竞态条件攻击 | 格式化字符串攻击 | |
图形验证码攻击 | 图灵攻击 | |
短信验证码攻击 | 多因素身份验证攻击 | |
权限攻击 | 目录浏览攻击 | 业务接口恶意调用 |
目录遍历攻击 | 业务逻辑攻击 | |
越权查看 | 后门利用 | |
越权操作 | 权限提升 | |
会话攻击 | Cookie属性利用 | 会话超时缺陷利用 |
Cookie伪造 | 会话及浏览器缓存利用 | |
Cookie敏感信息获取 | 冒用身份登录 | |
会话变量截获 | 跨站请求伪造(CSRF)攻击 | |
会话固定攻击 | ||
数据验证攻击 | HTTP参数污染攻击/不安全的直接对象引用 | SSI注入攻击 |
HTTP响应拆分攻击/缓存污染攻击 | IMAP/SMTP注入攻击 | |
Flash跨站脚本攻击 | 代码注入攻击 | |
反射型XSS攻击 | 命令执行注入 | |
存储型XSS攻击 | 命令执行攻击 | |
DOM型XSS攻击 | 缓冲区溢出(栈溢出、堆溢出) | |
URL跳转攻击(未验证的URL跳转) | 交易数据合法型校验攻击 | |
LDAP注入攻击 | 交易数据篡改攻击 | |
SQL注入攻击 | 交易数据重放攻击 | |
XML实体注入攻击 | 字符串格式溢出攻击 | |
XPATH注入攻击 | 孵育攻击 | |
框架注入攻击 | 文件包含攻击 | |
ORM注入攻击 | 任意文件上传攻击 | |
逻辑攻击 | 本地验证逻辑绕过 | 任意文件下载 |
拒绝服务攻击 | SQL通配符攻击 | thc ssl dos攻击 |
分配用户指定对象攻击 | Apache HTTP Server畸形头字段攻击 | |
释放资源失败攻击 | 存储过多会话数据 | |
NTP服务monlist拒绝服务攻击 | ||
AJAX攻击 | Ajax攻击 | |
服务框架攻击 | WSDL攻击 | XML内容级别攻击 |
XML结构攻击 | HTTP获取参数/REST攻击 |
五、威胁列表推导法分析
1、专项领域威胁识别较为全面,例如:WASC和OWASP对web应用和移动APP应用威胁识别较为全面;
2、缺少业务数据流分析过程,与业务系统功能或场景映射关系不直观。需要根据经验将威胁列表场景化后,在与业务系统场景进行关联;
3、需要自主研发工具进行快速威胁识别和导出。
六、综合威胁分析法
在开始讲述综合威胁分析方法之前先来回顾下威胁建模和威胁列表推导法各自的优劣势。
威胁建模 | 威胁列表推导法 | ||
优势 | 威胁建模方法论成熟,具有较强的落地性; | 优势 | 专项领域威胁识别较为全面 |
劣势 | 2014版以及之前版本威胁建模工具威胁识别结果不具有针对性 | 劣势 | 缺少业务数据流分析过程,与业务系统功能或场景映射关系不直观。 |
2016版本威胁建模工具通过自定义模板可弥补针对性不强缺点。但是,需要将威胁场景化并开发针对性的威胁模板。 | 需要自主研发工具进行快速威胁识别和导出。 |
由于威胁建模与威胁列表推导方式都存在一些劣势,因此,本文建议一种整合的威胁分析方法,即:综合威胁分析法。
综合威胁分析法是基于场景化处理结果,将威胁建模和威胁列表导出的威胁结合,再通过专家或AI判断,最终识别安全威胁的过程。
关键步骤说明:
第一步:主要完成场景化处理,一方面将业务功能进行场景化处理,另一方面将威胁列表按照场景进行分类。
例如:
业务场景包括:用户认证登录场景,账号信息查询场景,跨行转账场景等;
通用场景威胁列表,如下表所示:
用户认证登陆场景_用户枚举 |
用户认证登陆场景_空口令攻击 |
用户认证登陆场景_密码可变暴力猜解 |
用户认证登陆场景_用户名可变暴力猜解 |
用户认证登陆场景_撞库攻击 |
用户认证登陆场景_恶意锁定 |
用户认证登陆场景_Oauth认证缺陷 |
用户认证登陆场景_图形验证码绕过 |
用户认证登陆场景_图形验证码可识别 |
用户认证登陆场景_认证架构绕过 |
用户认证登陆场景_多点认证缺陷 |
用户认证登陆场景_明文密码传输 |
用户认证登陆场景_参数可预测的单点登录 |
用户认证登陆场景_记住密码和密码重置弱点 |
场景化威胁表
第二步:业务流程分析是在应用结构分析和应用分解后,完成业务数据流程图绘制过程,如下图所示:
数据流图(微软威胁建模工具绘制)
第三步:利用威胁建模工具完成威胁建模,导出威胁列表;
第四步:将第一步识别的“业务场景”和“通用场景威胁”以场景名称为关联要素进行匹配。便可获得业务场景对应的威胁列表;
第五步:通过专家分析或引入AI分析,综合威胁建模结果和场景威胁列表结果,最终导出合理的威胁列表。专家分析原则:用威胁建模结果保证威胁覆盖度,以威胁列表结果确保威胁深度。
第六步:优化活动,将威胁建模新识别的威胁进行分析、去重后录入威胁库。
七、总结
考虑到敏捷开发模式逐步成为主流,采用综合的威胁分析方法会在一定程度上会影响开发进度。因此,建议在使用综合威胁分析方法时,以场景化威胁列表方式为主体方法。功能场景化后,快速映射场景威胁列表导出威胁。遇到未识别场景时,再采用威胁建模的方式对未识别场景进行建模分析。并将新威胁分析入库。后续迭代出现类似场景即可快速识别。
文章来源:http://blog.nsfocus.net/threat-modeling/
布施恩德可便相知重
微信扫一扫打赏
支付宝扫一扫打赏