OWASP-Top4-(Insecure Design不安全设计)

A04:2021 – 不安全的设计

概述

2021 年的新类别侧重于与设计和架构缺陷相关的风险，并呼吁更多地使用威胁建模、安全设计模式和参考架构。值得注意的CWE包括 CWE-209：生成包含敏感信息的错误消息、 CWE-256：未受保护的凭证存储、CWE-501：信任边界违规和CWE-522：受保护的凭证不足。

 

官方的描述

不安全设计是一个广泛的类别，代表许多不同的弱点，表现为“缺失或无效的控制设计”。缺少不安全的设计是缺少控制的地方。例如，想象一下应该加密敏感数据的代码，但没有方法。无效的不安全设计是可以实现威胁的地方，但域（业务）逻辑验证不足会阻止该操作。

安全设计是一种文化和方法，它不断评估威胁并确保代码经过稳健设计和测试，以防止已知的攻击方法。安全设计需要安全的开发生命周期、某种形式的安全设计模式或铺砌道路组件库或工具，以及威胁建模。

 

CWE-209：生成包含敏感信息的错误消息

我们所熟悉的应用程序未容错也是属于这种，以一个登录界面为例

如果登录的时候涉及到内容的加密和解密.

那么登录时用非常规手段传了一串非法的字符串进行登录.在解密的时候可能会出现一些异常,如索引越界,这样就会把异常的英文内容直接提示给页面了。

应该在编写代码的时候在登录接口中处理异常的时候, 要根据不同的异常进行处理. 业务的异常, 如密码错误,账户冻结等, 就按业务异常提示.其他意外的错误, 则统一给提示语, 屏蔽掉异常的英文内容，防止通过攻击者构造不同的。

 

 CWE-522：受保护的凭证不足

可以说CWE-522包括了CWE-256：未受保护的凭证存储

示例

此代码更改用户的密码。

糟糕的 PHP

 

$user = $_GET['user'];
$pass = $_GET['pass'];
$checkpass = $_GET['checkpass'];
如果（$pass == $checkpass）{

SetUserPassword($user, $pass);

}

 

虽然代码确认请求用户输入了两次相同的新密码，但并不能确认请求更改密码的用户是将要更改密码的同一用户。攻击者可以请求更改其他用户的密码并控制受害者的帐户。

示例

以下代码从属性文件中读取密码并使用该密码连接到数据库。

糟糕的Java

 

...
Properties prop = new Properties();
prop.load(new FileInputStream("config.properties"));
String password = prop.getProperty("password");
DriverManager.getConnection(url, usr, 密码);
...

 

此代码将成功运行，但任何有权访问 config.properties 的人都可以读取密码的值。如果不正当的员工可以访问此信息，他们可以使用它来闯入系统。

 

这个CWE在我看来利用成功会更加偏向与后渗透的那一块，或许能够获取到更多数据库的信息，对于偷盗数据，脱裤可能有帮助。

 

 

CWE-501：信任边界违规

 

先说说什么是信任边界，可以这样画一条线，一边是低信任区域，一边是高信任区域

 

 

未通过安全验证就从低信任到高信任区域的请求是不安全的，比如http的get和post请求传递的参数就是不受信任的

应该对传入的参数值进行安全检测，否则则会造成信任边界违例。如果没有建立和维护良好的信任边界，开发者将不可避免地失去对数据验证的跟踪。这种混乱最终会导致一些数据在没有验证的情况下被使用。

 

下面这个代码就是直接获取username进行使用，并没有验证username是否可信任

就直接使用了

 

 

 修复方法：

在开发阶段，增加验证逻辑，让数据安全地穿过信任边界，即从不受信任的一边移到受信任的一边。

 

 

攻击场景示例

场景 #1：凭证恢复工作流程可能包括“问答”，这是 NIST 800-63b、OWASP ASVS 和 OWASP Top 10 所禁止的。不能将问答作为多个人身份的证据可以知道答案，这就是为什么它们被禁止。此类代码应删除并替换为更安全的设计。

场景#2：连锁影院允许团体预订折扣，并且在要求押金之前最多有 15 名参与者。攻击者可以对该流程进行威胁建模，并测试他们是否可以在几次请求中一次预订 600 个座位和所有电影院，从而造成巨大的收入损失。

场景 #3：零售连锁店的电子商务网站没有针对由黄牛运行的机器人提供保护，这些机器人购买高端显卡以转售拍卖网站。这对视频卡制造商和零售连锁店主造成了可怕的宣传，并与无法以任何价格获得这些卡的爱好者之间产生了仇恨。仔细的反机器人设计和域逻辑规则，例如在可用性的几秒钟内进行的购买，可能会识别出不真实的购买并拒绝此类交易。

 

 

 

如何预防

• 与 AppSec 专业人员建立并使用安全的开发生命周期，以帮助评估和设计与安全和隐私相关的控制

• 建立和使用安全设计模式库或准备使用组件的铺好的道路

• 将威胁建模用于关键身份验证、访问控制、业务逻辑和关键流

• 编写单元和集成测试以验证所有关键流都能抵抗威胁模型