OWASP Top 10:2021_owasp_2017_a06

目录

OWASP Top 10 For 2021

A01:2021-Broken Access Control（访问控制失效）

A02:2021 – Cryptographic Failures（加密失败）

A03:2021 – Injection（注入）

A04:2021 – Insecure Design（不安全设计）

A05:2021 – Security Misconfiguration（ 安全错误配置 ）

A06:2021 – Vulnerable and Outdated Components（易受攻击和已淘汰的组件）

A07:2021 – Identification and Authentication Failures（失效的身份认证）

A08:2021 – Software and Data Integrity Failures（软件和数据完整性故障）

A09:2021 – Security Logging and Monitoring Failures（安全记录和监控失效）

A10:2021 – Server-Side Request Forgery (服务器请求伪造 SSRF)

介绍

最近在找工作，看到好多招聘要求熟悉OWASP Top 10，在网上找相关博客进行学习时，发现大部分博主的相关博客都是基于OWASP Top 10:2017写的，而目前OWASP Top 10已经更新到2021版本。打算写一个博客翻译学习一下官方版本的OWASP Top 10 For 2021，同时希望可以为有相同需求的小伙伴提供帮助，也希望大家可以指出文章中的错误翻译或其他问题，共同学习。

OWASP Top 10 For 2021

与OWASP Top 10:2017相比较，OWASP Top 10:2021有三个全新的分类，有四个分类有做名称和范围的修正，并将一些类别进行合并。

图片来源：OWASP Top 10:2021

A01:2021-Broken Access Control（访问控制失效）

描述

访问控制可以限制用户使其无法在其权限之外执行操作。访问控制失效通常会导致未经授权的信息泄露、修改、数据销毁、在用户权限之外执行业务功能等。常见的访问控制脆弱点包括：

• 违反了最小特权原则或默认拒绝原则，即部分本应该只授予给特定的功能、角色或用户的访问权限却授予给了所有用户。

• 通过修改URL(参数篡改或强制浏览)、内部应用程序状态或HTML页面，或使用攻击工具修改API请求来绕过访问控制检查。

• 通过修改唯一 ID (主键)，允许查看或编辑他人的帐户。

• 访问API时缺少对POST, PUT和DELETE请求的访问控制。

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

• 元数据操作，例如重放或篡改JSON Web Token (JWT)访问控制令牌，或操纵cookie或隐藏字段以提高特权或滥用JWT的无效处理。

• CORS错误配置允许从未经授权/不受信任的来源访问API；。

• 强制以非认证用户的身份浏览认证页面，或以标准用户的身份浏览特权页面。

如何预防

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

• 除公有资源外，默认情况下拒绝访问。

• 只执行一次访问控制机制，并在整个应用程序中不断重复使用它们，尽量减少跨域资源共享(CORS)的使用。

• 模型访问控制应该强制执行记录所有权，而不是允许用户创建、读取、更新或删除的任何记录。

• 独特的应用业务限制要求应该由域模型强制执行。

• 禁用 Web服务器目录列表，并确保文件元数据 (如: git) 和备份文件不存在于 Web的根目录中；

• 记录失败的访问控制，并在适当时向管理员告警 (如: 重复故障) 。

• 对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具的危害。

• 有状态的会话ID应在注销后在服务器上失效。无状态的JWT令牌应该是短暂的，以便将攻击者的机会窗口降到最低。对于寿命较长的JWTs，强烈建议遵循OAuth标准来撤销访问。

开发人员和 QA 人员应进行功能访问控制单元和集成测试。

A02:2021 – Cryptographic Failures（加密失败）

描述

首先需要确认的是哪些数据是敏感数据（包含：传输过程中的数据、存储数据）而需要被加密。例如：密码、信用卡卡号、医疗记录、个人信息和商业机密等，特别是隐私法律或条例中规定需要加密的数据，如：欧盟《通用数据保护条例》（GDPR）、 属于“金融数据保护条例”的《支付卡行业数据安全标准》（PICDSS）。对于这些数据，要确定：

• 是否有任何数据以明文形式传输？这和传输协议相关，如：HTTP、SMTP和FTP。外部互联网流量是危险的。验证所有内部通信，例如负载平衡器、Web 服务器或后端系统之间的通信。

• 是否有任何旧的或弱的加密算法或协议被默认使用或在旧的代码中使用？

• 是否在使用默认的加密密钥、生成或重复使用脆弱的加密密钥，或者缺少适当的密钥管理或轮换？加密密钥是否被检查到源代码库中？

• 是否强制执行加密，例如，是否缺少任何HTTP头（浏览器）安全指令或头？

• 收到的服务器证书和信任链是否得到正确验证？

• 初始化向量是否被忽略、重用，或生成的加密操作模式不够安全？是否在使用如ECB之类的不安全的操作模式？在认证加密更合适的情况下，是否使用了加密？

• 在没有密码基密钥派生功能的情况下，是否使用密码作为加密密钥？

• 是否为加密目标使用了并非为满足加密要求而设计的随机性？即使选择了正确的函数，它是否需要由开发人员进行播种？如果不需要，开发人员是否用缺乏足够熵/不可预测性的种子对其内置的强播种功能进行了改写？

• 是否在使用被废弃的哈希函数，如MD5或SHA1，或者在需要加密哈希函数时使用了非加密哈希函数？

• 是否在使用已废弃的加密填充方法，如PKCS number 1 v1.5？

• 加密错误消息或边信道信息是否可被利用，例如以填充预言攻击的形式？

如何预防

至少执行以下操作，并查阅参考资料：

• 对应用程序处理、存储或传输的数据进行分类。根据隐私法、监管要求或业务需求确定哪些数据是敏感数据。

• 非必要不存储敏感性资料。尽快丢弃它或使用符合 PCIDSS 的资料记号化 (tokenization) 甚至截断 (truncation) 。没有保存的数据是不会被窃取的。

• 确保对所有静态敏感数据进行加密。

• 确保采用最新的、强大的标准算法、协议和密钥；使用适当的密钥管理。

• 使用安全协议加密传输中的所有数据，例如具有前向保密 (FS) 密码、 服务器的密码优先级和安全参数的 TLS。使用 HTTP 严格传输安全 (HSTS) 等指令强制加密。

• 对包含敏感数据的响应禁用缓存。

• 根据数据分类应用所需的安全控制。

• 不要使用 FTP 和 SMTP 等传统协议来传输敏感数据。

• 使用具有工作因素（延迟因素）的强自适应和加盐哈希函数存储密码，例如 Argon2、scrypt、bcrypt 或 PBKDF2。

• 必须选择适合操作模式的初始化向量。对于许多模式，这意味着使用 CSPRNG（加密安全伪随机数生成器）。对于需要随机数的模式，初始化向量 (IV) 不需要 CSPRNG。在所有情况下，IV 都不应该对一个固定密钥是使用两次。

• 始终使用经过身份验证的加密，而不仅仅是加密。

• 密钥应该以加密方式随机生成并作为字节数组存储在内存中。如果使用密码，则必须通过适当的密码基密钥派生函数将其转换为密钥。

• 确保在适当的情况下使用加密随机性，并确保没有以可预测的方式或以低熵的方式播种。大多数现代 API 不需要开发人员播种 CSPRNG 来获得安全性。

• 避免使用已废弃的加密函数和填充方案，例如 MD5、SHA1、PKCS number 1 v1.5。

• 独立验证配置和设置的有效性。

A03:2021 – Injection（注入）

描述

在以下情况下，应用程序容易受到攻击：

• 应用程序不会验证、过滤或清理用户提供的数据。

• 在解释器中直接使用动态查询或没有上下文感知转义的非参数化调用。

• 在对象关系映射 (ORM) 搜索参数中使用恶意数据来提取额外的敏感记录。

• 直接使用或连接恶意数据。SQL 或命令包含动态查询、命令或存储过程中的结构和恶意数据。

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

如何预防

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

• 首选选项是使用安全 API，它完全避免了解释器的使用，提供参数化接口，或迁移到对象关系映射工具 (ORM)。 注意：即使在参数化的情况下，如果 PL/SQL 或 T-SQL 连接查询和数据或使用 EXECUTE IMMEDIATE 或 exec() 执行恶意数据，存储过程仍然可能引入 SQL 注入。

• 使用积极的服务器端输入验证（白名单）。这不是一个完整的防御措施，因为许多应用程序需要特殊字符，例如用于移动应用程序的文本区域或 API。

• 对于任何残留的动态查询，使用该解释器的特定转义语法转义特殊字符。 注意： 在SQL 结构中，如表名、列名等不能被转义，因此用户提供的结构名是危险的。这是一个在编写软件时的常见问题。

• 在查询中使用 LIMIT 和其他 SQL 控件，以防止在遭受 SQL 注入攻击的情况下大量泄露记录。

A04:2021 – Insecure Design（不安全设计）

描述

不安全设计是一个广泛的类别，代表不同的弱点，表示为“缺少或无效的控制设计”。不安全的设计并不是所有其他 10 大风险类别的来源。不安全的设计和不安全的实现是有区别的。我们区分设计缺陷和实现缺陷是因为它们有不同的根本原因和补救措施。一个安全设计仍然可能存在导致可能被利用的漏洞的实现缺陷。一个不安全的设计无法通过完美的实现来解决，因为根据定义，所需要的安全控制从未被创造出来以防御特定的攻击。导致不安全设计的因素之一是正在开发的软件或系统中缺乏固有的业务风险分析，因此无法确定需要什么样的安全设计水平。

需求和资源管理

收集并协商应用程序的业务需求，包括有关所有数据资产的机密性、完整性、可用性和真实性以及预期业务逻辑的保护要求。兼顾应用程序的暴露程度以及是否需要对用户进行隔离（除了访问控制）。编制技术要求，包括功能和非功能安全要求。规划和协商涵盖所有设计、构建、测试和运营的预算，包括安全活动。

安全设计

安全设计是一种不断评估威胁并确保代码经过稳健设计和测试以防止已知攻击方法的文化和方法。威胁建模应整合到改进会议（或类似活动）中；寻找数据流和访问控制或其他安全控制的变化。在用户故事开发中确定正确的流程和故障状态，确保它们被负责和受影响的各方充分理解和同意。分析预期和失败流的假设和条件，确保它们仍然准确理想。确定如何验证假设并强制执行适当行为所需的条件。确保结果记录在用户故事中。从错误中吸取教训并提供积极的激励措施来促进改进。

安全开发生命周期

安全软件需要安全的开发生命周期、某种形式的安全设计模式、铺平道路方法、安全组件库、工具和威胁建模。在整个项目和软件维护过程中，在软件项目开始时就联系安全专家。考虑利用OWASP 软件保障成熟度模型 (SAMM)来帮助构建安全软件开发工作。

如何预防

• 与 AppSec 专业人员一起建立和使用安全的开发生命周期，以帮助评估和设计安全和隐私相关的控制措施；

• 建立和使用安全设计模式库或铺设好的可使用的组件。

• 将威胁建模用于关键身份验证、访问控制、业务逻辑和关键流程。

• 将安全语言和控制集成到用户故事中。

• 在应用程序的每个层级（从前端到后端）整合可信度检查。

• 编写单元和集成测试，以验证所有关键流程对威胁模型的抵抗力。为应用程序的每一层编制使用案例和错误使用案例。

• 根据暴露和保护需求在系统层和网络层上隔离层级。

• 通过设计在所有层级中可靠地隔离用户。

• 限制用户或服务的资源消耗。

A05:2021 – Security Misconfiguration（ 安全错误配置 ）

描述

如果应用程序存在以下情况，则该应用程序可能存在漏洞：

• 在应用程序堆栈的任何部分缺少适当的安全强化，或对云服务权限配置不当。

• 启用或安装了不必要的功能（例如，不必要的端口、服务、页面、帐户或权限）。

• 默认帐户及其密码仍处于启用状态且未更改。

• 错误处理向用户显示堆栈跟踪或其他信息过多的错误消息。

• 对于升级后的系统，最新的安全功能被禁用或未安全配置。

• 应用程序服务器、应用程序框架（例如，Struts、Spring、ASP.NET）、库、数据库等中的安全设置未设置为安全值。

• 服务器没有发送安全报头或指令，或者它们没有被设置为安全值。

• 该软件已过时或易受攻击（请参阅A06:2021-Vulnerable and Outdated Components）。

如果没有协调一致的、可重复的应用程序安全配置过程，系统就会面临更高的风险。

如何预防

应实施安全安装流程，包括：

• 一个可重复的安全强化流程，必需可以快速且简单的布署，而且能在分隔且封锁的环境下执行。 开发，品质管理，以及实际营运的环境，都须有一致相同的配置，并且使用不同的认证资讯。 这种步骤需要尽可能的自动化，以尽量减少建立一个新的安全环境所需的投入。

• 一个最精简的平台，没有任何不必要的功能、组件、文档和示例。删除或不安装所有不须使用的功能和框架。

• 在变更管理下，需有特定的任务，依据安全通知，相关更新，来执行安全审视及更动(可参照A06:2021-易受攻击和过时的组件](A06 Vulnerable and Outdated Components - OWASP Top 10:2021) )。 审视云端储存的权限(例如 S3 bucket的权限) 。

• 一个分段的应用程序体系结构，对于各元件，用户，可通过分段，容器化，云端安全群组设定(ACLs)，来达到有效且安全的分割效果。

• 向客户端发送安全指令，例如安全报头。

• 一个自动化的流程，可以确认环境中各类安全设定。

A06:2021 – Vulnerable and Outdated Components（易受攻击和已淘汰的组件）

描述

您可能易受攻击：

• 如果您不知道您使用的所有组件的版本（客户端和服务器端）。这包括您直接使用的组件以及嵌套的依赖项。

• 如果软件易受攻击、已不受支持或已过期。这包括操作系统、Web/应用程序服务器、数据库管理系统 (DBMS)、应用程序、API 和所有组件、运行环境和库。

• 如果您没有定期扫描漏洞并订阅与您使用的组件相关的安全公告。

• 如果您不以基于风险的方式及时修复或升级底层平台、框架和依赖项。这通常发生在修补工作是变更控制的每月或每季度任务的环境中，这会使组织数天甚至数月不必要地暴露于已修复的漏洞风险中。

• 如果软件开发人员不测试更新、升级或修补库的兼容性。

• 如果您不保护组件的配置档案（请参阅 A05:2021-Security Misconfiguration）。

如何预防

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

• 删除不使用的依赖项、不必要的功能、组件、文件和文档。

• 使用 versions、OWASP 依赖检查、retire.js 等工具持续清点客户端和服务器端组件（例如框架、库）及其依赖项的版本。持续监控CVE和NVD 等来源来确认组件是否存在的漏洞。 使用软件组成分析工具来自动化该过程。订阅与您使用的组件相关的安全漏洞的安全通报。

• 仅通过安全链接从官方来源获取组件。优先选择已签名的软件包以减少包含修改过的恶意组件的机会（请参阅 A08:2021-软件和数据完整性故障）。

• 监控未维护或没有为旧版本创建安全补丁的库和组件。如果无法进行修补，请考虑部署虚拟补丁来监控、检测或防御已发现的问题。

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

A07:2021 – Identification and Authentication Failures（失效的身份认证）

描述

确认用户的身份、身份验证和会话管理对于防止与身份验证相关的攻击至关重要。如果应用程序存在以下情况，则有可能有认证漏洞：

• 允许像是攻击者已经拥有有效用户名称和密码列表的撞库自动化攻击 。

• 允许暴力破解或其他自动攻击。

• 允许使用默认密码、弱密码或众所周知的密码，例如“Password1”或“admin/admin”。

• 使用弱的或失效的验证凭证，忘记密码程序，如不安全的"知识相关问答"。

• 使用明文、加密或弱散列密码（请参阅 A02:2021-Cryptographic Failures）。

• 缺少或无效的多因素身份验证。

• 在 URL 中泄露会话ID（例如URL重写）。

• 成功登录后重用会话ID/没有轮换会话ID。

• 不能正确地注销会话 ID 。用户会话或身份验证令牌（主要是单点登录 (SSO) 令牌）在注销或 一段时间没活动后未正确失效。

如何预防

• 在可能的情况下，实现多因素身份验证，以防止自动、凭证填充、暴力破解和被盗凭据再利用攻击。

• 不发布或部署任何默认凭证，尤其是管理员用户。

• 实施弱密码检查，例如测试新或变更的密码，以纠正“排名前10000个弱密码” 列表。

• 将密码长度、复杂性和轮换策略与NIST-800-63 B的指导方针的5.1.1章节-记住秘密，或其他现代的基于证据的密码策略相一致。

• 对所有结果使用相同的讯息回应 ，确保注册、凭证恢复和 API 路径能够抵御帐户枚举攻击。

• 限制或逐渐延迟失败的登录尝试，但请注意不要造成拒绝服务场景。当检测到凭证填充、暴力破解或其他攻击时，记录所有故障并提醒管理员。

• 使用服务器端安全、内置的会话管理器，在登录后生成具有高复杂度的新随机会话 ID。会话ID不应在 出现在URL 中，应安全存储，并在注销、空闲、绝对超时后失效。

A08:2021 – Software and Data Integrity Failures（软件和数据完整性故障）

描述

软件和数据完整性故障与代码和基础架构有关。例如，如果对象或数据被编码或序列化为攻击者可以看到和修改的结构，就容易导致不安全的反序列化。另一种形式是应用程序依赖来自不受信任的来源、存储库和内容交付网络（CDN）的插件、库或模块。一个不安全的CI/CD管道可能会带来未经授权的访问、恶意代码或系统破坏的可能性。最后，现在许多应用程序都包含自动更新功能，但自动更新功能在没有足够完整性验证的情况下下载更新并应用于以前受信任的应用程序。攻击者可能会上传他们自己的更新以传播到所有已安装的应用程序并在这些应用程序上执行。

如何预防

• 使用数字签名或类似机制来验证软件或数据是否来自预期来源并且未被更改。

• 确保库和依赖关系，例如 npm 或 Maven，正在使用受信任的存储库。如果您的风险较高，请考虑托管经过审查的已知内部良好的存储库。

• 确保使用软件供应链安全工具（例如 OWASP Dependency Check 或 OWASP CycloneDX）来验证组件不包含已知漏洞。

• 确保对代码和配置的更改进行审查，以最大程度地减少将恶意代码或配置引入您的软件管道的可能性。

• 确保您的 CI/CD 管道具有适当的隔离、配置和访问控制，以确保流经构建和部署过程的代码的完整性。

• 确保未签名或未加密的序列化数据在没有某种形式的完整性检查或数字签名的情况下不会发送到不受信任的客户端，以检测序列化数据的篡改或重放

A09:2021 – Security Logging and Monitoring Failures（安全记录和监控失效）

描述

此类别旨在帮助检测、升级和响应主动入侵行为。如果没有日志记录和监控，就无法检测到违规行为。任何时候都会出现日志记录、检测、监控和主动响应不足的情况：

• 未记录可审计性事件，如：登录、登录失败和高额交易。

• 警告和错误事件未能产生或产生不足的和不清晰的日志信息。

• 没有利用应用系统和API的日志信息来监控可疑活动。

• 日志信息仅在本地存储。

• 没有定义合理的告警阈值和制定响应处理流程。

• 渗透测试和使用DAST工具（如：OWASP ZAP）扫描没有触发警告。

• 对于实时或准实时的攻击，应用程序无法检测、处理和警告。

如果你的应用使得日志信息或告警信息对用户或者攻击者可见，你就很容易遭受信息泄露攻击。

如何预防

根据应用程序存储或处理的数据的风险：

• 确保所有登录、访问控制失败、输入验证失败能够被记录到日志中去，并保留足够的用户上下文信息，以识别可疑或恶意帐户，并为后期取证预留足够时间。

• 确保日志以一种能被集中日志管理解决方案使用的形式生成 。

• 确保日志数据被正确编码，以防止对日志或监控系统的注入或攻击。

• 确保高额交易有完整性控制的审计信息，以防止篡改或删除，例如审计信息保存在只能进行记录增加的数据库表中。

• 建立有效的监控和告警机制，使可疑活动在可接受的时间内被发现和应对。

• 建立或采用事件响应和恢复计划，如NIST 800-61r2或更高版本。

有一些商业和开源的应用程序保护框架，如OWASP ModSecurity核心规则集，以及开源的日志关联软件，如Elasticsearch、Logstash、Kibana（ELK）堆栈，具有自定义仪表盘和警报功能。

A10:2021 – Server-Side Request Forgery (服务器请求伪造 SSRF)

描述

每当 Web 应用程序在未验证用户提供的 URL 的情况下获取远程资源时，就会出现 SSRF 缺陷。它允许攻击者强制应用程序将精心制作的请求发送到意想不到的目的地，即使是在有防火墙、VPN 或其他类型的网络访问控制列表 (ACL) 保护的情况下。

现代 Web 应用程序为终端用户提供了方便的功能，获取 URL 成为一种常见的场景。因此，SSRF的发生率正在增加。此外，由于云服务和架构的复杂性，SSRF 的严重性变得越来越高。

如何预防

开发人员可以通过实施以下部分或全部深度防御控制来防止 SSRF：

从网络层：

• 在独立的网络中划分远程资源访问功能以减少 SSRF 的影响。

• 强制执行“默认拒绝”防火墙策略或网络访问控制规则，以阻止除基本 Intranet 流量之外的所有流量。 提示： ~ 为基于应用程序的防火墙规则建立所有权和生命周期。 ~ 在防火墙上记录所有接受和阻止的网络流（请参阅A09:2021-安全记录和监控失效）。

从应用层：

• 清理和验证所有客户端提供的输入数据。

• 用一个积极的允许列表强制执行URL模式、端口和目的地。

• 不要向客户发送原始响应。

• 禁用 HTTP 重定向。

• 注意 URL 一致性以避免诸如 DNS 重新绑定和“检查时间、使用时间”(TOCTOU) 竞争条件等攻击。

不要通过使用拒绝列表或正则表达式来缓解 SSRF。攻击者拥有绕过拒绝列表的有效负载列表、工具和技能。

需要考虑的其他措施：

• 不要在前端系统（例如 OpenID）上部署其他安全相关服务。控制这些系统上的本地流量（例如 localhost）。

• 对于具有专用和可管理用户组的前端，在独立系统上使用网络加密（例如 VPN）来考虑非常高的保护需求。