0.OWASP Top 10 - 2021

本文阅读 20 分钟
首页 代码,C/C#/C++ 正文

欢迎来到 OWASP Top 10 - 2021

img

欢迎来到 OWASP Top 10 的最新一期!OWASP Top 10 2021 是全新的,具有新的图形设计和可用的一页信息图,您可以打印或从我们的主页获取。

非常感谢为本次迭代贡献时间和数据的所有人。没有你,这一期就不会发生。谢谢!

2021 年前 10 名发生了什么变化

有三个新类别,四个类别的命名和范围发生了变化,并在 2021 年的前 10 名中进行了一些整合。我们在必要时更改了名称,以关注根本原因而不是症状。 img

A01:2021-Broken Access Control

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

A02:2021-Cryptographic Failures

上移一位至 #2,以前称为A3:2017-Sensitive Data Exposure,这是广泛的症状而非根本原因。更新后的名称侧重于与密码学相关的故障,因为它之前一直隐含着。此类别通常会导致敏感数据暴露或系统受损。

A03:2021-Injection

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

A04:2021-不安全设计

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

A05:2021-安全配置错误

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

A06:2021-Vulnerable and Outdated Components

之前的标题是使用具有已知漏洞的组件,在前 10 名社区调查中排名第二,但也有足够的数据通过数据分析进入前 10 名。该类别从 2017 年的第 9 位上升,是我们难以测试和评估风险的已知问题。它是唯一没有任何常见漏洞和暴露 (CVE) 映射到包含的 CWE 的类别,因此默认的利用和影响权重 5.0 被计入它们的分数。

A07:2021-Identification and Authentication Failures

之前是 Broken Authentication 并且从第二位下滑,现在包括与识别失败更多相关的 CWE。这个类别仍然是前 10 名的一个组成部分,但标准化框架的可用性增加似乎有所帮助。

A08:2021-软件和数据完整性故障

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

A09:2021-Security Logging and Monitoring Failures

之前是A10:2017-Insufficient Logging & Monitoring并且是从 Top 10 社区调查(#3)中添加的,从之前的 #10 上升。此类别已扩展为包括更多类型的故障,难以测试,并且在 CVE/CVSS 数据中没有得到很好的体现。但是,此类故障会直接影响可见性、事件警报和取证。

A10:2021-Server-Side Request Forgery

添加自 Top 10 社区调查 (#1)。数据显示发生率相对较低,测试覆盖率高于平均水平,并且利用和影响潜力的评级高于平均水平。此类别代表安全社区成员告诉我们这很重要的场景,即使目前数据中没有说明这一点。

方法

前 10 名的这一部分比以往任何时候都更受数据驱动,但并非盲目地受数据驱动。我们从贡献的数据中选择了 10 个类别中的 8 个,从高水平的 Top 10 社区调查中选择了两个类别。我们这样做的根本原因是,查看贡献的数据就是回顾过去。AppSec 研究人员花时间寻找新的漏洞和测试它们的新方法。将这些测试集成到工具和流程中需要时间。当我们能够可靠地大规模测试弱点时,可能已经过去了很多年。为了平衡这种观点,我们使用社区调查来询问第一线的应用程序安全和开发专家他们认为数据可能尚未显示的基本弱点。

我们采用了一些关键的变化来继续使前 10 名变得成熟。

类别的结构

与上一期的 OWASP 前十名相比,一些类别发生了变化。这是类别更改的高级摘要。

以前的数据收集工作集中在大约 30 个 CWE 的规定子集上,并有一个要求额外发现的领域。我们了解到,组织将主要关注那 30 个 CWE,很少添加他们看到的其他 CWE。在本次迭代中,我们将其打开并仅询问数据,对 CWE 没有限制。我们询问了给定年份(从 2017 年开始)测试的应用程序数量,以及在测试中发现至少一个 CWE 实例的应用程序数量。这种格式使我们能够跟踪每个 CWE 在应用程序群体中的流行程度。为了我们的目的,我们忽略频率;虽然在其他情况下可能有必要,但它仅隐藏了应用程序群体中的实际流行率。一个应用程序是否有四个 CWE 或 4 个实例,000 个实例不是前 10 名计算的一部分。我们从大约 30 个 CWE 增加到近 400 个 CWE,以在数据集中进行分析。我们计划在未来做额外的数据分析作为补充。CWE 数量的显着增加需要改变类别的结构。

我们花了几个月的时间对 CWE 进行分组和分类,并且本可以再持续几个月。我们不得不在某个时候停下来。CWE有根本原因和症状类型,其中根本原因类型如“加密失败”和“错误配置”,与“敏感数据暴露”和“拒绝服务”等症状类型形成对比。我们决定尽可能关注根本原因,因为提供识别和补救指导更合乎逻辑。关注根本原因而不是症状并不是一个新概念。前十名是症状和根本原因的混合. CWE 也是症状和根本原因的混合体;我们只是更加深思熟虑并大声疾呼。本部分中每个类别平均有 19.6 个 CWE,下限为A10: 2021-服务器端请求伪造 (SSRF) 的1 个 CWE到A04: 2021-不安全设计中的40 个 CWE 。这种更新的类别结构提供了额外的培训优势,因为公司可以专注于对语言/框架有意义的 CWE。

如何使用数据选择类别

2017 年,我们按发生率选择类别以确定可能性,然后根据数十年的可利用性、可检测性(也称为可能性)和技术影响的经验,通过团队讨论对它们进行排名。对于 2021 年,我们希望尽可能将数据用于可利用性和(技术)影响。

我们下载了 OWASP Dependency Check 并提取了 CVSS Exploit 和按相关 CWE 分组的影响分数。由于所有 CVE 都具有 CVSSv2 分数,因此需要进行大量研究和努力,但 CVSSv2 中存在 CVSSv3 应该解决的缺陷。在某个时间点之后,所有 CVE 也会被分配一个 CVSSv3 分数。此外,在 CVSSv2 和 CVSSv3 之间更新了评分范围和公式。

在 CVSSv2 中,Exploit和(技术)Impact都可以达到 10.0,但公式会将它们降低到Exploit 的60%和Impact 的40% 。在 CVSSv3 中,Exploit的理论最大值限制为 6.0 ,Impact的理论最大值限制为4.0 。考虑到权重,Impact 得分上升了,在 CVSSv3 中平均下降了近一个半点,而可利用性平均下降了近半个点。

从OWASP Dependency Check提取的国家漏洞数据库(NVD)数据中,有125k个CVE记录映射到CWE,映射到CVE的唯一CWE有241个。62k CWE 地图有一个 CVSSv3 分数,大约是数据集中人口的一半。

对于 2021 年前十名,我们按以下方式计算平均利用和影响分数。我们通过 CWE 将所有具有 CVSS 分数的 CVE 分组,并按具有 CVSSv3 分数的人口百分比 + 剩余的 CVSSv2 分数对漏洞利用和影响进行加权以获得总体平均值。我们将这些平均值映射到数据集中的 CWE,以用作风险等式另一半的利用和(技术)影响评分。

为什么不只是纯粹的统计数据?

数据中的结果主要限于我们可以以自动化方式测试的内容。与经验丰富的 AppSec 专业人员交谈,他们会告诉您他们发现的东西和他们看到的尚未在数据中的趋势。人们需要时间为某些漏洞类型开发测试方法,然后需要更多时间让这些测试自动化并针对大量应用程序运行。我们发现的一切都在回顾过去,可能会遗漏去年的趋势,而这些趋势在数据中不存在。

因此,我们只从数据中挑选了十个类别中的八个,因为它是不完整的。其他两个类别来自 Top 10 社区调查。它允许一线从业者投票选出他们认为可能没有在数据中(并且可能永远不会在数据中表达)的最高风险。

为什么是发生率而不是频率?

数据的主要来源有三个。我们将它们识别为人工辅助工具 (HaT)、工具辅助人工 (TaH) 和原始工具。

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

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

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

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

您的数据收集和分析过程是怎样的?

我们在 2017 年开放安全峰会上正式确定了 OWASP 前 10 名数据收集流程。 OWASP 前 10 名领导者和社区花了两天时间制定了透明数据收集流程的正式化。2021 版是我们第二次使用这种方法。

我们通过我们可用的社交媒体渠道发布数据征集,包括项目和 OWASP。在 OWASP 项目页面上,我们列出了我们正在寻找的数据元素和结构以及如何提交它们。在 GitHub 项目中,我们有用作模板的示例文件。我们根据需要与组织合作,以帮助确定结构并映射到 CWE。

我们从按行业测试供应商的组织、漏洞赏金供应商和提供内部测试数据的组织那里获取数据。获得数据后,我们将其加载在一起,并对 CWE 映射到风险类别的内容进行基本分析。一些 CWE 之间存在重叠,而另一些则非常密切相关(例如加密漏洞)。任何与提交的原始数据相关的决定都被记录和发布,以公开和透明地说明我们如何标准化数据。

我们查看了前 10 名中发生率最高的 8 个类别。我们还查看了前 10 名社区调查结果,看看哪些类别可能已经存在于数据中。数据中尚未出现的前两名投票将被选为前 10 名中的其他两个名额。一旦全部 10 个名额都被选中,我们将应用广义的可利用性和影响因素;帮助按照基于风险的顺序对 2021 年前 10 名进行排名。

数据因素

前 10 个类别中的每一个都列出了数据因素,它们的含义如下:

  • 映射的 CWE:前 10 名团队映射到某个类别的 CWE 数量。
  • 发生率:发生率是该组织当年测试的人群中易受该 CWE影响的应用程序的百分比。
  • (测试)覆盖率:所有组织针对给定 CWE 测试的应用程序百分比。
  • 加权漏洞利用:分配给 CVE 的 CVSSv2和 CVSSv3 分数的漏洞利用子分数映射到 CWE,归一化,并放置在 10 分的范围内。
  • 加权影响:分配给 CVE 的 CVSSv2 和CVSSv3 分数的影响子分数映射到 CWE,归一化,并放置在 10 分的范围内。
  • Total Occurrences:发现将 CWE映射到某个类别的应用程序总数。
  • 总 CVE:NVD 数据库中映射到 CWE 的 CVE 总数,映射到一个类别。

感谢我们的数据贡献者

以下组织(连同一些匿名捐赠者)为超过 500,000 个应用程序捐赠了数据,使其成为最大、最全面的应用程序安全数据集。没有你,这是不可能的。

  • 应用安全实验室
  • Cobalt.io
  • 对比安全
  • GitLab
  • 黑客一号
  • 盐酸技术
  • 微焦点
  • PenTest-工具
  • 探测
  • 方格
  • 代码
  • 白帽 (NTT)

详细一点的解释

传送门

本文为互联网自动采集或经作者授权后发布,本文观点不代表立场,若侵权下架请联系我们删帖处理!文章出自:https://blog.csdn.net/qq_45555226/article/details/122131456
-- 展开阅读全文 --
KillDefender 的 Beacon 对象文件 PoC 实现
« 上一篇 02-09
Web安全—逻辑越权漏洞(BAC)
下一篇 » 03-13

发表评论

成为第一个评论的人

热门文章

标签TAG

最近回复