OWASP(开放Web软体安全项目- Open WebApplication Security Project)是一个开放社群、非盈利性组织,长期致力于协助政府或企业了解并改善网页应用程式与网页服务

以下是两个从OWASP搜索下来然后翻译的例子,可以让我们更加了解该网站。

1、

A02:2021 – 加密失败

图标

因素

映射的 CWE最大发生率平均发生率平均加权漏洞利用平均加权影响最大覆盖范围平均覆盖率总发生次数CVE 总数
2946.44%4.49%7.296.8179.33%34.85%233,7883,075

概述

上移一个位置到#2,以前称为敏感数据暴露,这更像是一种广泛的症状而不是根本原因,重点是与密码学(或缺乏密码学)相关的故障。这往往会导致敏感数据的暴露。包括的值得注意的常见弱点枚举 (CWE) 包括CWE-259:使用硬编码密码CWE-327:损坏或有风险的加密算法CWE-331 熵不足

描述

首先是确定传输中和静止数据的保护需求。例如,密码、信用卡号、健康记录、个人信息和商业秘密需要额外保护,主要是如果该数据属于隐私法(例如欧盟的通用数据保护条例 (GDPR))或法规(例如金融数据保护)例如 PCI 数据安全标准 (PCI DSS)。对于所有此类数据:

  • 是否有任何数据以明文传输?这涉及 HTTP、SMTP、FTP 等协议也使用 TLS 升级,如 STARTTLS。外部互联网流量是危险的。验证所有内部流量,例如,负载平衡器、Web 服务器或后端系统之间的流量。

  • 默认情况下或在较旧的代码中是否使用任何旧的或弱的加密算法或协议?

  • 是否正在使用默认加密密钥、生成或重复使用弱加密密钥,或者是否缺少适当的密钥管理或轮换?加密密钥是否已签入源代码存储库?

  • 是否未强制执行加密,例如,是否缺少任何 HTTP 标头(浏览器)安全指令或标头?

  • 收到的服务器证书和信任链是否经过正确验证?

  • 对于加密操作模式,初始化向量是否被忽略、重用或没有足够安全地生成?是否使用了不安全的操作模式,例如欧洲央行?当认证加密更合适时是否使用加密?

  • 在没有密码基密钥派生函数的情况下,是否将密码用作加密密钥?

  • 随机性是否用于并非旨在满足加密要求的加密目的?即使选择了正确的功能,它是否需要由开发人员播种,如果不需要,开发人员是否用缺乏足够熵/不可预测性的种子覆盖了内置的强大播种功能?

  • 是否使用过时的哈希函数,例如 MD5 或 SHA1,或者在需要加密哈希函数时使用非加密哈希函数?

  • 是否在使用已弃用的加密填充方法,例如 PKCS number 1 v1.5?

  • 加密错误消息或边信道信息是否可利用,例如以填充预言机攻击的形式?

请参阅 ASVS 加密 (V7)、数据保护 (V9) 和 SSL/TLS (V10)

如何预防

至少执行以下操作,并查阅参考资料:

  • 对应用程序处理、存储或传输的数据进行分类。根据隐私法、监管要求或业务需求确定哪些数据是敏感的。

  • 不要不必要地存储敏感数据。尽快丢弃它或使用符合 PCI DSS 的标记化甚至截断。未保留的数据不能被窃取。

  • 确保加密所有静态敏感数据。

  • 确保拥有最新且强大的标准算法、协议和密钥;使用适当的密钥管理。

  • 使用安全协议(例如具有前向保密 (FS) 密码的 TLS、服务器的密码优先级和安全参数)加密所有传输中的数据。使用 HTTP 严格传输安全 (HSTS) 等指令强制加密。

  • 对包含敏感数据的响应禁用缓存。

  • 根据数据分类应用所需的安全控制。

  • 不要使用传统协议(例如 FTP 和 SMTP)来传输敏感数据。

  • 使用具有工作因子(延迟因子)的强自适应和加盐散列函数存储密码,例如 Argon2、scrypt、bcrypt 或 PBKDF2。

  • 必须选择适合操作模式的初始化向量。对于许多模式,这意味着使用 CSPRNG(密码安全伪随机数生成器)。对于需要随机数的模式,则初始化向量 (IV) 不需要 CSPRNG。在所有情况下,对于一个固定键,IV 永远不应该被使用两次。

  • 始终使用经过身份验证的加密,而不仅仅是加密。

  • 密钥应该以加密方式随机生成并作为字节数组存储在内存中。如果使用密码,则必须通过适当的密码基密钥派生函数将其转换为密钥。

  • 确保在适当的地方使用加密随机性,并且没有以可预测的方式或低熵播种。大多数现代 API 不需要开发人员为 CSPRNG 设置种子以获得安全性。

  • 避免不推荐使用的加密函数和填充方案,例如 MD5、SHA1、PKCS number 1 v1.5。

  • 独立验证配置和设置的有效性。

示例攻击场景

场景#1:应用程序使用自动数据库加密对数据库中的信用卡号进行加密。但是,这些数据在检索时会自动解密,从而允许 SQL 注入缺陷以明文形式检索信用卡号。

场景#2:站点不会对所有页面使用或强制执行 TLS 或支持弱加密。攻击者监视网络流量(例如,在不安全的无线网络中),将连接从 HTTPS 降级为 HTTP,拦截请求并窃取用户的会话 cookie。然后攻击者重放这个 cookie 并劫持用户的(经过身份验证的)会话,访问或修改用户的私人数据。除了上述之外,他们还可以更改所有传输的数据,例如,汇款的接收者。

场景#3:密码数据库使用未加盐或简单的哈希来存储每个人的密码。文件上传缺陷允许攻击者检索密码数据库。所有未加盐的哈希值都可以通过预先计算的哈希值彩虹表公开。由简单或快速散列函数生成的散列可能会被 GPU 破解,即使它们被加盐。

2、 

A04:2021 – 不安全的设计

图标

因素

映射的 CWE最大发生率平均发生率平均加权漏洞利用平均加权影响最大覆盖范围平均覆盖率总发生次数CVE 总数
4024.19%3.00%6.466.7877.25%42.51%262,4072,691

概述

2021 年的新类别侧重于与设计和架构缺陷相关的风险,并呼吁更多地使用威胁建模、安全设计模式和参考架构。作为一个社区,我们需要超越编码空间中的“左移”,以预编码对设计安全原则至关重要的活动。值得注意的常见弱点枚举 ( CWE ) 包括CWE-209:生成包含敏感信息的错误消息CWE-256:未受保护的凭证存储CWE-501:信任边界违规CWE-522:受保护的凭证不足

描述

不安全设计是一个广泛的类别,代表不同的弱点,表示为“缺失或无效的控制设计”。不安全的设计并不是所有其他 10 大风险类别的来源。不安全的设计和不安全的实现之间是有区别的。我们区分设计缺陷和实施缺陷是有原因的,它们有不同的根本原因和补救措施。安全设计仍可能存在实现缺陷,从而导致可能被利用的漏洞。不安全的设计无法通过完美的实现来修复,因为根据定义,从来没有创建所需的安全控制来防御特定的攻击。导致设计不安全的因素之一是正在开发的软件或系统中缺乏固有的业务风险分析,

需求和资源管理

收集并与企业协商应用程序的业务需求,包括有关所有数据资产的机密性、完整性、可用性和真实性以及预期业务逻辑的保护要求。考虑您的应用程序的公开程度以及您是否需要隔离租户(此外还需要访问控制)。编译技术要求,包括功能性和非功能性安全要求。规划和协商涵盖所有设计、构建、测试和运营(包括安全活动)的预算。

安全设计

安全设计是一种文化和方法,它不断评估威胁并确保代码经过稳健设计和测试,以防止已知的攻击方法。威胁建模应整合到细化会议(或类似活动)中;寻找数据流和访问控制或其他安全控制的变化。在用户故事开发中,确定正确的流程和故障状态,确保责任方和受影响方充分理解并同意它们。分析预期和失败流的假设和条件,确保它们仍然准确和可取。确定如何验证假设并强制执行正确行为所需的条件。确保结果记录在用户故事中。从错误中学习并提供积极的激励措施来促进改进。

安全开发生命周期

安全软件需要安全的开发生命周期、某种形式的安全设计模式、铺好的道路方法、安全的组件库、工具和威胁建模。在整个项目和软件维护过程中,在软件项目开始时联系您的安全专家。考虑利用OWASP 软件保障成熟度模型 (SAMM)来帮助构建您的安全软件开发工作。

如何预防

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

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

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

  • 将安全语言和控件集成到用户故事中

  • 在应用程序的每一层(从前端到后端)集成合理性检查

  • 编写单元和集成测试以验证所有关键流都能抵抗威胁模型。为应用程序的每一层编译用例误用用例。

  • 根据暴露和保护需求分离系统层和网络层上的层

  • 通过设计在所有层中强有力地隔离租户

  • 限制用户或服务的资源消耗

示例攻击场景

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

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

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

通过在OWASP中的学习,我们可以了解到更多前沿的网络安全知识,对我们的成长特别有帮助。OWASP 测试和代码审查指南为开发人员提供了评估软件的有益信息。测试指南包含组织可用于应用识别常见 Web 应用程序或服务安全问题的技术的信息。组织也可以参考 OWASP 代码审查指南来实施创建更安全软件的实践。OWASP 建议 Web 开发人员应实施日志记录和监控以及事件响应计划,以确保他们意识到对其应用程序的攻击。
 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值