2021 OWASP Top 10 Web Application Security Risks （1）

A02 Cryptographic Failures – OWASP Top 10:2021

The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.

Globally recognized by developers as the first step towards more secure coding.

Companies should adopt this document and start the process of ensuring that their web applications minimize these risks. Using the OWASP Top 10 is perhaps the most effective first step towards changing the software development culture within your organization into one that produces more secure code.
 

Top 10 Web Application Security Risks

There are three new categories, four categories with naming and scoping changes, and some consolidation in the Top 10 for 2021.

• A01:2021-Broken Access Control 失效的访问控制 moves up from the fifth position; 94% of applications were tested for some form of broken access control. The 34 Common Weakness Enumerations (CWEs) mapped to Broken Access Control had more occurrences in applications than any other category.
• A02:2021-Cryptographic Failures 加密失败，以前叫敏感数据泄露  shifts up one position to #2, previously known as Sensitive Data Exposure, which was broad symptom rather than a root cause. The renewed focus here is on failures related to cryptography which often leads to sensitive data exposure or system compromise.
• A03:2021-Injection 注入 slides down to the third position. 94% of the applications were tested for some form of injection, and the 33 CWEs mapped into this category have the second most occurrences in applications. Cross-site Scripting is now part of this category in this edition. 在这个版本中，XSS也属于这个分类
• A04:2021-Insecure Design 不安全的设计 is a new category for 2021, with a focus on risks related to design flaws. If we genuinely want to “move left” as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures.
• 不安全设计是 2021 年的新类别，重点关注与设计缺陷相关的风险。如果我们真的想作为一个行业“左移”，就需要更多地使用威胁建模、安全设计模式和原则以及参考架构。
• A05:2021-Security Misconfiguration 安全的错误配置 moves up from #6 in the previous edition; 90% of applications were tested for some form of misconfiguration. With more shifts into highly configurable software, it’s not surprising to see this category move up. The former category for XML External Entities (XXE) is now part of this category.  2017版本的XXE现在属于这个分类。
• A06:2021-Vulnerable and Outdated Components 脆弱过时的组件was previously titled Using Components with Known Vulnerabilities and is #2 in the Top 10 community survey, but also had enough data to make the Top 10 via data analysis. This category moves up from #9 in 2017 and is a known issue that we struggle to test and assess risk. It is the only category not to have any Common Vulnerability and Exposures (CVEs) mapped to the included CWEs, so a default exploit and impact weights of 5.0 are factored into their scores.
• A07:2021-Identification and Authentication Failures 识别和身份认证失败 was previously Broken Authentication and is sliding down from the second position, and now includes CWEs that are more related to identification failures. This category is still an integral part of the Top 10, but the increased availability of standardized frameworks seems to be helping.
• 标识和身份验证失败以前是“身份验证中断”，并且从第二个位置下滑，现在包括与标识失败更相关的 CWE。这个类别仍然是前 10 名中不可或缺的一部分，但标准化框架可用性的增加似乎有所帮助。
• A08:2021-Software and Data Integrity Failures 软件和数据完整性失效 is a new category for 2021, focusing on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. One of the highest weighted impacts from Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) data mapped to the 10 CWEs in this category. Insecure Deserialization from 2017 is now a part of this larger category.
• 2021-软件和数据完整性故障是 2021 年的新类别，侧重于在不验证完整性的情况下做出与软件更新、关键数据和 CI/CD 管道相关的假设。映射到此类别中 10 个 CWE 的常见漏洞和暴露/常见漏洞评分系统 （CVE/CVSS） 数据的最高加权影响之一。从 2017 年开始的不安全反序列化现在是这个更大类别的一部分。
• A09:2021-Security Logging and Monitoring Failures was previously Insufficient Logging & Monitoring and is added from the industry survey (#3), moving up from #10 previously. This category is expanded to include more types of failures, is challenging to test for, and isn’t well represented in the CVE/CVSS data. However, failures in this category can directly impact visibility, incident alerting, and forensics.
• 不足的安全日志和监控 以前是 Insufficient Logging & Monitoring，是从行业调查 （#3） 中添加的，从之前的 #10 上升。此类别已扩展为包括更多类型的故障，测试具有挑战性，并且在 CVE/CVSS 数据中没有得到很好的表示。但是，此类别中的故障可能会直接影响可见性、事件警报和取证。
• A10:2021-Server-Side Request Forgery is added from the Top 10 community survey (#1). The data shows a relatively low incidence rate with above average testing coverage, along with above–average ratings for Exploit and Impact potential. This category represents the scenario where the security community members are telling us this is important, even though it’s not illustrated in the data at this time.
• 2021-服务器端请求伪造是从前 10 名社区调查 （#1） 中添加的。数据显示，检测覆盖率相对较低，检测覆盖率高于平均水平，漏洞利用和影响潜力评级也高于平均水平。此类别表示安全社区成员告诉我们这很重要的场景，即使目前数据中未说明这一点。

什么时候用top 10

从2003年top 10出来后，就有组织把它当做标准，但是top10只是一个awareness document，使用top10的难点在于这些问题不一定是容易测试的问题

除了top10,owasp还有ASVS，是一个应用安全验证标准。如下表格显示了什么时候应该才用top10，什么时候用ASVS，可以看到ASVS是一个比较全面的标准，top10是一个比较基础的规则。

鼓励任何想要采用应用程序安全性的人 使用 OWASP 应用程序安全验证标准 （ASVS） 的标准，因为它旨在进行验证和测试，并可用于 安全开发生命周期的所有部分。

ASVS 是工具供应商唯一可接受的选择。工具不能 全面检测、测试或防范 OWASP 前 10 名，原因是 OWASP十大风险中的几种性质，参考 A10：04-不安全的设计。OWASP不鼓励任何工具声明可以覆盖 OWASP 2021的top10，因为是不可能做到的。

如何使用 OWASP Top 10 启动 AppSec 计划

首先，OWASP Top 10 从未被设计作为 AppSec 计划。但是，对于许多人来说，从某个地方开始是必不可少的 刚刚开始应用安全之旅的组织。 OWASP Top 10 2021 是一个良好的开端，作为清单和 依此类推，但这本身是不够的。

第 1 阶段。确定应用安全计划的差距和目标

许多应用程序安全 （AppSec） 程序尝试在运行之前运行 爬行或行走。这些努力注定要失败。我们强烈 鼓励首席信息安全官和 AppSec 领导层使用 OWASP 软件保障 成熟度模型 （SAMM） 用于识别弱点 以及 1-3 年内需要改进的领域。第一步是 评估您现在所处的位置，确定治理、设计、 需要解决的实施、验证和操作 确定哪些是需要立即解决的，哪些是可以排期解决的，并优先实施或 改进15项 OWASP SAMM 安全实践。OWASP SAMM可以提供帮助建造并衡量软件保障工作的改进成都。

第 2 阶段 规划paved road secure development lifecycle

paved road的概念是“最简单的方式也是最安全的方式” ，包括 开发团队和安全团队深度合作的文化，最好这两者属于是同一个team。paved road的目标是不断提升，衡量，检测，通过拥有 企业范围的即插即用安全替换库替换不安全的组件，有工具可以检测需要做出哪些提升 ，这允许现有开发工具报告不安全的构建和帮助 开发团队自我纠正，远离不安全的替代方案。

aims to continuously improve, measure, detect and replace insecure alternatives by having an enterprise-wide library of drop-in secured replacements, with tooling to help see where improvements can be made by adopting the paved road. This allows existing development tools to report on insecure builds and help development teams self-correct away from insecure alternatives.

 实施paved road看起来需要做的东西很多，但它应该被建造，并且随着时间的推移不断提升。还有其他形式的appsec，如 Microsoft 敏捷安全开发生命周期。不是每种 AppSec 计划方法都适合每个企业，需要选择适合于自己企业的。

第 3 阶段。与您的开发团队一起实施paved road

铺砌道路的建造是经过 相关的开发和运营团队。铺砌的道路应该是 与业务战略保持一致，帮助交付更安全的服务 应用程序更快。铺设道路的发展应该是一个整体 涵盖整个企业或应用程序生态系统的练习，而不是 每个应用程序的创可贴，就像过去一样。

第 4 阶段。将所有即将推出的和现有的应用程序迁移到paved road

在开发应用时，使用paved road检测工具，来提升应用的安全。 一旦采用了paved road的某个方面，组织就应该 实施持续集成检查，检查现有代码和 禁止替代方法并警告或拒绝代码合并。这样可以防止不安全的选项潜入代码中，防止技术债务和有缺陷的不安全应用程序。 此类警告应链接到安全的替代方案，使开发 团队会立即得到正确的方案。开发人员可以重构和 快速采用paved road组件。

(如sonar报告，展示出问题的同时显示了如何修改问题的合规方案)

第 5 阶段。测试paved road是否缓解了 OWASP 前 10 名中发现的问题

paved road组件应重视OWASP top 10，例如，如何自动检测或修复vulnerable components，或静态代码分析 IDE 插件，用于检测injection或开始使用已知的库来防御injection。尽可能 提供给团队的安全的drop-in 代替品。 appsec 团队的一项重要任务是确保不断评估和提升这些组件的安全性。 当这些组件更新后，使用这些组件的团队就应该知道应该升级这些组件，最好是自动升级，如果无法自动升级，最少可以用仪表盘工具告知大家。

第 6 阶段。将您的程序构建为成熟的 AppSec 程序

您不能止步于OWASP前10名。它只涵盖 10 种风险 类别。我们强烈鼓励组织采用ASVS，并逐步增加paved road 1、2 和 3 级的组件和测试，具体取决于开发的 应用程序的风险级别。

超越

所有出色的 AppSec 程序都超出了最低限度。每个人都必须遵守 如果我们要掌握 AppSec 漏洞，那就去吧。

• 概念完整性。成熟的 AppSec 程序必须包含一些 安全架构的概念，无论是正式的云还是 企业安全架构或威胁建模

• 自动化和规模化。成熟的 AppSec 程序尝试自动化 他们的大部分可交付成果，使用脚本来模拟 复杂的渗透测试步骤，静态代码分析工具 直接提供给开发团队，协助开发团队 构建 AppSec 单元和集成测试等。

• 文化。成熟的 AppSec 程序试图构建不安全的 设计和消除现有代码的技术债务，方法是 开发团队的一部分，而不是一边。AppSec 团队 将开发团队视为“我们”，而“他们”注定要失败。

• 持续改进。成熟的 AppSec 计划希望 不断改进。如果某些东西不起作用，请停止这样做。如果 有些东西笨拙或不可扩展，请努力改进它。如果 开发团队未使用某些内容，并且没有或 影响有限，做一些不同的事情。只是因为我们做到了 自 1970 年代以来的案头检查等测试并不意味着它是一个好的 想法。衡量、评估，然后构建或改进。

A01：2021 – 访问控制中断

因素

概述

从第五位上升，94%的被测应用发现了某种形式的破坏访问控制，平均发生率为 3.81%，在贡献的数据集中出现次数最多，超过 318K。 值得注意的常见弱点枚举 （CWE） 包括 CWE-200：向未经授权的行为者暴露敏感信息，CWE-201： 将敏感信息插入到发送的数据中，CWE-352： 跨站点请求伪造。

描述

访问控制策略如用户不应该执行超过给定权限的动作，如果访问控制失效通常会导致未授权信息泄露，修改，数据或者执行超过用户限制的业务功能。

通用访问 控制漏洞包括：

• 违反最小权限原则或默认拒绝原则， 访问应仅授予特定功能， 角色或用户，但却可以被任何人访问。is available to anyone

• 通过修改 URL（参数 篡改或强制浏览）、内部应用程序状态或 HTML 页面，或使用攻击工具修改 API 请求。

• 允许查看或编辑他人的帐户，通过提供他人的唯一标识符（不安全的直接对象引用）

• 访问 API，但缺少对 POST、PUT 和 DELETE 的访问控制。

• 特权提升 elevation of privilege。在未登录的情况下以用户身份行事，或 以用户身份登录时充当管理员。

• 元数据操作，例如重播或篡改 JSON Web 令牌 （JWT） 访问控制令牌，或者 Cookie 或隐藏字段 纵以提升权限或滥用 JWT 失效。

• CORS 配置错误允许从未经授权/不受信任的源发起。

• 强制以未经身份验证的用户身份浏览经过身份验证的页面，或者 以标准用户身份访问特权页面。

如何预防

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

• 除公共资源外，默认为 deny。

• 实施一次访问控制机制，并在整个过程中重复使用它们 应用程序，包括最大程度地减少跨域资源共享 （CORS） 的使用。

• model access controls should enforce record ownership，而不是 接受用户可以创建、读取、更新或删除任何 记录。（从数据方面进行权限控制）

• 应通过domain models 强制执行独特的应用程序业务限制要求。

• 禁用 Web 服务器目录列表并确保文件元数据（例如， .git） 和备份文件在 Web 根目录中不存在。

• 日志访问控制失败，在适当的时候提醒管理员（例如， 重复失败）。

• 速率限制 API 和控制器访问，以最大程度地减少 自动化攻击工具。

• 注销后，服务器上的有状态会话标识符应失效。 无状态的 JWT 令牌应该是短暂的，以便 攻击者的机会被最小化。对于long lived JWT，强烈建议 按照 OAuth 标准撤消访问权限。

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

示例攻击场景

场景 #1：应用程序在 SQL 调用中使用未经验证的数据，该调用 正在访问帐户信息：

 pstmt.setString(1, request.getParameter("acct"));
 ResultSet results = pstmt.executeQuery( );

攻击者只需修改浏览器的“acct”参数即可发送 他们想要什么帐号。如果未正确验证， 攻击者可以访问任何用户的帐户。

 https://example.com/app/accountInfo?acct=notmyacct

场景#2：攻击者只是强制浏览到目标 URL。管理 访问管理页面需要权限。

 https://example.com/app/getappInfo
 https://example.com/app/admin_getappInfo

如果未经身份验证的用户可以访问任一页面，则这是一个缺陷。如果 非管理员可以访问管理页面，这是一个缺陷。

A02：2021 – 加密失败

A02 Cryptographic Failures – OWASP Top 10:2021

因素

概述

向上移动一个位置到 #2，以前称为敏感数据 暴露，这更像是一个广泛的症状，而不是根本原因， 重点是与密码学（或缺乏密码学）相关的故障。 这通常会导致敏感数据的暴露。包括值得注意的常见弱点枚举 （CWE） 是 CWE-259：使用硬编码密码，CWE-327：损坏或有风险 加密算法和 CWE-331 熵不足。

描述

首先是确定传输和存储时的数据的保护需求。例如，密码、信用卡号、health records、个人信息和需要额外的 保护的商业机密，主要是如果该数据属于隐私法，例如欧盟的 通用数据保护条例 （GDPR） 或法规，例如 金融数据保护，例如 PCI 数据安全标准 （PCI DSS）。 对于所有此类数据：

• 是否有任何数据以明文形式传输？这涉及以下协议 如 HTTP、SMTP、FTP 也使用 TLS 升级，如 STARTTLS。外部 互联网流量是危险的。验证所有内部流量，例如， 在负载平衡器、Web 服务器或后端系统之间。

• 是否默认使用了任何旧的或弱的加密算法或协议，或者旧的代码中有这些。

• 是否正在使用默认加密密钥、生成的弱加密密钥或 重复使用，还是缺少适当的密钥管理或轮换？ 加密密钥是否签入源代码存储库？

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

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

• 初始化向量是否被忽略、重用或未生成 对于加密操作模式是否足够安全？ 是否正在使用像欧洲央行这样的不安全的操作模式？是加密 当经过身份验证的加密更合适时使用？

• 密码是否在没有密码的情况下被用作加密密钥 密码库密钥派生功能？

• 随机性是否用于非设计的加密目的 是否满足加密要求？即使正确的功能是 选择，它是否需要由开发人员播种，如果没有，则有 开发人员覆盖了内置的强大种子设定功能 它有一个缺乏足够熵/不可预测性的种子？

• 是否正在使用已弃用的哈希函数（如 MD5 或 SHA1），或者 加密哈希函数时使用的非加密哈希函数 需要吗？

• 是否使用已弃用加密填充方法，例如 PKCS 编号 1 v1.5 正

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

请参阅 ASVS 加密 （V7）、数据保护 （V9） 和 SSL/TLS （V10）

如何预防

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

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

• 不要不必要地存储敏感数据。尽快丢弃 可能或使用符合 PCI DSS 标准的标记化甚至截断。 未保留的数据不能被盗。

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

• 确保最新和强大的标准算法、协议和 钥匙已到位;使用适当的密钥管理。

• 使用安全协议（如 TLS）加密传输中的所有数据 前向保密 （FS） 密码，密码优先级由 服务器和安全参数。使用指令强制加密 类似于 HTTP 严格传输安全 （HSTS）。

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

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

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

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

• 初始化向量的选择必须使适用于运作模式。对于许多模式，这意味着使用 CSPRNG（以加密方式 安全伪随机数生成器）。对于需要 nonce的模式，则初始化向量 （IV） 不需要 CSPRNG。在所有情况下，对于固定密钥，IV切勿使用两次。

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

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

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

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

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

示例攻击场景

场景 #1：应用程序对信用卡号在数据库中存储使用数据库自动加密。但是，这样数据会在获取时自动解密，允许 SQL 注入缺陷 以明文形式获取信用卡号。

场景 #2：网站不对所有页面使用或强制使用 TLS，或者 支持弱加密。攻击者监控网络流量（例如，在 不安全的无线网络），将连接从 HTTPS 降级到 HTTP，拦截请求，并窃取用户的会话 cookie。然后，攻击者重放此 cookie 并劫持用户的（经过身份验证的） 会话，访问或修改用户的私人数据。除了所说的，还可以更改所有传输的数据，例如，接收者 汇款。

场景 #3：密码数据库使用未加盐或简单的哈希来 存储每个人的密码。文件上传缺陷允许攻击者 检索数据库中的密码。所有未加盐的哈希值都可以被公开，如一些哈希值被计算生成的的彩虹表。使用简单或者快速的hash函数生成的哈希可能会被 GPU 破解，即使加了盐。

代码007普通

打赏 收藏 海报 链接