2021 OWASP Top 10 Web Application Security Risks （2）

A03：2021 – 注入

因素
映射的 CWE 最大发生率 平均发生率 平均加权漏洞利用 平均加权影响 最大覆盖范围 平均覆盖率 总发生次数 CVE 总数
33 19.09% 3.37% 7.25 7.15 94.04% 47.90% 274,228 32,078

概述

注入向下滑动到第三个位置。94%的被测应用发现了了某种形式的注射，最大发生率为 19%，平均发生率为 3%，发生率为 274k。值得注意的常见弱点枚举 （CWE） 包括 CWE-79：XSS、CWE-89：SQL 注入和 CWE-73： 文件名或路径的外部控制。

描述

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

-用户提供的数据不会被应用验证、过滤或净化sanitized。

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

在对象关系映射 （ORM） 搜索中使用恶意数据 参数来提取additional，敏感的记录。

恶意数据被直接使用或串联。SQL 或命令command 包含动态查询、 命令或存储过程的结构或者恶意数据。

一些更常见的注入是 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。

对于任何residual 动态查询，escape special characters using the specific escape syntax for that interpreter.
注意：SQL 结构，例如表名、列名等 无法转义，因此用户提供的结构名称是危的。这是软件报告中的常见问题。

在查询中使用 LIMIT 和其他 SQL controls 来防止以免出现SQL注入时，大量数据记录被披露。

Scenario #1: An application uses untrusted data in the construction of the following vulnerable SQL call:

String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Scenario #2: Similarly, an application’s blind trust in frameworks may result in queries that are still vulnerable, (e.g., Hibernate Query Language (HQL)):

 Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");

In both cases, the attacker modifies the ‘id’ parameter value in their browser to send: ’ UNION SLEEP(10);–. For example:

 http://example.com/app/accountView?id=' UNION SELECT SLEEP(10);--

This changes the meaning of both queries to return all the records from the accounts table. More dangerous attacks could modify or delete data or even invoke stored procedures. 这样的构造能够返回accounts表内的所有记录。

A04：2021 – 不安全的设计

因素

映射的 CWE 最大发生率 平均发生率 平均加权漏洞利用 平均加权影响 最大覆盖范围 平均覆盖率 总发生次数 CVE 总数
40秒 24.19% 3.00% 6.46 6.78 77.25% 42.51% 262,407 2,691

概述

2021 年的新类别侧重于与设计和架构缺陷相关的风险，呼吁更多地使用威胁建模、安全设计模式和参考架构。作为一个社区，我们需要超越编码空间中的“shift left”，转换为对安全设计原则至关重要的pre-code activities。值得注意的常见弱点枚举 （CWE） 包括 CWE-209：生成包含敏感信息的错误消息、CWE-256：未受保护的凭据存储、CWE-501：信任边界冲突和 CWE-522：凭据保护不足。

描述

不安全设计是一个广泛的类别，代表不同的弱点，表示为“missing or ineffective control design”。不安全的设计并不是所有其他前 10 大风险类别的根源。不安全的设计和不安全的实现是有区别的。我们区分设计缺陷和实施缺陷是有原因的，它们有不同的根本原因和补救措施。安全设计仍可能存在实现缺陷，从而导致可能被利用的漏洞。不安全的设计不能通过完美的实现来修复，因为根据定义，needed security controls were never created to defend against attacks。导致设计不安全的因素之一是缺乏正在开发的软件或系统固有的业务风险分析，因此无法确定需要什么级别的安全设计。

需求和资源管理

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

安全设计

安全设计是一种文化和方法，它不断评估威胁，并确保代码经过可靠的设计和测试，以防止已知的攻击方法。
威胁建模应集成到refined sessions（或类似活动）中;
查找数据流和访问控制或其他安全控制中的更改。
在用户故事开发中，确定正确的流程和故障状态，确保责任方和受影响方充分理解和同意它们。determine the correct flow and failure states
分析预期流和故障流的假设和条件，确保它们仍然准确且可取。analyze assumptions and contions for expected and failure flows
确定如何验证假设并强制执行正确行为所需的条件。
确保结果记录在用户情景中。ensure the results are documented in the user story
从错误中吸取教训，并提供积极的激励措施来促进改进。
安全设计既不是附加组件，也不是可以添加到软件中的工具。secure design is neither and add-on nor a tool that you can add to software

安全开发生命周期

安全软件需要安全的开发生命周期、某种形式的安全设计模式、paved road methodology、安全的组件库、工具和威胁建模。在软件项目开始时，在整个项目和软件维护过程中联系您的安全专家。考虑利用 OWASP 软件保障成熟度模型 （SAMM） 来帮助构建安全的软件开发工作。https://owaspsamm.org/

如何预防

建立和使用安全的开发生命周期 ,使用 AppSec 专业人员帮助评估和设计安全性和 隐私相关控制

建立和使用安全设计模式或铺砌道路库 即用型组件 a library of secure design patterns or paved road ready to use components

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

将安全语言和控件集成到用户故事中

在应用程序的每一层集成合理性检查 （从前端到后端）

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

隔离系统层和网络层上，具体取决于 暴露和保护需求 segregate tier layers on the system and network

通过设计在所有层中稳健地隔离租户

限制用户或服务的资源消耗 limit resource consumption bu user or service

示例攻击场景

场景 #1：A credential recovery workflow 凭据恢复工作流可能包括“问题 和答案“，这是 NIST 800-63b、OWASP ASVS ,OWASP 前 10 名所禁止的。问题和答案不能作为证据 身份，因为不止一个人可以知道答案，这就是为什么他们 是被禁止的。这样的代码应该被删除，并替换为更多的 安全设计。

场景#2：一家连锁电影院允许团体预订折扣，并有 最多15名与会者，然后才需要押金。攻击者可以 威胁对此流程进行建模，并测试他们是否可以在几个请求中一次预订 600个席位和 所有电影院，造成巨大的收入损失。

场景#3：零售连锁店的电子商务网站没有 防止黄牛购买高端视频卡的机器人运行 转售拍卖网站。这为视频带来了可怕的宣传 卡片制造商和零售连锁店所有者，并忍受坏血 无法以任何价格获得这些卡的爱好者。小心翼翼的反机器人 设计和域逻辑规则，careful antii-bot desifn and admain logic rules 例如在几秒购买的可用性，可能会识别出不真实的购买和 拒绝此类交易。（意思就是需要设计防止黄牛使用机器人刷票）

A05：2021 – 安全配置错误

因素

映射的 CWE 最大发生率 平均发生率 平均加权漏洞利用 平均加权影响 最大覆盖范围 平均覆盖率 总发生次数 CVE 总数
20 19.84% 4.51% 8.12 6.56 89.58% 44.84% 208,387 789
概述
从上一版的#6 上升，90% 的被测应用测试了某种形式的错误配置，平均发生率为 4.%，并且在此风险类别中出现超过 208k 次常见弱点枚举 （CWE）。随着越来越多的人转向高度可配置的软件，看到这一类别上升也就不足为奇了。 值得注意的 CWE 包括 CWE-16 配置和 CWE-611 不正确 XML 外部实体引用的限制。

描述

如果应用程序处于以下状态，则应用程序可能容易受到攻击：

在 应用程序堆栈或云上配置不正确的权限。 Missing appropriate security hardening across any part of the application stack or improperly configured permissions on cloud services.

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

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

错误处理会显示堆栈跟踪或其他信息量过大的信息。Error handling reveals stack traces or other overly informative error messages to users.

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

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

服务器不发送安全标头或指令，或者它们未设置为安全值。

软件已过期或易受攻击（参见 A06：2021-易受攻击 和过时的组件）。

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

如何预防

应实施安全的安装过程，包括：

可重复的强化过程使其部署快速且简单 另一个被适当锁定的环境。A repeatable hardening process makes it fast and easy to deploy another environment that is appropriately locked down. 开发 、QA 和生产环境都应配置 完全相同，在每个环境中使用不同的凭据。 此过程应自动化，以最大程度地减少设置新的安全环境所需的工作量

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

A task to review and update the configurations appropriate to all security notes, updates, and patches as part of the patch management process (see A06:2021-Vulnerable and Outdated Components). Review cloud storage permissions (e.g., S3 bucket permissions).

分段应用程序架构提供有效且安全 组件或租户之间的分离，进行分段， 容器化或云安全组 （ACL）。

向客户端发送安全指令，例如安全标头。Security Headers

验证 所有环境中的配置和设置。An automated process to verify the effectiveness of the configurations and settings in all environments.

示例攻击场景

场景 #1：应用程序服务器附带了示例应用程序 未从生产服务器中删除。这些示例应用程序具有已知安全漏洞,攻击者可以用来破坏服务器。假设其中一个应用程序中有管理控制台，而默认帐户未做改变。在这种情况下，攻击者就可以使用默认密码登录并控制账户。

场景#2：服务器上未禁用目录列表。一 攻击者发现他们可以简单地列出目录。攻击者发现 并下载已编译的 Java 类，这些类可以进行反编译和 逆向工程以查看代码。然后，攻击者发现应用程序中的严重访问控制缺陷。

场景#3：应用程序服务器的配置允许详细的 错误消息，例如堆栈跟踪，被返回给用户。这 可能会暴露敏感信息或潜在缺陷，例如 已知易受攻击的组件版本。

场景#4：云服务提供商 （CSP） 具有默认共享 其他 CSP 用户向 Internet 开放的权限。这允许 存储在云存储中的敏感数据要访问。
A cloud service provider (CSP) has default sharing permissions open to the Internet by other CSP users. This allows sensitive data stored within cloud storage to be accessed.

A06：2021 – 易受攻击和过时的组件图标

因素

映射的 CWE 最大发生率 平均发生率 最大覆盖范围 平均覆盖率 平均加权漏洞利用 平均加权影响 总发生次数 CVE 总数
3 27.96% 8.77% 51.78% 22.47% 5.00 5.00 30,457 0
概述
它是社区调查中的 top10的第二名，但也有足够的数据来制作 通过数据排名前 10 位。易受攻击的组件是我们面临的一个已知问题 难以测试和评估风险，并且是唯一没有映射到CWE的类别 ，因此默认攻击/影响 使用5.0的重量。值得注意的 CWE 包括 CWE-1104：使用 未维护的第三方组件。

描述

您可能容易受到攻击：

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

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

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

如果您不修复或升级底层平台、框架、 以及基于风险的及时依赖关系。通常修补是每月或每季度任务的环境中发生的，使组织数天或数月 不必要地暴露于已修复的漏洞。

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

如果不保护组件的配置（请参阅 A05：2021-安全配置错误）。

如何预防

应该有一个补丁管理流程，以便：

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

持续清点客户端和 服务器端组件（例如，框架、库）及其 使用的版本、OWASP 依赖关系检查，retire.js 等。持续监控常见漏洞和 披露 （CVE） 和国家漏洞数据库 （NVD） 组件中的漏洞。使用软件组合分析工具来自动化这个流程具。订阅 与您使用的组件安全漏洞相关电子邮件提醒。

仅通过官方来源的安全链接获取组件。 首选已签名的包，以减少包含包修改后的恶意组件（参见 A08：2021-软件和数据完整性 失败）。

监控那些没有维护或者没有为旧版本做安全补丁的库或者组件。如果无法进行修改，请考虑部署虚拟补丁来监控、检测或 防范发现的问题。

Every organization must ensure an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.

示例攻击场景

场景 #1：组件通常与应用程序运行在相同的权限下，因此任何组件中的缺陷都可能导致严重的影响。此类缺陷可能是偶然的（例如，编码错误）或故意的 （例如，组件中的后门）。一些可利用的组件示例 发现的漏洞包括：

CVE-2017-5638，一个 Struts 2 远程代码执行漏洞 允许在服务器上执行任意代码，已被归咎于重大违规行为。

虽然物联网 （IoT） 通常很困难或 无法修补，修补它们的重要性可能很大 （例如，生物医学设备）。

有一些自动化工具可以帮助攻击者找到未打补丁或 系统配置错误。例如，Shodan IoT 搜索引擎可以 帮助您设备中是否仍存在 Heartbleed 漏洞，而这个漏洞已在2014年4月修补。

A07：2021 – 标识和身份验证失败

因素

映射的 CWE 最大发生率 平均发生率 平均加权漏洞利用 平均加权影响 最大覆盖范围 平均覆盖率 总发生次数 CVE 总数
22秒 14.84% 2.55% 7.40 6.50 79.51% 45.72% 132,195 3,897

概述

以前称为“损坏的身份验证”，此类别从第二个位置下滑至第七 ，现在包括与identification failures相关的CWE。值得注意的 CWE 包括 CWE-297：不正确的验证 证书主机不匹配、CWE-287：身份验证不正确和 CWE-384：会话固定。

描述

确认用户的身份、身份验证和会话 管理对于防止与身份验证相关的保护至关重要。如果应用程序出现以下情况，则可能存在身份验证弱点：

允许自动攻击，例如撞库攻击，其中攻击者拥有有效用户名和密码的列表。

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

允许使用默认密码、弱密码或已知密码，例如“Password1” 或“admin/admin”。

使用弱或无效的凭据恢复和忘记密码 过程，例如“基于知识的答案”，这是不安全的。

使用纯文本、加密或弱哈希密码进行数据存储（请参阅 A02：2021-加密故障）。

缺少多重身份验证或多重身份验证无效。

在 URL 中公开会话标识符。Exposes session identifier in the URL.

成功登录后重用会话标识符。

未正确使会话 ID 失效。用户会话或 身份验证令牌（主要是单一登录 （SSO） 令牌）在登录后或者或一段时间不活动期间未正确失效。

如何预防

在可能的情况下，实施多重身份验证以防止credential stuffing自动撞库、暴力破解和凭据被盗 重用攻击。

不要使用任何默认凭据进行交付或部署，尤其是对于 管理员用户。

实施弱密码检查，例如对针对前 10,000 个最差密码列表的密码。测试新的或更改的密码 。

使密码长度、复杂性和轮换策略与 美国国家标准与技术研究院 （NIST） 800-63b 第 5.1.1 节中for Memorized Secrets or other modern, evidence-based password policies.

Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.

限制或越来越多地延迟失败的登录尝试，但要注意不要造成拒绝服务情况。在撞库、暴力破解或 检测到其他攻击发生时，记录在日志中，并并通知管理员 limit or increading delay failed login attempts

Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session identifier should not be in the URL, be securely stored, and invalidated after logout, idle, and absolute timeouts.

示例攻击场景

场景 #1：撞库攻击，使用已知密码列表，是一种常见的攻击。假设应用程序没有实现 自动威胁或撞库保护。在这种情况下， 应用程序可以用作密码预言机，以确定 凭据有效。 used as a password oracle to determine if the credentials are valid.

场景#2：大多数身份验证攻击是由于持续的 使用密码是唯一的验证因素。 密码轮换和复杂性要求鼓励用户使用并重复使用弱密码，这曾经被认为是好的实践。建议组织停止这些操作 按照 NIST 800-63 的做法，并使用多因素身份验证。

场景#3：应用程序会话超时设置不正确。一个 用户使用公共计算机访问应用程序。而不是 选择“注销”，用户只需关闭浏览器选项卡即可离开。一小时后，攻击者使用相同的浏览器，用户仍然是认证状态。（这个一般是几天吧，如果都设置很短不能用了）

A08：2021 – 软件和数据完整性故障

因素

映射的 CWE 最大发生率 平均发生率 平均加权漏洞利用 平均加权影响 最大覆盖范围 平均覆盖率 总发生次数 CVE 总数
10 16.67% 2.05% 6.94 7.94 75.04% 45.35% 47,972 1,152

概述

2021 年的新类别侧重假设软件更新、关键数据和 CI/CD 流水线未验证完整性。加权最高的影响之一 常见漏洞披露/常见漏洞评分系统 （CVE/CVSS） 数据。值得注意的常见弱点枚举 （CWE） 包括 CWE-829：包含来自不受信任的 Control Sphere 的功能、CWE-494：下载不带完整性检查的代码和 CWE-502：对不受信任的数据进行反序列化。

描述

软件和数据完整性故障与代码和基础结构有关 ，并不能防止违反完整性的行为。例如，应用程序依赖不受信任的来源、存储库和内容的插件、库或模块 交付网络 （CDN）。不安全的 CI/CD 流水线可能会引入 未经授权的访问、恶意代码或系统入侵的可能性。 最后，许多应用程序现在都包含自动更新功能，其中 下载更新时未进行充分的完整性验证，并且 应用于以前受信任的应用程序。攻击者可以 可能会上传自己的更新，并在所有的安装用户中进行分发和运行。另一个例子是 对象或数据被编码或序列化为一个结构，攻击者可以查看和修改该结构，使之容易受到不安全反序列化的影响。

如何预防

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

确保库和依赖项（如 npm 或 Maven）是 使用受信任的存储库。如果您的风险状况较高，请考虑托管经过审查的已知良好的内部存储库。

确保用于验证 组件的软件供应链安全工具，例如 OWASP dependency check 或 OWASP CycloneDX 不包含已知漏洞

确保对代码和配置更改进行审计，以最大程度地减少恶意代码或配置被引入软件流水线的可能性。

确保 CI/CD 流水线具有适当的隔离、配置和访问权限 控制以确保流经的代码的完整性 构建和部署流程。

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

示例攻击场景

场景 #1 在不签名的情况下更新：许多家用路由器、机顶盒 包装盒、设备固件和其他软件不会通过签名验证更新 固件。未签名的固件是攻击者日益增长的目标，并且预计只会变得更糟。This is a major concern as many times there is no mechanism to remediate other than to fix in a future version and wait for previous versions to age out.

场景 #2 SolarWinds 恶意更新：民族国家已经 已知攻击更新机制，最近值得注意的攻击是 SolarWinds Orion 攻击。开发该软件的公司有 保护生成和更新完整性过程。尽管如此，还是能够 被颠覆，几个月来，该公司分发了高度 针对 18,000 多个组织进行有针对性的恶意更新，其中 大约有100人受到影响。这是影响最深远和 历史上最严重的这种性质的违规行为。

场景 #3 不安全的反序列化：一个叫React 应用程序调用 Spring Boot 微服务集。作为函数式程序员，他们 试图确保他们的代码是不可变的。他们想出的解决方案 是序列化用户状态并每个请求中 pass it back and forth。An attacker notices the “rO0” Java object signature (in base64) and uses the Java Serial Killer tool to gain remote code execution on the application server.

A09：2021 – 安全日志记录和监控故障图标

因素

映射的 CWE 最大发生率 平均发生率 平均加权漏洞利用 平均加权影响 最大覆盖范围 平均覆盖率 总发生次数 CVE 总数
4 19.23% 6.51% 6.87 4.99 53.67% 39.97% 53,615 242

概述

安全日志记录和监控来自前 10 名社区调查 （#3），比起2017年的top10上升了一点。日志记录和 监控测试可能具有挑战性，通常涉及访谈或 询问在渗透测试期间是否检测到攻击。对于此类别没有大量的 CVE/CVSS 数据，但检测和响应 违规行为至关重要。尽管如此，它it can be very impactful for accountability, visibility, incident alerting, and forensics.This category expands beyond CWE-778 Insufficient Logging to include CWE-117 Improper Output Neutralization for Logs, CWE-223 Omission of Security-relevant Information, and CWE-532 Insertion of Sensitive Information into Log File.

描述

这个类别是为了帮助检测， 上报并响应主动违规行为。没有日志记录和 监控，无法检测到违规行为。日志记录不足， 检测、监控和主动响应随时发生：

Auditable events，例如登录、失败登录和高价值交易未被日志记录。

Warnings and errors generate no, inadequate, or unclear log messages.

Logs of applications and APIs are not monitored for suspicious activity.

日志仅存储在本地。

适当的警报阈值和响应升级流程 没有到位或有效。

通过动态应用程序安全测试 （DAST） 工具（如 OWASP ZAP）进行渗透测试和扫描 没有触发警报。

Penetration testing and scans by dynamic application security testing (DAST) tools (such as OWASP ZAP) do not trigger alerts.

The application cannot detect, escalate, or alert for active attacks in real-time or near real-time.

You are vulnerable to information leakage by making logging and alerting events visible to a user or an attacker (see A01:2021-Broken Access Control). https://owasp.org/Top10/A01_2021-Broken_Access_Control/

如何预防

开发人员应实现以下部分或全部控制，根据应用的风险：

确保所有登录、访问控制和服务器端输入验证被记录在日志中，并且记录足够的用户上下文来识别可以的或者恶意的账户，并且支持延迟分析。

确保以日志管理的格式生成日志 解决方案可以很容易地使用。Ensure that logs are generated in a format that log management solutions can easily consume.

确保日志数据编码正确，以防止注入或 对日志记录或监控系统的攻击。Ensure log data is encoded correctly to prevent injections or attacks on the logging or monitoring systems.

确保高价值交易具有完整性的审计跟踪 防止篡改或删除的控件，例如仅追加 数据库表或类似表。Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion, such as append-only database tables or similar.

DevSecOps 团队应建立有效的监视和警报 以便检测和响应可疑活动 迅速。DevSecOps teams should establish effective monitoring and alerting such that suspicious activities are detected and responded to quickly.

建立或采用事件响应和恢复计划，例如 美国国家标准与技术研究院 （NIST） 800-61r2 或更高版本。Establish or adopt an incident response and recovery plan, such as National Institute of Standards and Technology (NIST) 800-61r2 or later.

有商业和开源应用程序保护框架 例如 OWASP ModSecurity 核心规则集和开源日志 相关软件，例如 Elasticsearch、Logstash、Kibana （ELK） 堆栈，具有自定义仪表板和警报功能。There are commercial and open-source application protection frameworks such as the OWASP ModSecurity Core Rule Set, and open-source log correlation software, such as the Elasticsearch, Logstash, Kibana (ELK) stack, that feature custom dashboards and alerting.

示例攻击场景

场景 #1：儿童健康计划提供者的网站运营商 由于缺乏监视和日志记录，无法检测到违规行为。一个外部机构通知健康计划提供商，攻击者有进入了系统并修改了数以千计的超过 3万儿童敏感健康记录，事后审查发现，该网站 开发人员尚未解决重大漏洞。

场景#2：印度一家大型航空公司发生了涉及更多数据泄露的事件 超过十年的数百万乘客的个人数据， 包括护照和信用卡数据。数据泄露发生在 第三方云托管提供商，之后提供商才通知这家航空公司。

场景#3：一家大型欧洲航空公司遭受了GDPR报告 缺口。据报道，该漏洞是由支付应用程序安全性引起的 攻击者利用的漏洞，收集了超过 400,000 个漏洞 客户付款记录。该航空公司被隐私监管机构罚款20万英镑。

A10：2021 – 服务器端请求伪造 （SSRF）

https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/

因素

映射的 CWE 最大发生率 平均发生率 平均加权漏洞利用 平均加权影响 最大覆盖范围 平均覆盖率 总发生次数 CVE 总数
1 2.72% 2.72% 8.28 6.72 67.72% 67.72% 9,503 385秒

概述

此类别是从 Top 10 社区调查 （#1） 中添加的。数据显示发生相对较低，检测覆盖率高于平均水平，并且 高于平均水平的漏洞利用和影响潜在评级。随着新条目的出现 可能是单个或一小群常见弱点枚举 （CWE） 引起注意和 意识，希望他们受到关注并在今后被归为更大的类别中

描述

每当 Web 应用程序获取远程资源，而不验证用户提供的 URL时，就会发生 SSRF 缺陷 资源。它允许攻击者 强制应用程序将构建的请求发送到意外请求 目的地，即使受防火墙、VPN 或其他类型的 网络访问控制列表 （ACL）。

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

如何预防

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

从网络层

将单独网络中的远程资源访问功能分段到 减少 SSRF 的影响
强制实施“默认拒绝”防火墙策略或网络访问 控制规则以阻止除基本 Intranet 流量之外的所有流量。
提示：
~ 根据应用程序建立防火墙规则的所有权和生命周期。
~ 在防火墙上记录所有接受和阻止的网络流 （请参阅 A09：2021 - 安全日志记录和监控故障）。
Segment remote resource access functionality in separate networks to reduce the impact of SSRF
Enforce “deny by default” firewall policies or network access control rules to block all but essential intranet traffic.
Hints:
~ Establish an ownership and a lifecycle for firewall rules based on applications.
~ Log all accepted and blocked network flows on firewalls (see A09:2021-Security Logging and Monitoring Failures).

从应用层

Sanitize and validate all client-supplied input data 清理和验证所有客户提供的输入数据
Enforce the URL schema, port, and destination with a positive allow list 强制执行具有正允许的 URL 架构、端口和目标 列表
Do not send raw responses to clients 不要向客户端发送原始响应
Disable HTTP redirections 禁用 HTTP 重定向
Be aware of the URL consistency to avoid attacks such as DNS rebinding and “time of check, time of use” (TOCTOU) race conditions
注意 URL 一致性，以避免 DNS 等攻击 重新绑定和“检查时间，使用时间”（TOCTOU） 竞争条件
Do not mitigate SSRF via the use of a deny list or regular expression. Attackers have payload lists, tools, and skills to bypass deny lists.
不要通过使用拒绝列表或正则表达式来缓解 SSRF。 攻击者拥有有效负载列表、工具和技能来绕过拒绝列表。

需要考虑的其他措施

Don’t deploy other security relevant services on front systems (e.g. OpenID). Control local traffic on these systems (e.g. localhost)

For frontends with dedicated and manageable user groups use network encryption (e.g. VPNs) on independent systems to consider very high protection needs
不要在前端系统上部署其他与安全相关的服务（例如 OpenID）。 控制这些系统上的本地流量（例如 localhost）

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

示例攻击场景

攻击者可以使用 SSRF 攻击受 Web 保护的系统 应用程序防火墙、防火墙或网络 ACL，使用以下方案 如：

场景 #1：端口扫描内部服务器 – 如果网络体系结构 未分段时，攻击者可以绘制内部网络并确定是否 根据连接结果，内部服务器上的端口是打开或关闭的，或者 连接或拒绝 SSRF 有效负载连接所经过的时间。

场景#2：敏感数据泄露 – 攻击者可以访问本地 文件或内部服务来获取敏感信息，例如 file:///etc/passwdhttp://localhost:28017/

场景#3：访问云服务的元数据存储 - 大多数云 提供程序具有元数据存储，例如 .攻击者可以读取元数据以获取敏感信息。http://169.254.169.254/

场景#4：破坏内部服务 – 攻击者可以滥用 内部服务进行进一步的攻击，例如远程代码 执行 （RCE） 或拒绝服务 （DoS）。

A11：2021 – 下一步

https://owasp.org/Top10/A11_2021-Next_Steps/
根据设计，OWASP Top 10 天生就被限制在最 10 个 重大风险。每个OWASP的前10名都考虑了“处于风口浪尖”的风险 ，但也有很多风险未被选上。

致力于实现成熟应用安全计划或安全性的组织或者希望扩大其覆盖范围的咨询公司或工具供应商 产品，以下四个问题非常值得努力 识别和修正的。

代码质量问题

映射的 CWE 最大发生率 平均发生率 平均加权漏洞利用 平均加权影响 最大覆盖范围 平均覆盖率 总发生次数 CVE 总数
38秒 49.46% 2.22% 7.1 6.7 60.85% 23.42% 101736秒 7564秒

描述

Code quality issues include known security defects or patterns, reusing variables for multiple purposes, exposure of sensitive information in debugging output, off-by-one errors, time of check/time of use (TOCTOU) race conditions, unsigned or signed conversion errors, use after free, and more. The hallmark of this section is that they can usually be identified with stringent compiler flags, static code analysis tools, and linter IDE plugins. Modern languages by design eliminated many of these issues, such as Rust’s memory ownership and borrowing concept, Rust’s threading design, and Go’s strict typing and bounds checking.

如何预防

启用和使用编辑器和语言的静态 代码分析选项。请考虑使用静态代码分析工具。 考虑是否可以使用或迁移到某种语言或 消除 bug 类（如 Rust 或 Go）的框架。（如使用soanr静态代码分析工具）

示例攻击场景

An attacker might obtain or update sensitive information by exploiting a race condition using a statically shared variable across multiple threads.

拒绝服务

映射的 CWE 最大发生率 平均发生率 平均加权漏洞利用 平均加权影响 最大覆盖范围 平均覆盖率 总发生次数 CVE 总数
8秒 17.54% 4.89% 8.3 5.9 79.58% 33.26% 66985秒 973秒

描述

Denial of service is always possible given sufficient resources. However, design and coding practices have a significant bearing on the magnitude of the denial of service 设计和编码实践对DOS有很大影响. Suppose anyone with the link can access a large file, or a computationally expensive transaction occurs on every page. In that case, denial of service requires less effort to conduct.

如何防止

Performance test code for CPU, I/O, and memory usage, re-architect, optimize, or cache expensive operations. Consider access controls for larger objects to ensure that only authorized individuals can access huge files or objects or serve them by an edge caching network.
对于大的对象做访问控制，只有认证的个体可以访问超大文件和对象

示例攻击场景

An attacker might determine that an operation takes 5-10 seconds to complete. When running four concurrent threads, the server seems to stop responding. The attacker uses 1000 threads and takes the entire system offline.
一个动作需要5-10s完成，当执行四个线程时，服务会停止响应。攻击者使用1000个线程并使整个系统下线。

https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html
https://owasp.org/www-community/attacks/Denial_of_Service

内存管理错误

映射的 CWE 最大发生率 平均发生率 平均加权漏洞利用 平均加权影响 最大覆盖范围 平均覆盖率 总发生次数 CVE 总数
14秒 7.03% 1.16% 6.7 8.1 56.06% 31.74% 26576秒 16184秒

描述

Web 应用程序往往是用托管语言编写的 内存语言，例如 Java、.NET 或 node.js（JavaScript 或 TypeScript）。但是，这些语言是在系统中编写的 存在内存管理问题的语言，例如缓冲区或堆 溢出、释放后使用、整数溢出等。有 多年来，许多沙盒逃脱证明了这一点 因为 Web 应用程序语言名义上是内存“安全的”，但他们的底层并非如此。
Web applications tend to be written in managed memory languages, such as Java, .NET, or node.js (JavaScript or TypeScript). However, these languages are written in systems languages that have memory management issues, such as buffer or heap overflows, use after free, integer overflows, and more. There have been many sandbox escapes over the years that prove that just because the web application language is nominally memory “safe,” the foundations are not.

如何预防

现在，许多现代 API 都是用内存安全编写的 Rust 或 Go 等语言。在 Rust 的情况下，内存安全是 该语言的一个关键特征。对于现有代码，使用 严格的编译器标志、强类型、静态代码分析和模糊 测试有助于识别内存泄漏、内存和 阵列溢出等。

示例攻击场景

缓冲区和堆溢出是 多年来攻击者的中流砥柱。攻击者将数据发送到程序，该程序存储在一个容量过小的堆栈缓冲区中。结果是调用堆栈上的信息被覆盖，包括函数的返回指针。该数据设置返回指针的值，以便在函数返回时，它将控制权转移给攻击者数据中包含的恶意代码。
Buffer and heap overflows have been a mainstay of attackers over the years. The attacker sends data to a program, which it stores in an undersized stack buffer. The result is that information on the call stack is overwritten, including the function’s return pointer. The data sets the value of the return pointer so that when the function returns, it transfers control to malicious code contained in the attacker’s data.