OWASP Top 10漏洞解析（4）- A4:Insecure Design 不安全的设计

Web应用程序安全一直是一个重要的话题，它不但关系到网络用户的隐私，财产，而且关系着用户对程序的新人。随着Web应用程序功能持续增加，复杂性不断提高，这些程序也面临着越来越多的安全威胁和挑战。

为了帮助这些应用程序的开发团队和安全人员了解和防范这些威胁，提高安全意识，编写更安全的代码，OWASP（Open Web Application Security Project，开放式Web应用程序安全项目）发布了一份标准指南，称为OWASP Top 10。

这是一份关于Web应用程序安全风险的标准指南，它基于全球范围内的安全专家和数据提供者的共识，列出了当前最严重、最关键的10种Web应用程序安全风险，并提供了相应的防范措施和建议。OWASP Top10 每隔几年会更新一次（目前已经发布了六个版本，分别是2004年、2007年、2010年、2013年、2017年和2021年），最新的版本是在2021年发布的OWASP Top10:2021。

已解析的OWASP漏洞

1. OWASP Top 10漏洞解析（1）- A1:Broken Access Control 访问控制失效：https://bbs.huaweicloud.com/blogs/400993
2. OWASP Top 10漏洞解析（2）- A2:Cryptographic Failures 加密机制失效：https://bbs.huaweicloud.com/blogs/405125
3. OWASP Top 10漏洞解析（3）- A3:Injection 注入攻击：https://bbs.huaweicloud.com/blogs/407990

“不安全的设计”缺陷详情

本文的主题是OWASP Top10:2021中的第4条缺陷：Insecure Design 不安全的设计，它是该版本中新出现的一个关注设计和架构缺陷相关风险的类别，该缺陷呼吁大家更多地使用威胁建模、安全设计模式和参考架构。

我们不仅仅在代码编写层面要做到“安全左移”，同时在编码前活动的安全性也需要关注，这些活动对于“安全设计”原则都是至关重要的。安全设计相关的缺陷里相对较为知名的有：CWE-209 生成包含敏感信息的错误消息，CWE-256 未保护的凭据存储，CWE-522 保护不足的凭据等。

不安全的设计可以说是一个广泛的类别，代表着不同的弱点，可以表达为“缺失的或则无效的控制设计”。要注意的是，不安全的设计并非是其它所有top 10类别风险的来源，不安全的设计和不安全的实现之间还是有区别的。我们之所以要区分设计和实现层面两种缺陷，就在于它们的发生有着不同的根本原因，而修复方面也有着不同的补救措施。一个安全的设计仍然可能在实现层面上有缺陷，产生可能会被利用的漏洞。根据定义，一个不安全的设计不能通过完美的实现来修复，这也很好理解，因为在设计阶段就没有考虑要去创建必要的安全控制来防御特定的攻击。导致不安全的设计的其中一个因素就是缺乏对正在开发的软件或系统固有的业务的风险分析，因此未能确定所需的安全设计级别。

常见的“不安全的设计”缺陷类型

在需求和资源管理方面，我们不仅需要考虑与业务方收集和协商应用程序的业务需求，包括涉及所有数据资产的保密性、完整性、可用性和真实性以及预期的业务逻辑的保护需求。还需要考虑我们的应用程序将面临多大的暴露程度，以及是否需要对租户进行隔离（除了访问控制）。要计划和协商涵盖所有设计、构建、测试和运营的预算，包括安全活动。

在安全设计方面，因为安全设计是一种文化和方法，它会不断的评估威胁来确保代码经过健壮的设计和测试，以防止已知的攻击方式。其中，威胁建应该被集成到细化的会议中，来寻找数据流和访问控制或其他安全控制的变化。在用户开发中确定好正确的流程和失败状态，确保流程和状态所负责和影响的各部分充分的理解和认可。做好预期分析和失败流程的假设，确保它们的准确和可取。确定如何验证假设并强制执行正确行为所需的条件。确保结果记录在用户故事中。从错误中学习，并提供积极的激励来促进改进。总之，安全设计既不是一个附加物，也不是一个可以添加到软件中的工具，它是一种文化和方法。

在安全开发生命周期方面，安全的软件需要一个安全的开发生命周期，一些形式的安全设计模式，铺平道路的方法，安全的组件库，工具和威胁建模。在软件项目的开始阶段，就需要一位安全专家，贯穿整个项目和软件的维护。

如何防止该缺陷的发生

如何防止该缺陷的发生，可以运用如下这些举措：

• 建立并使用安全的开发生命周期，与 AppSec 专业人员合作，帮助评估和设计与安全和隐私相关的控制
• 建立并使用安全设计模式或现成的成熟组件库
• 对关键的身份验证、访问控制、业务逻辑和关键流程进行威胁建模
• 将安全语言和控制集成到用户故事中
• 在应用程序的每个层级（从前端到后端）进行合理性检查
• 编写单元和集成测试，以验证所有关键流程能够抵抗威胁模型。为应用程序的每个层级编译用例和误用例。
• 根据暴露和保护需求，在系统和网络层上分隔层级
• 通过设计在所有层级上强力分隔租户
• 限制用户或服务的资源消耗

举个栗子

场景1

一个凭证可以恢复的工程流，里面可能包含有“问题和答案”，这是被 NIST 800-63b、OWASP ASVS 和 OWASP Top 10 所禁止的。问题和答案不能作为身份的证据，因为不止一个人可以知道答案，这就是为什么它们被禁止的原因。这样的代码应该被删除，并用更安全的设计替换。

场景2

一个连锁电影院允许团体预订折扣，并且在团体人数达到15名之前，允许不用交押金。攻击者可以对这个流程进行威胁建模，并测试他们是否可以在几个请求中一次预订六百个座位或则说所有这些连锁电影院的位置，让这连锁店造成巨大的收入损失。

场景3

一个零售业务的连锁电子商务网站没有对由黄牛运行的机器人进行防御，导致这些机器人可以购买高端显卡，然后在拍卖网站上转卖。这给显卡制造商和零售连锁店老板造成了很坏的影响，也给无法以合适价格获得这些卡片的爱好者带来了持久的痛苦，不愿意再来网站上购买。周全的反机器人设计和详尽的领域逻辑规则，比如在可用的几秒钟内进行的连续购买，可以识别出不真实的购买，并拒绝这样的交易。

参考链接

1. https://owasp.org/Top10/A04_2021-Insecure_Design/