安全风险在WEB应用中的变化

举报
码乐 发表于 2024/07/16 09:04:28 2024/07/16
【摘要】 本文介绍OWASP的安全风险评估,一个国际非营利组织,专注于提升Web应用安全。其Top 10项目列出最严重的安全风险,如Broken Access Control(现最严重风险),加密故障,注射漏洞,不安全设计,配置错误等。2021版新增了不安全设计、软件完整性故障和服务器端请求伪造等类别。安全问题排名考虑了发生率,以反映攻击者只需一个实例即可造成损害的风险。

1 简介

OWASP 代表 开放 Web 应用程序安全项目。它是一个国际非营利组织,致力于 Web 应用程序的安全性。

OWASP的核心原则包括其材料在其网站上免费且易于访问。

他们的动机是使任何用户都可以提高他们的 Web 应用程序安全性。他们提供的材料包括文档、视频、工具和论坛。

OWASP Top 10 是最著名的项目。OWASP基金会还在网络安全领域组织了许多领先的教育和培训计划。

2 WEB安全风险变化

从17到21年的安全风险排名变化:

A01:2021-Broken Access Control 从第五位上升到具有最严重 Web 应用程序安全风险的类别;贡献的数据表明,平均而言,3.81% 的受测应用程序具有一个或多个常见弱点枚举 (CWE),在此风险类别中 CWE 的发生率超过 318k。映射到 Broken Access Control 的 34 个 CWE 在应用程序中的出现次数比任何其他类别都多。

A02:2021-加密故障将位置上升一个至#2,以前称为A3:2017-敏感数据暴露,这是广泛的症状,而不是根本原因。更新后的名称侧重于与密码学相关的故障,因为它以前是隐含的。此类别通常会导致敏感数据泄露或系统泄露。

A03:2021-注射滑落到第三个位置。94% 的应用程序进行了某种形式的注射测试,最大发生率为 19%,平均发生率为 3.37%,映射到此类别的 33 个 CWE 在应用程序中出现次数第二多,为 274k 次。跨站点脚本现在是此版本中此类别的一部分。

A04:2021-不安全设计是 2021 年的新类别,重点关注与设计缺陷相关的风险。如果真的想作为一个行业“向左移动”,需要更多的威胁建模、安全的设计模式和原则以及参考架构。不安全的设计无法通过完美的实现来解决,因为根据定义,从未创建过所需的安全控制来防御特定的攻击。

A05:2021-安全配置错误从上一版的#6上移;90% 的应用程序进行了某种形式的错误配置测试,平均发生率为 4.5%,超过 208k 次的 CWE 发生率映射到此风险类别。随着越来越多的人转向高度可配置的软件,看到这一类别的上升也就不足为奇了。A4:2017-XML 外部实体 (XXE) 的前一类别现在是此风险类别的一部分。

A06:2021-易受攻击和过时的组件以前的标题是“使用具有已知漏洞的组件”,在前 10 名社区调查中排名 #2,但也有足够的数据通过数据分析进入前 10 名。该类别从2017年的#9上升,这是一个已知的问题,正在努力测试和评估风险。它是唯一一个没有将任何常见漏洞和披露 (CVE) 映射到所包含的 CWE 的类别,因此默认漏洞利用和影响权重 5.0 被计入其分数。

A07:2021-识别和身份验证失败以前是“身份验证中断”,现在从第二个位置向下滑动,现在包括与识别失败更相关的 CWE。这一类别仍然是前 10 名中不可或缺的一部分,但标准化框架可用性的增加似乎有所帮助。

A08:2021 - 软件和数据完整性故障是 2021 年的新类别,侧重于在不验证完整性的情况下做出与软件更新、关键数据和 CI/CD 管道相关的假设。映射到此类别中 10 个 CWE 的常见漏洞和披露/通用漏洞评分系统 (CVE/CVSS) 数据中权重最高的影响之一。A8:2017-不安全的反序列化现在是这个更大类别的一部分。

A09:2021-Security Logging and Monitoring Failures 之前是 A10:2017-Insufficient Logging & Monitoring,是从前 10 名社区调查 (#3) 中添加的,从之前的 #10 上升。此类别已扩展为包括更多类型的故障,测试起来具有挑战性,并且在 CVE/CVSS 数据中没有很好地表示。但是,此类别中的故障可能会直接影响可见性、事件警报和取证。

A10:2021-服务器端请求伪造是从十大社区调查 (#1) 中添加的。数据显示,发生率相对较低,测试覆盖率高于平均水平,漏洞利用和影响潜力评级也高于平均水平。此类别表示安全社区成员告诉这很重要的场景,即使目前数据中没有说明这一点。

3 小结

OWASP评估的WEB安全问题有三个主要数据来源。它们分类为人工辅助工具 (HaT)、工具辅助人工 (TaH) 和原始工具。

Tooling 和 HaT 是高频查找发生器。工具将查找特定的漏洞,并孜孜不倦地尝试查找该漏洞的每个实例,并将为某些漏洞类型生成高发现计数。
看看跨站点脚本,它通常是两种类型之一:它要么是一个小的、孤立的错误,要么是一个系统性问题。
当它是一个系统性问题时,单个应用程序的发现安全问题计数可能达到数千个。这种单个问题的高频次显式淹没了报告或数据中发现的大多数其他漏洞。

另一方面,TaH 会发现更广泛的漏洞类型,但由于时间限制,频率要低得多。
当人们测试一个应用程序并看到类似跨站点脚本的东西时,他们通常会找到三到四个实例并停止。
他们可以确定一个系统性的发现,并写下一个建议,以便在应用程序范围内进行修复。无需(或时间)查找每个实例。

假设采用这两个不同的数据集,并尝试按频率合并它们。
在这种情况下,Tooling 和 HaT 数据将淹没更准确(但更广泛)的 TaH 数据,
这也是为什么像 Cross-Site Scripting 这样的东西在许多安全问题排名中排名如此之高,而影响通常为低到中等的原因,这是因为大量的发现。(跨站点脚本也相当容易测试,因此还有更多)。

2017 年,引入了使用发生率来重新审视数据,并将 Tooling 和 HaT 数据与 TaH 数据干净地合并。
发生率询问应用程序群中至少有一个漏洞类型实例的百分比。
不在乎它是一次性的还是系统性的。这与目的无关;只需要知道有多少应用程序至少有一个实例,这有助于更清晰地了解测试是跨多种测试类型的结果,而不会将数据淹没在高频结果中。
这与风险相关视图相对应,因为攻击者只需要一个实例即可通过类别成功攻击应用程序。

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。