OWASP Top 10 2021

---

OWASP Top 10 2021

OWASP Top 10 2021

---

总体来说，2021年新鲜出炉的OWASP Top 10榜单出现了三个新的类别，还有四个类别的名称和范围发生了变化，甚至还对一些类别进行了合并。

A01:失效的访问控制

• 概述

访问控制失效（Broken Access Control）从第五位上升到了第一位。94%的应用程序都经过了某种形式的访问控制失效测试。映射到访问控制失效的34个CWE在应用程序中的出现频率比其他任何类别都要多。其中值得关住的常见CWE有：CWE-200：将敏感信息暴露给未经授权的参与者、CWE-201通过发送的数据暴露敏感信息以及CWE-352：跨站请求伪造。

• 描述

失效的访问控制，也叫越权，指的是在未对通过身份验证的用户，实施恰当的访问控制。攻击者可以利用这一漏洞，访问未经授权的功能或数据。

比如，访问其他用户的账户、查看敏感文件、修改其他用户的数据，更改访问权限等等，都属于失效的访问控制造成的后果。

常见的访问漏洞包括：

1、通过修改 URL、内部应用程序状态或 HTML 页面，或仅使用自定义 API 攻击工具来绕过访问控制检查。

2、允许将主键更改为其他用户的记录，允许查看或编辑其他人的帐户。

3、特权提升。在未登录的情况下充当用户或以用户身份登录时充当管理员。

4、元数据操作，例如重放或篡改 JSON Web 令牌 (JWT) 访问控制令牌，或用于提升权限或滥用 JWT 失效的 cookie 或隐藏字段。

5、CORS 错误配置允许未经授权的 API 访问。

6、强制以未经身份验证的用户身份浏览经过身份验证的页面或以标准用户身份浏览特权页面。访问 API 时缺少对 POST、PUT 和 DELETE 的访问控制。

对于上述提到的问题其实说具体点可以说是文件包含或者目录遍历，由于控制不严使用户可以对网站进行非法操作，得到一些敏感信息和对网站不利的信息（未授权访问）；还有就是权限绕过和提升，例如网站存在漏洞使恶意者得到一个账户就可以对其它平级用户实现操作，或者严重一点的可以借此获得管理员权限；还有就是对不安全直接对象的引用，有时候网站在跨站访问一些资源的时候由于配置错误或者控制不严，使网站暴露在危险之中。

• 防御思路

1、访问控制仅在受信任的服务器代码或无服务器API中有效，攻击者无法修改访问控制检查或元数据。

1 除公共资源外，默认拒绝。
2 实施一次访问控制机制并在整个应用程序中重复使用它们，包括最大限度地减少跨源资源共享 (CORS) 的使用。
3 模型访问控制应该强制记录所有权，而不是接受用户可以创建、读取、更新或删除任何记录。
4 独特的应用程序业务限制要求应由领域模型强制执行。
5 禁用Web服务器目录列表并确保文件元数据（例如 .git）和备份文件不在 Web 根目录中。记录访问控制失败，在适当时提醒管理员（例如，重复失败）。
6 速率限制API和控制器访问，以最大限度地减少自动攻击工具的危害。
7 注销后，服务器上的有状态会话标识符应失效。无状态JWT令牌应该是短暂的，以便最小化攻击者的机会窗口。对于寿命较长的 JWT，强烈建议遵循OAuth标准来撤销访问。

2、做到检查访问——对每一个来自于不信任的源的直接对象引用都必须包含访问控制检查， 从而确信该用户对该对象拥有访问权。

3、如果这个URL不是公开的， 那么必须限制能够访问他的授权用户。

4、完全禁止访问未被授权的页面类型（ 如配置文件、日志文件、源文件等）。

A02: 加密失败

• 概述

加密失败（Cryptographic Failure）——此前名为“敏感数据暴露”（Sensitive Data Exposure），这一名称只是描述了广泛的症状而非根本原因——上移到了榜单第二位。此处需要重新关注与密码学相关的故障，这些故障通常会导致敏感数据暴露或系统受损。从文章的解释中我理解为主要是采用的相关加密算法是不安全的，因为使用了这些不安全的加密算法,使被加密的数据有被破解的风险，从而导致相关敏感数据的泄露。

• 描述

对于需要加密或加密传输的数据，常见的漏洞情况包括：

1 数据采用明文形式传输，这涉及 HTTP、SMTP、FTP 等协议也使用 TLS 升级，如 STARTTLS。外部互联网流量是危险的。
2 验证所有内部流量，例如，负载平衡器、Web 服务器或后端系统之间的流量。
3 默认情况下或在较旧的代码中是否使用任何旧的或弱的加密算法或协议。
4 使用默认加密密钥、生成或重复使用弱加密密钥，或者缺少适当的密钥管理或轮换。加密密钥是否已签入源代码存储库？
5 是否未强制执行加密，例如，是否缺少任何 HTTP 标头（浏览器）安全指令或标头？
6 收到的服务器证书和信任链是否经过正确验证？
7 初始化向量是否被忽略、重用或生成的加密操作模式不够安全。是否使用了不安全的操作模式，当认证加密更合适时是否使用加密。
8 在没有密码基密钥派生函数的情况下，是否将密码用作加密密钥。
9 随机性是否用于并非旨在满足加密要求的加密目的。即使选择了正确的函数，它是否需要由开发人员播种，如果不需要，开发人员是否用缺乏足够熵/不可预测性的种子覆盖了内置的强大播种功能。
10 是否使用过时的哈希函数，例如 MD5 或 SHA1，或者在需要加密哈希函数时使用非加密哈希函数。
11 是否在使用已弃用的加密填充方法，例如 PCKS number 1 v1.5。
12 加密错误消息或边信道信息是否可利用，例如以填充预言机攻击的形式。

• 防御思路

1 对应用程序处理、存储或传输的数据进行分类。根据隐私法、监管要求或业务需求确定哪些数据是敏感的。
2 不要不必要地存储敏感数据。尽快丢弃它或使用符合 PCI DSS 的标记化甚至截断。未保留的数据不能被窃取。
3 确保加密所有静态敏感数据。
4 确保拥有最新且强大的标准算法、协议和密钥；使用适当的密钥管理。
5 使用安全协议（例如具有前向保密 (FS) 密码的 TLS、服务器的密码优先级和安全参数）加密所有传输中的数据。使用 HTTP 严格传输安全 (HSTS) 等指令强制加密。
6 对包含敏感数据的响应禁用缓存。
7 根据数据分类应用所需的安全控制。
8 不要使用旧协议（例如 FTP 和 SMTP）来传输敏感数据。
9 使用具有工作因子（延迟因子）的强自适应和加盐散列函数存储密码，例如 Argon2、scrypt、bcrypt 或 PBKDF2。
10 必须选择适合操作模式的初始化向量。对于许多模式，这意味着使用 CSPRNG（密码安全伪随机数生成器）。对于需要随机数的模式，则初始化向量 (IV) 不需要 CSPRNG。在所有情况下，对于一个固定密钥，IV 永远不应该被使用两次。
11 始终使用经过身份验证的加密，而不仅仅是加密。
12 密钥应该以加密方式随机生成并作为字节数组存储在内存中。如果使用密码，则必须通过适当的密码基密钥派生函数将其转换为密钥。
13 确保在适当的地方使用加密随机性，并且它没有以可预测的方式或低熵进行播种。大多数现代 API 不需要开发人员为 CSPRNG 设置种子以获得安全性。
14 避免不推荐使用的加密函数和填充方案，例如 MD5、SHA1、PKCS number 1 v1.5。
15 独立验证配置和设置的有效性。

A03:注入

• 概述

随着大量主流框架被使用，发生注入攻击的概率也随之下降，“注入”也从2017年的第一位下降到第三位。
94% 的应用程序针对某种形式的注射进行了测试，最大发生率为 19%，平均发生率为 3%，注入类别中如今包括跨站脚本。映射到该类别的33个CWE在应用程序中出现次数第二多。

SQL注入是典型的注入攻击，攻击者可以在web应用程序中事先定义好的查询语句的结尾，添加额外的SQL语句，从而实现非法操作。

• 描述

关于注入：当用户发送不可信地数据到解释器的时候，就可能出现注入漏洞，比如SQL, NoSQL, LDAP注入，解释器可能会将用户发送的恶意数据视为指令或数据库查询，使得用户在没有权限的情况下访问数据，甚至导致用户完全控制服务器。

常见的漏洞包括：

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

源代码审查是检测应用程序是否容易受到注入攻击的最佳方法。强烈建议对所有参数、标头、URL、cookie、JSON、SOAP 和 XML 数据输入进行自动化测试。组织可以将静态源 (SAST) 和动态应用程序测试 (DAST) 工具包含到 CI/CD 管道中，以在生产部署之前识别引入的注入缺陷。

• 防御思路

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

补充：一个强大的防御waf也是不错的选择，可以相对有效的避免。

A04:不安全设计

• 概述

不安全设计（Insecure Design）是2021年出现的新类别，并且一出场就高居第四位。它重点关注的是设计缺陷相关的风险，“不安全设计”代表的是一类漏洞。同时呼吁更多地使用威胁建模、安全设计模式和原则以及参考架构。

• 描述

不安全设计是一个广泛的类别，代表许多不同的弱点，表现为“缺失或无效的控制设计”。缺少不安全的设计是缺少控制的地方。例如，想象一下应该加密敏感数据的代码，但没有方法。无效的不安全设计是可以实现威胁的地方，但域（业务）逻辑验证不足会阻止该操作。

收集并与企业协商应用程序的业务需求，包括有关所有数据资产的机密性、完整性、可用性和真实性以及预期业务逻辑的保护要求。考虑您的应用程序的公开程度以及您是否需要隔离租户（除了访问控制之外）。编译技术要求，包括功能性和非功能性安全要求。规划和协商涵盖所有设计、构建、测试和运营（包括安全活动）的预算。安全设计是一种文化和方法，它不断评估威胁并确保代码经过稳健设计和测试，以防止已知的攻击方法。安全设计需要安全的开发生命周期、某种形式的安全设计模式或铺砌道路组件库或工具，以及威胁建模。

我们所熟悉的应用程序未容错也是属于这种，以一个登录界面为例，如果登录的时候涉及到内容的加密和解密。那么登录时用非常规手段传了一串非法的字符串进行登录。在解密的时候可能会出现一些异常，如索引越界，这样就会把异常的英文内容直接提示给页面了。应该在编写代码的时候在登录接口中处理异常的时候，要根据不同的异常进行处理。业务的异常，如密码错误，账户冻结等，就按业务异常提示。其他意外的错误，则统一给提示语，屏蔽掉异常的英文内容，防止通过攻击者构造不同的异常处理方法。

• 防御思路

1 与 AppSec 专业人员建立并使用安全的开发生命周期，以帮助评估和设计与安全和隐私相关的控制 
2 建立和使用安全设计模式库或准备使用组件的铺好的道路 
3 将威胁建模用于关键身份验证、访问控制、业务逻辑和关键流 
4 将安全语言和控件集成到用户故事中 
5 在应用程序的每一层（从前端到后端）集成合理性检查 
6 编写单元和集成测试以验证所有关键流都能抵抗威胁模型。为应用程序的每一层编译用例和误用用例。
7 根据暴露和保护需求分离系统层和网络层上的层 
8 通过设计在所有层中强有力地隔离租户 
9 限制用户或服务的资源消耗

A05:安全配置错误

• 概述

安全配置错误（Security Misconfiguration）从上一版的第6位上升到了第5位。90%的应用程序都经过了某种形式的错误配置测试，随着转向高度可配置软件的趋势不可逆，看到这一类别排名上升也就不足为奇了。此前版本的XML外部实体注入（XXE）类别现在也被合并为该类别的一部分。值得注意的 CWE 包括 CWE-16 配置和 CWE-611 XML 外部实体引用的不当限制。

• 描述

安全配置错误可以发生在一个应用程序堆栈的任何层面，包括网络服务、平台、Web服务器、应用服务器、数据库、框架、自定义代码和预安装的虚拟机、容器和存储。自动扫描器可用于检测错误的安全配置、默认帐户的使用或配置、不必要的服务、遗留选项等。

常见的漏洞：

1 应用程序栈堆的任何部分都缺少适当的安全加固，或者云服务的权限配置错误。
2 应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、帐户或权限）。
3 默认帐户的密码仍然可用且没有更改。
4 错误处理机制向用户披露堆栈跟踪或其他大量错误信息。
5 对于更新的系统，禁用或不安全地配置最新的安全功能。
6 应用程序服务器、应用程序框架（如：Struts、Spring、ASP.NET）、库文件、数据库等没有进行安全配置。
7 服务器不发送安全标头或指令，或者未对服务器进行安全配置。
8 应用软件已过期或易受攻击（参见A09：2017-使用含有已知漏洞的组件、 A06:2021-易受攻击和过时的组件）。

• 防御思路

1 一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且，在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的耗费。
2 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。
3 检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分，（参见A9：2017-使用含有已知漏洞的组件）。在检查过程中，应特别注意云存储权限（如：S3桶权限）。
4 一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括：分段、容器化和云安全组。
5 向客户端发送安全指令，如：安全标头。
6 在所有环境中能够进行正确安全配置和设置的自动化过程。

A06:易受攻击和过时的组件

• 概述
  易受攻击和过时的组件（Vulnerable and Outdated Component）——此前名为“使用具有已知漏洞的组件”（Using Components with Known Vulnerabilities）该类别是唯一一个没有任何CVE映射到所含CWE的类别，因此默认的漏洞与影响权重计5.0分。

• 描述

常见的漏洞有：

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

比如我们的产品经常出现的产品版本问题等类似的问题，旧的版本或者组件就有可能攻破，是网站或者受到损失。

• 防御思路

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

A07:识别与认证失败

• 概述
• 描述
• 防御思路

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

• 概述
• 描述
• 防御思路

A09:安全日志与监测失败

• 概述
• 描述
• 防御思路

A10：服务器端请求伪造

• 概述
• 描述
• 防御思路