OWASP Top10 -2021

image-20211115122522511

什么是OWASP？

OWASP，开放式Web应用程序安全项目（OWASP，Open Web Application Security Project）是一个非营利组织，不附属于任何企业或财团，它提供有关计算机和互联网应用程序的公正、实际、有成本效益的信息。其目的是协助个人、企业和机构来发现和使用可信赖软件。

OWASP项目最具权威的就是其“十大安全漏洞列表”（OWASPTop 10），OWASP Top 10不是官方文档或标准，而只是一个被广泛采用的意识文档，被用来分类网络安全漏洞的严重程度，目前被许多漏洞奖励平台和企业安全团队评估错误报告。这个列表总结了Web应用程序最可能、最常见、最危险的十大漏洞，可以帮助IT公司和开发团队规范应用程序开发流程和测试流程，提高Web产品的安全性。

2021-TOP 10 一览

image-20211115123626268

  • 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:Insecure Design（2021-不安全设计）是2021 年的一个新类别，重点关注与设计缺陷相关的风险。如果我们真的想作为一个行业“向左移动”，我们需要更多的威胁建模、安全设计模式和原则以及参考架构。不安全的设计不能通过完美的实现来修复，因为根据定义，从来没有创建所需的安全控制来防御特定的攻击。
  • A05:2021-Security Misconfiguration（安全配置错误）从上一版的第 6 位上升；90% 的应用程序都针对某种形式的错误配置进行了测试，平均发生率为 4.5%，超过 208,000 次 CWE 映射到此风险类别。随着更多转向高度可配置的软件，看到这一类别上升也就不足为奇了。
  • 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- Software and Data Integrity Failures（软件和数据完整性故障）是 2021 年的一个新类别，专注于在不验证完整性的情况下做出与软件更新、关键数据和 CI/CD 管道相关的假设。来自常见漏洞和暴露/常见漏洞评分系统 (CVE/CVSS) 数据的最高加权影响之一映射到此类别中的 10 个 CWE。
  • A09:2021-Security Logging and Monitoring Failures（ 安全日志记录和监控失败）之前是A10:2017-Insufficient Logging & Monitoring并从前 10 名社区调查（#3）中添加，从之前的 #10 上升。此类别已扩展为包括更多类型的故障，难以测试，并且在 CVE/CVSS 数据中没有得到很好的体现。但是，此类故障会直接影响可见性、事件警报和取证。
  • A10:2021-Server-Side Request Forgery（服务器端请求伪造-SSRF）添加自 Top 10 社区调查 (#1)。数据显示发生率相对较低，测试覆盖率高于平均水平，并且利用和影响潜力的评级高于平均水平。此类别代表安全社区成员告诉我们这很重要的场景，即使目前数据中没有说明这一点。

我所熟悉的top漏洞

Injection（注入）

简介

image-20211115124036133

注入攻击代指一类攻击，它们通过注入数据到一个网络应用程序以期获得执行，亦或是通过非预期的一个方式来执行恶意数据。这种类别的攻击包括跨站脚本攻击（XSS）、SQL 注入攻击、头部注入攻击、日志注入攻击和全路径暴露。当然限于篇幅，这里只是一个简单的介绍。

定义

OWASP 对注入攻击的定义如下：

类似SQL、OS、LDAP注入攻击等注入攻击会在不可信数据作为命令或请求的一部分被发送到解释程序时发生。攻击者的恶意数据会迷惑解释程序去执行非计划的命令，或访问非授权的数据。

SQL 注入攻击
目前最常见的注入攻击形式是臭名昭著的 SQL 注入攻击。SQL 注入攻击不仅常见，而且致命。我要特别强调，了解这种攻击、实现攻击的条件以及防御攻击需要采取的措施极为重要。

SQL 注入攻击通过将数据注入网络应用程序，然后被用于 SQL 请求来操作。数据通常来自类似网页表单的不可信来源。不过，数据也可能来自包括数据库本身在内的其他来源。程序员通常会信任来自自己数据库的数据，以为它们是非常安全的，却没有意识到，在一种用法中安全，不代表它在所有其他用法中都是安全的。来自数据库在经过证明（比如说，通过验证流程）之前，应该被视为不可信。

如果攻击成功，SQL 注入攻击能够操纵受攻击的 SQL 请求，从而进行非程序员意愿的数据库操作。

应用程序在以下情况下容易受到攻击：
  • 应用程序不会验证、过滤或清理用户提供的数据。
  • 没有上下文感知转义的动态查询或非参数化调用直接在解释器中使用。
  • 在对象关系映射 (ORM) 搜索参数中使用恶意数据来提取额外的敏感记录。
  • 直接使用或连接恶意数据。SQL 或命令包含动态查询、命令或存储过程中的结构和恶意数据。

一些更常见的注入是 SQL、NoSQL、OS 命令、对象关系映射 (ORM)、LDAP 和表达式语言 (EL) 或对象图导航库 (OGNL) 注入。这个概念在所有口译员中都是相同的。源代码审查是检测应用程序是否容易受到注入攻击的最佳方法。强烈建议对所有参数、标头、URL、cookie、JSON、SOAP 和 XML 数据输入进行自动化测试。组织可以在 CI/CD 管道中包含静态 (SAST)、动态 (DAST) 和交互式 (IAST) 应用程序安全测试工具，以在生产部署之前识别引入的注入缺陷。

如何预防

防止注入需要将数据与命令和查询分开：

  • 首选选项是使用安全的 API，它完全避免使用解释器，提供参数化接口，或迁移到对象关系映射工具 (ORM)。
    注意：即使在参数化时，如果 PL/SQL 或 T-SQL 连接查询和数据或使用 EXECUTE IMMEDIATE 或 exec() 执行恶意数据，则存储过程仍然会引入 SQL 注入。
  • 使用正面或“白名单”服务器端输入验证。这不是一个完整的防御，因为许多应用程序需要特殊字符，例如文本区域或移动应用程序的 API。
  • 对于任何残留的动态查询，使用该解释器的特定转义语法转义特殊字符。
    注意：表名、列名等 SQL 结构不能转义，因此用户提供的结构名是危险的。这是报告编写软件中的常见问题。
  • 在查询中使用 LIMIT 和其他 SQL 控件以防止在 SQL 注入的情况下大量披露记录。

Vulnerable and Outdated Components（易受攻击和过时的组件）

简介

image-20211115125430662

这个漏洞顾名思义，就是企业或个人使用易受攻击和过时的组件构建自己的网站，导致攻击者很容易就能查找资料利用这些nday漏洞对你的网站进行攻击。

定义

OWASP 对注入攻击的定义如下：

组件（例如：库、框架和其他软件模块）拥有和应用程序相同的权限。如果应用程序中含有已知漏洞的组件被攻击者利用，可能会造成严重的数据丢失或服务器接管。同时，使用含有已知漏洞的组件的应用程序和API可能会破坏应用程序防御、造成各种攻击并产生严重影响。

如果有以下情况，你的网站可能很脆弱：
  • 如果您不知道您使用的所有组件的版本（客户端和服务器端）。这包括您直接使用的组件以及嵌套的依赖项。
  • 如果软件易受攻击、不受支持或已过期。这包括操作系统、Web/应用程序服务器、数据库管理系统 (DBMS)、应用程序、API 和所有组件、运行时环境和库。
  • 如果您不定期扫描漏洞并订阅与您使用的组件相关的安全公告。
  • 如果您没有以基于风险的方式及时修复或升级底层平台、框架和依赖项。这通常发生在修补是变更控制下的每月或每季度任务的环境中，使组织面临数天或数月不必要地暴露于固定漏洞的风险。
  • 如果软件开发人员不测试更新、升级或修补的库的兼容性。
  • 如果您不保护组件的配置（请参阅 A05:2021-安全配置错误）。

如何预防

应该有一个补丁管理流程来：

  • 删除未使用的依赖项、不必要的功能、组件、文件和文档。
  • 使用版本、OWASP 依赖项检查、retire.js 等工具持续清点客户端和服务器端组件（例如框架、库）及其依赖项的版本。持续监控常见漏洞和暴露 (CVE) 等来源和国家漏洞数据库 (NVD) 以获取组件中的漏洞。使用软件组合分析工具来自动化该过程。订阅与您使用的组件相关的安全漏洞的电子邮件警报。
  • 仅通过安全链接从官方来源获取组件。首选签名包以减少包含修改后的恶意组件的机会（请参阅 A08:2021-软件和数据完整性故障）。
  • 监视未维护或未为旧版本创建安全补丁的库和组件。如果无法打补丁，请考虑部署虚拟补丁来监控、检测或防止发现的问题。

每个组织都必须确保在应用程序或产品组合的生命周期内制定持续的监控、分类和应用更新或配置更改的计划。