Owasp Top2021中文版

Owasp Top2021中文版

以下出自《Welcome to the OWASP Top 10 – 2021》翻译

图片[1]-Owasp Top2021中文版-FancyPig's blog

欢迎来到最新版本的 OWASP Top 10!! OWASP Top 10 2021 是一个全新的名单,包含了你可以列印下来的新图示说明,若有需要的话,你可以从我们的网页上面下载。

在此我们想对所有贡献了他们时间和资料的人给予一个极大的感谢。没有你们,这一个新版本是不会出现的。谢谢。

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

这次在 OWASP Top 10 for 2021 有三个全新的分类,有四个分类有做名称和范围的修正,并有将一些类别做合并。

图片[2]-Owasp Top2021中文版-FancyPig's blog
  • A01:2021-权限控制失效 从第五名移上来; 94% 被测试的应用程式都有验测到某种类别权限控制失效的问题。在权限控制失效这个类别中被对应到的 34 个 CWEs 在验测资料中出现的次数都高于其他的弱点类别。
  • A02:2021-加密机制失效 提升一名到第二名,在之前为 敏感资料外曝,在此定义下比较类似于一个广泛的问题而非根本原因。在此重新定义并将问题核心定义在加密机制的失败,并因此造成敏感性资料外洩或是系统被破坏。
  • A03:2021-注入式攻击 下滑到第三名。94% 被测试的应用程式都有验测到某种类别注入式攻击的问题。在注入式攻击这个类别中被对应到的 33 个 CWEs 在验测资料中出现的次数为弱点问题的第二高。跨站脚本攻击现在在新版本属于这个类别。
  • A04:2021-不安全设计 这是 2021 年版本的新类别,并特别针注在与设计相关的缺失。如果我们真的希望让整个产业”向左移动”*注一*,那我们必须进一步的往威胁建模,安全设计模块的观念,和安全参考架构前进。*注一: Move Left 于英文原文中代表在软体开发及交付过程中,在早期找出及处理相关问题,同 Shift Left Testing。*
  • A05:2021-安全设定缺陷 从上一版本的第六名移动上来。90% 被测试的应用程式都有验测到某种类别的安全设定缺陷。在更多的软体往更高度和有弹性的设定移动,我们并不意外这个类别的问题往上移动。在前版本中的 XML 外部实体注入攻击 (XML External Entities)现在属于这个类别。
  • A06:2021-危险或过旧的元件 在之前标题为 使用有已知弱点的元件。在本次版本中于业界问卷中排名第二,但也有足够的统计资料让它可以进入 Top 10。这个类别从 2017 版本的第九名爬升到第六,也是我们持续挣扎做测试和评估风险的类别。这也是唯一一个没有任何 CVE 能被对应到 CWE 内的类别,所以预设的威胁及影响权重在这类别的分数上被预设为 5.0。
  • A07:2021-认证及验证机制失效 在之前标题为 错误的认证机制。在本次版本中油第二名下滑至此,并同时包含了将认证相关缺失的 CWE 包含在内。这个类别仍是 Top 10 不可缺少的一环,但同时也有发现现在标准化的架构有协助降低次风险发生机率。
  • A08:2021-软件及资料完整性失效 这是 2021 年版本全新的类别,并在软体更新,机敏及重要资料,和 CI/CD 管道中并没有做完整性的确认为前提做假设并进行评估。在评估中影响权重最高分的 CVE/CVSS 资料都与这类别中的 10 个 CWE 对应到。2017 年版本中不安全的反序列化现在被合併至此类别。
  • A09:2021-安全记录及监控失效 在之前为不完整的纪录及监控并纳入在业界问卷中在本次列名为第三名并从之前的第十名上移。这个类别将扩充去纳入更多相关的缺失,但这也是相当难去验证,并没有相当多的 CVE/CVSS 资料可以佐证。但是在这个类别中的缺失会直接影响到整体安全的可视性,事件告警及鑑识。
  • A10:2021-服务端请求伪造 这个类别是在业界问卷排名第一名,并在此版本内纳入。由资料显示此问题有较低被验测次数和范围,但有高于平均的威胁及影响权重比率。这个类别的出现也是因为业界专家重複申明这类别的问题相当重要,即使在本次资料中并没有足够的资料去显示这个问题。

分析方法

本次 Top 10 的选择方式比以往更重视资料分析,但并不是完全以资料分析为主。我们从资料分析中挑选了八个风险类别,然后由业界问卷中挑选两个风险类别。我们从过往的分享资料中去了解,并有我们一个基本的理由。原因是所有的资安研究人员都不断的在找新的弱点并找出方法去验证弱点,但会需要时间才能将这些验测方法纳入到既有的工具和测试流程中。当我们能有效的大量测试这个弱点时,有可能已经过了多年的时间。为了要让两者之间有平衡,我们使用业界问卷请教在前线的网安研究专家们并瞭解他们觉得有哪些是他们觉得严重但尚未出现在测试资料中的漏洞及问题。

这是几个我们为了要让 OWASP Top 10 更加成熟的重要改变。

如何建构风险类别

有别于上一个版本,在这次的 OWASP Top 10 有一些风险类别的修改。我们在此以比较高的角度说明一下这次的类别修改。

在上一次的资料收集当中,我们将资料收集的重心放在预先定义好的约 30 个 CWEs 并纳入一个栏位徵求其他的发现。从这裡我们看到决多数的组织都只会专注在这 30 个 CWEs 而不常加入其他他们可能发现的 CWEs。在这次的改版中,我们将所有的问题都以开放式的方法处理,并没有限制在任何一个 CWEs。我们请教了从 2017 年开始所测试的网页应用程式数量,然后在这些程式中至少有一个 CWE 被发现的数量。这个格式让我们能够追踪每个 CWE 跟所有被验测及统计的应用程式的数量跟关係。我们也忽略了 CWE 出现的频率,虽然在某些状况下这也许是必须的,但这却隐藏了风险类别本身与应用程式数量整体的关係。所以一个应用程式有 4 个或是 4,000 个弱点并不是被计算在 Top 10 的基础。但同时我们也从原本的 30 多个 CWEs 增长到快 400 多个CWEs 去进行分析。我们因此也计画未来做更多的资料分析,并在对此版本进行补充说明。而这些增加的 CWEs 也同时影响了这次风险类别的规划。

我们花了好几个月将 CWEs 进行分组跟分类,而且其实可以一直花更多个月去做这件事情。但我们必须在某一个时间点停住。在 CWEs 当中,同时有 原因 以及 症状 的问题,而像是 “加密机制失效” 和 “设定问题” 这类型的 原因 与 “机敏资料外洩” 和 “阻断服务” 这类型的 症状 是对立的。因此我们决定在可以的时候要更专注于底层的原因,因为这是可以有效指出问题的本体跟同时提供问题的解决方向。专注在问题核心而不将重心放在症状并不是一个新的概念,Top Ten 有史以来一直是症状跟问题核心的综合体,只是这次我们更刻意的将他突显出来。在这次的新版本中,每一个类别内的平均有 19.6 个 CWE,而最低的 A10:2021-伺服端请求伪造 有一个 CWE 到 A04:2021-不安全设计 有四十个 CWE。这个新的类别架构能提供企业更多的资安训练的好处,因为在新的架构下可以更专注在某个语系或平台上的 CWE。

选择类别时资料的使用方式

在 2017 年,我们用事件发生次数去判断可能发生的机率去选择类别,然后透过一群在业界拥有数十年经验的专家团对讨论并依照 可发生性,可发现性(同可能性),和 技术影响力 去做排名。在 2021 年,我们希望如果可以的话用资料证明可发生性和技术影响性。

我们下载了 OWASP Depndency Check 并取出了 CVSS 漏洞,并将相关的 CWE 用影响力分数分群。这花了一些时间和力气去研究因为所有的 CVEs 都有 CVSSv2 分数,但是在其中因为 CVSSv2 跟 CVSSv3 之间有一些缺失是必须被修正的。经过了一段时间后,所有的 CVEs 都会有对应的 CVSSv3 的分数。再者,分数的范围和计算的公式在 CVSSv2 和 CVSSv3 之间也做了更新。

在 CVSSv2 中,漏洞和影响力两者都可达到 10.0 分,但是公式本身会将两者调整为漏洞佔 60%,然后影响力佔 40%。在 CVSSv3 中,理论上的最高值将漏洞限制在 6.0 分而影响力在 4.0 分。当考虑到权重比率时,影响力的分数会偏高,在 CVSSv3 中几乎平均会多出 1.5 分,而漏洞分数却会平均少 0.5 分。

从 OWASP Dependcy Check 翠取出的 NVD 资料当中有将近 12.5 万笔 CVE 资料有对应到 CWE,而有 241 笔独特的 CWEs 有对应到 CVE。6.2万笔 CWE 有对应到 CVSSv3 分数,所以大约是整体资料中一半的部分。

而在 Top Ten,我们计算漏洞和影响力的平均分数的方式如下。我们将所有有 CVSS 分数的 CVE 依照 CWE 分组,然后依照有 CVSSv3 的漏洞和影响力在所有资料中的百分比作权重,在加上资料中有 CVSSv2 的资料去做平均。我们将这些平均后的 CWEs 对应到资料中,然后将他的漏洞和引想力分数使用在另一半的风险公式中。

为什么就不纯粹做统计分析?

这些资料的结果最主要是被限制在能使用自动工具测试出来的结果。可是当你跟一位有经验的应用程式安全专家聊的时候,他们会跟你说绝大多数他们找到的问题都不在这些资料裡面。原因是一个测试要被自动化的时候,需要花时间去开发这些弱点测试的方法论,当你需要将这个测试自动化并能对大量的应用程式去验证时,又会花上更多的时间。当我们回头看去年获以前有可能没出现的一些问题的趋势,我们发现其实都没有在这些资料当中。

因此,由于资料不完全的关係,我们只有从资料中选出 8 个类别,而并不是 10 个。剩下的两个类别是从业界问卷中所选出的。这会允许在前线的参与者去选出他们认为的高风险,而不是纯粹依据资料去判断(甚至可能资料永远都不会有出现的踪迹)。

为什么用事故率而不是用发生次数?

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

工具化和HaT是高频的查找生成器。工具会寻找特定的漏洞,并不知疲倦地试图找到该漏洞的每一个实例,并对某些漏洞类型产生高的发现次数。看看跨网站脚本,它通常有两种情况:要么是一个较小的、孤立的错误,要么是一个系统性的问题。当它是一个系统性的问题时,对于一个应用程序来说,发现的数量可能是成千上万的。这种高频率淹没了报告或数据中发现的大多数其他漏洞。

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

假设我们采取这两个不同的数据集,并试图在频率上将它们合并。在这种情况下,工具和HaT数据将淹没在更准确(但广泛)的TaH数据中,这也是为什么像跨站脚本这样的东西在许多列表中排名如此之高,而其影响通常是低到中等的。这是因为发现的数量太大。(跨站脚本也是相当容易测试的,所以也有很多测试)。

在2017年,我们引入了使用发生率,以重新审视数据,并将工具和HaT数据与TaH数据干净地合并。发生率问的是应用人群中至少有一个漏洞类型的实例的百分比。我们并不关心它是一次性的还是系统性的。这与我们的目的无关;我们只需要知道有多少应用程序至少有一个实例,这有助于更清楚地了解多种测试类型的测试结果,而不会使数据淹没在高频结果中。

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

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

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

我们从作为测试供应商的组织、错误赏金供应商以及提供内部测试数据的组织那里获得数据。一旦我们有了数据,我们就把它加载到一起,并对哪些CWEs映射到风险类别进行基本分析。一些CWEs之间存在重叠,而另一些则是非常密切相关的(例如,加密漏洞)。任何与提交的原始数据有关的决定都会被记录和公布,以使我们对数据的规范化公开和透明。

我们看一下发生率最高的八个类别,以列入前十名。我们也看一下行业调查结果,看看哪些可能已经存在于数据中。在数据中尚未出现的前两票将被选为前十名中的另外两个名额。一旦所有10个被选中,我们应用可利用性和影响的一般化因素;以帮助对前10名进行排序。

数据因素

有一些数据因素被列在十大类别中的每一个,以下是它们的含义。

  • 绘制的CWEs:前十名团队映射到某一类别的 CWE 数量。
  • 事故率:发生率是指该组织当年测试的人群中易受该CWE影响的应用程序的百分比。
  • (测试)覆盖率:所有组织对某一特定CWE进行测试的应用程序的百分比。
  • 加权漏洞:从CVSSv2和CVSSv3分数中分配给CVEs映射到CWEs的Exploit子分数,经过归一化处理,并置于10pt刻度上。
  • 加权影响:从 CVSSv2 和 CVSSv3 分数中分配给 CVEs 映射到 CWEs 的影响子分数,经归一化处理,并置于 10pt 的刻度上。
  • 总发生率:发现具有映射到某一类别的CWEs的应用程序总数。
  • CVEs总数:NVD数据库中与映射到某一类别的CWEs相匹配的CVEs总数。

2017年以来的类别关系

有很多人在谈论十大风险之间的重叠问题。根据每个人的定义(包括CWEs的清单),确实没有任何重叠。然而,从概念上讲,基于更高层次的命名,可能会有重叠或相互影响。维恩图很多时候是用来显示这样的重叠的。

图片[3]-Owasp Top2021中文版-FancyPig's blog

上面的维恩图代表了2017年十大风险类别之间的相互作用。在这样做的时候,有几个基本点变得很明显。

可以说,跨站脚本最终属于注入,因为它本质上是内容注入。看看2021年的数据,XSS需要移入注入,这一点变得更加明显。

重叠只是在一个方向上。我们通常会根据最终表现或 “症状 “对漏洞进行分类,而不是根据(潜在的深层)根本原因。例如,”敏感数据暴露 “可能是 “安全错误配置 “的结果;但是,你不会在另一个方向看到它。因此,在交互区画上箭头,以表明它发生的方向。

有时这些图是用A06:2021中的所有东西画的,使用有已知漏洞的组件。虽然这些风险类别中的一些可能是第三方漏洞的根源,但它们一般是以不同的方式和责任来管理的。其他类型一般是代表第一方的风险。

© 版权声明
THE END
喜欢就支持一下吧
点赞26 分享
评论 抢沙发

请登录后发表评论