最新的2021 top 10已经出来了，我们从A01开始进行一次详细解读，本系列会详细介绍各个漏洞的变化与内容，并会着重介绍新增的漏洞情况。本篇解读A02  Cryptographic Failures（加密机制失效）。

A04:2021–不安全设计

因素

CWE映射	最大发病率	平均发病率	平均加权利用率	平均加权影响	最大覆盖范围	平均覆盖率	总发生次数	总CVE
40	24.19%	3.00%	6.46	6.78	77.25%	42.51%	262407个	2691个

概述

这是2021年的一个新类别，关注与设计和架构缺陷相关的风险，并呼吁更多地使用威胁建模、安全设计模式和参考架构。作为一个社区，我们需要超越编码空间中的“左移”行为，而是对设计安全原则至关重要的活动进行预编码。值得注意的共同弱点列举（CWE）包括CWE-209：生成包含敏感信息的错误消息,CWE-256:凭据的无保护存储,CWE-501：违反信任边界，和CWE-522:保护不足的凭据.

说明

不安全设计是一个广泛的范畴，代表不同的弱点，表现为“缺失或无效的控制设计”不安全设计并不是所有其他十大风险类别的根源。不安全的设计和不安全的实现是有区别的。我们区分设计缺陷和实现缺陷是有原因的，它们有不同的根源和补救措施。一个安全的设计仍然可能有导致漏洞被利用的实现缺陷。一个不安全的设计不可能被完美的实现所修复，因为根据定义，所需的安全控制从未被创建来抵御特定的攻击。导致不安全设计的因素之一是开发的软件或系统中缺乏固有的业务风险分析，因此无法确定需要何种级别的安全设计。

需求和资源管理

收集并与业务部门协商应用程序的业务需求，包括所有数据资产和预期业务逻辑的机密性、完整性、可用性和真实性的保护要求。考虑应用程序的公开程度，以及是否需要隔离租户（除了访问控制）。编制技术要求，包括功能性和非功能性安全性要求。计划并协商预算，包括所有设计、建造、测试和运行，包括安全活动。

安全设计

安全设计是一种文化和方法，它不断评估威胁，并确保代码经过可靠的设计和测试，以防止已知的攻击方法。威胁建模应集成到改进会议（或类似活动）中；查找数据流和访问控制或其他安全控制的更改。在用户故事开发中，确定正确的流程和故障状态，确保责任方和受影响方充分理解和同意它们。分析预期流和失败流的假设和条件，确保它们仍然准确和可取。确定如何验证假设并实施适当行为所需的条件。确保结果记录在用户情景中。从错误中吸取教训，并提供积极的激励措施来促进改进。安全设计既不是一个附加组件，也不是一个可以添加到软件中的工具。

安全开发生命周期

安全软件需要一个安全的开发生命周期、某种形式的安全设计模式、铺路方法、安全组件库、工具和威胁建模。在整个项目和软件维护的整个过程中，在软件项目的开始阶段就联系您的安全专家。考虑利用OWASP软件保证成熟度模型（SAMM）以帮助组织您的安全软件开发工作。

如何预防

• 使用AppSec建立和使用安全的开发生命周期专业人士帮助评估和设计安全性和隐私相关控制
• 建立并使用安全设计模式或铺面道路库即用组件
• 将威胁建模用于关键身份验证、访问控制，业务逻辑和关键流程
• 将安全语言和控件集成到用户情景中
• 在应用程序的每一层集成合理性检查（从前端到后端）
• 编写单元和集成测试来验证所有关键流对威胁模型有抵抗力。编译用例和滥用案例应用程序的每一层。
• 根据暴露和防护需求
• 通过设计在所有层中充分隔离租户
• 限制用户或服务的资源消耗

攻击场景示例

场景1：凭证恢复工作流可能包括“问题回答：“这是NIST 800-63b、OWASP ASV禁止的，以及OWASP前10名。问题和答案不能被认为是作为一个以上的人可以知道答案，这就是为什么他们禁止使用。这样的代码应该被删除并替换为安全设计。

场景2：电影院连锁店允许团体预订折扣，并且在要求押金前最多15名与会者。攻击者可以威胁模拟这个流程并测试他们是否可以预订600个座位所有电影院在几次请求中，造成了巨大的收入损失。

场景3：一家零售连锁店的电子商务网站没有防止黄牛党购买高端显卡运行的机器人转售拍卖网站。这给这段视频造成了可怕的宣传信用卡制造商和零售连锁店老板不能以任何价格获得这些卡片的爱好者。小心防机器人设计和领域逻辑规则，例如在几个几秒钟的可用性，可能会识别出不真实的购买和拒绝此类交易。

不安全的设计（Insecure Design）

这个漏洞是新出在Owasp榜单上的问题，猛的一看，他其实和越权很像，但从根本上来说他们其实是不一样的，因为越权漏洞的根本内容是在权限的限定上，而不安全的设计更多的是利用你的本身功能，只是说你的本身功能存在问题。

就像攻击场景示例1中所说，他并没有权限问题，只是密码提示问题这种东西本身就存在不安全的因素，假设一个攻击者通过社工或本身对你有一定的了解，那他就可以直接利用功能去重置你的密码了。

我们说的在通俗一些，不安全的设计这个漏洞就是说你设计的功能有问题这已经不是黑客攻击你的风险了，而是你运行起来就存在一定的风险了。

威胁建模

不安全的设计这种问题一旦被发现，那轻则功能修复，重则下线重构，所以我们解决这个问题的方法最好的路线就是不出现这类型漏洞，最好的防守就是进攻，那么我们最好的修复就是不出现

这样说的话我们就要引入威胁建模了，把安全风险左移，提前来发现这类型风险，把这问题解决在事前。

威胁建模流程和步骤

每种的威胁建模方法都包含一系列步骤，不同的建模方法的每个步骤存在着细微差别。首先，看一下所有这些方法共有的基本逻辑流程。对威胁建模过程最简洁明了的概述指出，威胁模型的目的是回答四个问题：

1. 我们面对的是什么？
2. 可能会有哪些问题（威胁）？
3. 我们该怎么做？
4. 我们做得好吗？

反过来，威胁建模过程应包括四个主要步骤，每个步骤都会为这些问题之一提供答案。

1. 分解应用程序或基础架构
2. 确定威胁
3. 确定对策和缓解措施
4. 排序威胁

为了准确了解这些步骤中的每个步骤，我们需要讨论构成威胁建模基础的特定技术。

威胁建模技术

上面列出的步骤中，最陌生的术语可能是分解（Decompose）。分解应用程序或基础架构意味着什么？

广义上讲，分解应用程序包括”了解应用程序及其与外部实体的交互方式。这涉及创建用例，以了解应用程序的使用方式，确定入口点以查看潜在的攻击者可以在哪里与应用程序进行交互，确定资产（即攻击者可能会感兴趣的项目/区域），并标识表示应用程序将授予外部实体的访问权限的信任级别。” （这里专门谈论应用程序安全性，但是显然，从广义上讲，这也适用于对基础结构的看法。）

分解应用程序的一种技术是构建数据流程图。这是1970年代的开发方法，以可视方式展示数据如何在应用程序或系统中移动，以及各个组件在何处更改或存储数据。其中信任边界是在2000年代初期添加进来的概念，特指数据流中的卡点，在该点上需要对数据进行验证，然后数据才能被接收该数据的实体使用。信任边界是用数据流程图进行威胁建模的关键。

• 在线银行应用的数据流程图示例

下图是在线银行应用程序的数据流程图；虚线表示信任边界，数据可能会在信任边界被更改，因此需要采取安全措施。

• 过程流程图

由于数据流程图是由系统工程师而不是安全专家开发的，因此它们包含了许多威胁建模不需要的开销。数据流程图的一种替代方法是过程流程图。两者在总体概念上相似，但后者更加精简，并且侧重于用户和执行代码在系统中的移动方式，更紧密地反映了攻击者的思维方式（例如下图）。

• 攻击树

绘制攻击树也是一种威胁建模技术，当您确定要对应用程序或基础结构潜在威胁的阶段时，它就变得非常重要。攻击树由90年代后期的信息安全传奇人物布鲁斯·施耐尔（Bruce Schneier）开创。它们由代表不同事件的一系列父节点和子节点组成，子节点是必须满足的条件才能使父节点为真。根节点（图中的最高父节点）是攻击的总体目标。借助攻击树，威胁建模者可以看到必须组合哪些情况才能使威胁成功。下图显示了一个简单的银行应用攻击树，说明了病毒可能成功感染文件的不同方式。

威胁建模框架和方法

威胁建模的各种结构化方法通常称为框架或方法论（本文中这两个术语基本上可以互换使用）。目前的威胁建模框架和方法有很多，我们挑几个最流行的介绍如下（仅拓展前三个方法）：

7种顶级威胁建模方法

• STRIDE
• DREAD
• PASTA
• VAST
• Trike
• OCTAVE
• NIST

1、STRIDE威胁建模
如上所述，STRIDE是威胁建模的祖父，最早于90年代末在Microsoft开发。STRIDE代表六种威胁，每种都对CIA三要素构成威胁，具体如下：

威胁	安全属性	定义	举例
仿冒（S）	认证	冒充人或物	冒充其他用户账号
篡改（T）	完整性	修改数据或代码	修改订单信息
抵赖（R）	审计	不承认做过某行为	不承认修改行为
信息泄露（I）	保密性	信息被泄露或窃取	用户信息被泄露
拒绝服务（D）	可用性	消耗资源、服务不可用	DDOS 导致网站不可用
权限提升（E）	授权	未经授权获取、提升权限	普通用户提升到管理员

2、DREAD威胁建模
DREAD被认为是STRIDE模型的一个附加组件，该模型使建模人员可以在确定威胁后对其进行排名。对于每个潜在威胁，DREAD代表六个问题,这些问题中的每一个都得到1-3分的评分：

3、PASTA威胁建模
PASTA代表攻击模拟和威胁分析过程，它是一个七步骤过程，致力于使技术安全要求与业务目标保持一致。每个步骤都非常复杂，由几个子步骤组成，但是总体顺序如下：

威胁建模工具

简单粗暴：https://online.visual-paradigm.com/cn/diagrams/templates/threat-model-diagram/data-flow-diagram-online-banking-application/

我们可以直接去画图玩

总结

关于本漏洞没有太多的事后办法，更多的需要开发者在事前引入安全角色来规避风险

在现在这个安全越发重要的场景下，安全左移是以后的大方向，也是最难调和的问题。

希望可以有更加成熟的产品和方案可以解决对应的问题

本文作者：Loren麟， 转载请注明来自FreeBuf.COM