OWASP Top 10 2021 简介

OWASP Top 10 2021 是全新的，具有新的图形设计和一页有用的信息图。

2021 年前 10 名发生了什么变化

有三个新类别，四个类别的命名和范围发生了变化，并且 2021 年的前 10 名中进行了一些合并。

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

从第五位上升；94% 的应用程序都经过了某种形式的破坏访问控制的测试。映射到 Broken Access Control 的 34 个 CWE 在应用程序中出现的次数比任何其他类别都多。

A02:2021-Cryptographic Failures 加密失败

上移一位至 #2，以前称为敏感数据泄露，这是广泛的症状而不是根本原因。此处重新关注与密码学相关的漏洞，这些漏洞通常会导致敏感数据泄露或系统受损。

A03:2021-Injection 注入

下滑到第三位。94% 的应用程序都针对某种形式的注入进行了测试，映射到此类别的 33 个 CWE 在应用程序中的出现次数排名第二。跨站点脚本攻击现在是此版本中此类别的一部分。

A04:2021-不安全的设计

是2021 年的一个新类别，重点关注与设计缺陷相关的风险。如果我们真的想作为一个行业“安全左移”，就需要更多地使用威胁建模、安全设计模式和原则以及参考架构。

A05:2021-安全配置错误

从上一版的第 6 位上升；90% 的应用程序都经过了某种形式的错误配置测试。随着更多定制性高度可配置的软件，看到这一类别上升也就不足为奇了。XML 外部实体 (XXE) 的前一个类别现在属于此类别。

A06:2021-Vulnerable and Outdated Components 易受攻击和过时的组件

之前的标题是 使用具有已知漏洞的组件，在行业调查中排名第二，但也有足够的数据通过数据分析进入前 10 名。该类别从 2017 年的第 9 位上升，是我们难以测试和评估风险的已知问题。它是唯一没有任何 CVE 映射到包含的 CWE 的类别，因此默认的利用和影响权重 5.0 被计入他们的分数。

A07:2021-Identification and Authentication Failures 认证和授权失败

以前是 Broken Authentication 失效的身份认证并且从第二位下滑，现在包括与识别失败更多相关的 CWE。这个类别仍然是前 10 名的一个组成部分，但标准化框架的可用性增加似乎有所帮助。

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

是 2021 年的一个新类别，专注于在不验证完整性的情况下做出与软件更新、关键数据和 CI/CD 管道相关的假设。CVE/CVSS 数据的最高加权影响之一映射到该类别中的 10 个 CWE。2017 年的不安全反序列化现在是这一更大类别的一部分。

A09:2021-安全日志记录和监控失败

以前是 日志记录和监控不足，是从行业调查 (#3) 中添加的，从之前的 #10 上升。此类别已扩展为包括更多类型的故障，难以测试，并且在 CVE/CVSS 数据中没有得到很好的体现。但是，此类故障会直接影响可见性、事件警报和取证。

A10:2021-Server-Side Request Forgery 服务器请求伪造

是从行业调查 (#1) 中添加的。数据显示发生率相对较低，测试覆盖率高于平均水平，并且利用和影响潜力的评级高于平均水平。此类别代表行业专业人士告诉我们这很重要的场景，即使目前数据中没有说明。

前 10 名的这一部分比以往任何时候都更受数据驱动，但并非盲目地受数据驱动。我们从贡献的数据中选择了十个类别中的八个，从高水平的行业调查中选择了两个类别。我们这样做的根本原因是，查看贡献的数据就是回顾过去。AppSec 研究人员花时间寻找新的漏洞和测试它们的新方法。将这些测试集成到工具和流程中需要时间。当我们能够可靠地大规模测试漏洞时，可能已经过去了很多年。为了平衡这种观点，我们使用行业调查来询问一线人员他们认为数据可能尚未显示的漏洞。

有很多关于十大风险之间重叠的讨论。根据每个（包括 CWE 列表）的定义，确实没有任何重叠。但是，从概念上讲，可能存在基于更高级别命名的重叠或交互。维恩图多次用于显示这样的重叠。

上面的维恩图代表了 2017 年十大风险类别之间的相互作用。这样做时，几个要点变得明显：

有人可能会争辩说，跨站点脚本最终属于注入，因为它本质上是内容注入。看看 2021 年的数据，XSS 需要进入注入变得更加明显。

重叠仅在一个方向。我们通常会根据最终表现或“症状”而不是（可能很深的）根本原因对漏洞进行分类。例如，“敏感数据暴露”可能是“安全配置错误”的结果；但是，您不会从另一个方向看到它。因此，在交互区域中绘制了箭头以指示发生的方向。

有时这些图表是用A06:2021 Using Components with known Vulnerabilities 中的所有内容绘制的。虽然其中一些风险类别可能是第三方漏洞的根本原因，但它们的管理方式和责任通常不同。其他类型通常代表第一方风险。

A01:2021 – 失效的访问控制   概述

从第五位上升，94% 的应用程序都经过了某种形式的访问控制损坏测试。值得注意的CWE包括CWE-200：将敏感信息暴露给未经授权的参与者、CWE-201：通过发送的数据暴露敏感信息和CWE-352：跨站点请求伪造。

失效的访问控制 - 描述

访问控制强制执行策略，使用户不能在其预期权限之外采取行动。故障通常会导致未经授权的信息泄露、修改或破坏所有数据或执行超出用户限制的业务功能。常见的访问控制漏洞包括：

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

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

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

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

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

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

失效的访问控制 - 如何预防

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

• 除公共资源外，默认拒绝。

• 实施一次访问控制机制并在整个应用程序中重复使用它们，包括最大限度地减少 CORS 的使用。

• 模型访问控制应该强制记录所有权，而不是接受用户可以创建、读取、更新或删除任何记录。

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

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

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

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

• 注销后，JWT 令牌应在服务器上失效。

A02:2021 – 加密失败  概述

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

加密失败 - 描述

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

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

• 默认情况下或在较旧的代码中是否使用任何旧的或弱的加密算法？

• 是否正在使用默认加密密钥、生成或重复使用弱加密密钥，或者是否缺少适当的密钥管理或轮换？

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

• 用户代理（例如，应用程序、邮件客户端）是否不验证收到的服务器证书是否有效？

加密失败 - 如何预防

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

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

• 根据分类应用控制。

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

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

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

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

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

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

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

A03:2021 – 注入    概述

注射向下滑动到第三个位置。94% 的应用程序都针对某种形式的注入进行了测试。值得注意的CWE包括 CWE-79：跨站点脚本、CWE-89：SQL 注入和CWE-73：文件名或路径的外部控制。

注入 - 描述

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

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

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

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

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

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

注入 - 如何预防

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

• 首选选项是使用安全的 API，它完全避免使用解释器，提供参数化接口，或迁移到对象关系映射工具 (ORM)。

• 注意：即使在参数化时，如果 PL/SQL 或 T-SQL 连接查询和数据或使用 EXECUTE IMMEDIATE 或 exec() 执行恶意数据，则存储过程仍然会引入 SQL 注入。

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

• 对于任何残留的动态查询，使用该解释器的特定转义语法转义特殊字符。

• 注意：表名、列名等 SQL 结构不能转义，因此用户提供的结构名是危险的。这是报告编写软件中的常见问题。

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

A04:2021 – 不安全的设计   概述

2021 年的新类别侧重于与设计和架构缺陷相关的风险，并呼吁更多地使用威胁建模、安全设计模式和参考架构。值得注意的CWE包括 CWE-209：生成包含敏感信息的错误消息、 CWE-256：未受保护的凭证存储、CWE-501：信任边界违规和CWE-522：受保护的凭证不足。

不安全的设计 - 描述

不安全设计是一个广泛的类别，代表许多不同的弱点，表现为“缺失或无效的控制设计”。缺少不安全的设计是缺少控制的地方。例如，想象一下应该加密敏感数据的代码，但没有方法。无效的不安全设计是可以实现威胁的地方，但域（业务）逻辑验证不足会阻止该操作。例如，假设域逻辑应该根据收入等级处理流行病税收减免，但不验证所有输入都已正确签名并提供比应授予的更重要的减免收益。

安全设计是一种文化和方法，它不断评估威胁并确保代码经过稳健设计和测试，以防止已知的攻击方法。安全设计需要安全的开发生命周期、某种形式的安全设计模式或铺砌道路组件库或工具，以及威胁建模。

不安全的设计 - 如何预防

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

• 建立和使用安全设计模式库或准备使用组件的铺好的道路

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

• 编写单元和集成测试以验证所有关键流都能抵抗威胁模型

A05:2021 – 安全配置错误    概述

从上一版的第 6 位开始，90% 的应用程序都经过了某种形式的错误配置测试。随着更多转向高度可配置的软件，看到这一类别上升也就不足为奇了。值得注意的CWE包括CWE-16 Configuration和CWE-611 Improper Restriction of XML External Entity Reference。

安全配置错误 - 描述

如果应用程序是：

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

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

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

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

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

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

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

• 软件已过时或易受攻击（请参阅 A06:2021-易受攻击和过时的组件）。

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

安全配置错误 - 如何预防

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

• 可重复的强化过程使部署另一个适当锁定的环境变得快速而轻松。开发、QA 和生产环境都应配置相同，在每个环境中使用不同的凭据。这个过程应该是自动化的，以最大限度地减少设置新安全环境所需的工作。

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

• 作为补丁管理流程的一部分，审查和更新适用于所有安全说明、更新和补丁的配置的任务（请参阅 A06:2021-易受攻击和过时的组件）。查看云存储权限（例如，S3 存储桶权限）。

• 分段应用程序架构通过分段、容器化或云安全组 (ACL) 在组件或租户之间提供有效且安全的分离。

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

• 验证配置和设置在所有环境中的有效性的自动化过程。

A06:2021 – 易受攻击和过时的组件    概述

它在行业调查中排名第二，但也有足够的数据通过数据进入前 10 名。易受攻击的组件是我们难以测试和评估风险的已知问题，并且是唯一没有任何 CVE 映射到包含的 CWE 的类别，因此使用默认的漏洞利用/影响权重 5.0。值得注意的CWE包括CWE-1104：使用未维护的第三方组件和来自 2013 年和 2017 年前 10 名的两个 CWE。

易受攻击和过时的组件 - 描述

你可能很脆弱：

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

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

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

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

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

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

易受攻击和过时的组件 - 如何预防

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

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

• 使用版本、OWASP Dependency Check、retire.js 等工具持续清点客户端和服务器端组件（例如框架、库）及其依赖项的版本。成分。使用软件组合分析工具来自动化该过程。订阅与您使用的组件相关的安全漏洞的电子邮件警报。

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

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

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

A07:2021 – 认证和授权失败    概述

以前称为Broken Authentication，此类别从第二位下滑，现在包括与识别失败相关的 CWE。包括的值得注意的CWE包括CWE-297：不正确的证书验证与主机不匹配、CWE-287：不正确的身份验证和 CWE-384：会话固定。

认证和授权失败 - 描述

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

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

• 允许蛮力或其他自动攻击。

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

• 使用弱或无效的凭据恢复和忘记密码流程，例如无法确保安全的“基于知识的答案”。

• 使用纯文本、加密或弱散列密码（请参阅 A3:2017-敏感数据暴露）。

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

• 在 URL 中公开会话 ID（例如，URL 重写）。

• 成功登录后不要轮换会话 ID。

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

认证和授权失败 - 如何预防

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

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

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

• 将密码长度、复杂性和轮换策略与 NIST 800-63b 的第 5.1.1 节中关于记忆秘密的指南或其他现代的、基于证据的密码策略保持一致。

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

• 限制或增加延迟失败的登录尝试。当检测到凭证填充、暴力破解或其他攻击时，记录所有故障并提醒管理员。

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

A08:2021 – 软件和数据完整性故障    概述

2021 年的新类别侧重于在不验证完整性的情况下做出与软件更新、关键数据和 CI/CD 管道相关的假设。来自 CVE/CVSS 数据的最高加权影响之一。著名的CWE包括CWE-502：不可信数据的反序列化、 CWE-829：包含不受信任的控制领域的功能和 CWE-494：下载没有完整性检查的代码。

软件和数据完整性故障 - 描述

软件和数据完整性故障与不能防止完整性违规的代码和基础设施有关。例如，在对象或数据被编码或序列化为攻击者可以看到和修改的结构的情况下，很容易受到不安全的反序列化的影响。另一种形式是应用程序依赖来自不受信任的来源、存储库和内容交付网络 (CDN) 的插件、库或模块。不安全的 CI/CD 管道可能会导致未经授权的访问、恶意代码或系统受损。最后，许多应用程序现在包括自动更新功能，其中更新在没有充分完整性验证的情况下被下载并应用于以前受信任的应用程序。攻击者可能会上传自己的更新以分发并在所有安装上运行。

软件和数据完整性故障 - 如何预防

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

• 通过签名或类似机制验证软件或数据来自预期来源

• 确保库和依赖项（例如 npm 或 Maven）使用受信任的存储库

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

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

A09:2021 – 安全日志记录和监控失败    概述

安全日志记录和监控来自行业调查（#3），比 2017 年 OWASP 前 10 名中的第十位略有上升。日志记录和监控可能很难测试，通常涉及采访或询问是否在渗透测试期间检测到攻击。此类别的 CVE/CVSS 数据不多，但检测和响应漏洞至关重要。尽管如此，它对于可见性、事件警报和取证仍然非常有影响力。此类别扩展到CWE-778 日志记录不足之外，包括CWE-117 日志的不当输出中和、CWE-223 安全相关信息的遗漏和 CWE-532 将敏感信息插入日志文件。

安全日志记录和监控失败 - 描述

回到 2021 年 OWASP 前 10 名，该类别旨在帮助检测、升级和响应主动违规行为。如果没有日志记录和监控，就无法检测到漏洞。任何时候都会发生日志记录、检测、监控和主动响应不足的情况：

• 不记录可审计的事件，例如登录、失败登录和高价值交易。

• 警告和错误不会生成、不充分或不清楚的日志消息。

• 不会监控应用程序和 API 的日志是否存在可疑活动。

• 日志仅存储在本地。

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

• DAST 工具（例如 OWASP ZAP）的渗透测试和扫描不会触发警报。

• 应用程序无法实时或接近实时地检测、升级或警告主动攻击。

通过使用户或攻击者可以看到日志记录和警报事件，您很容易受到信息泄漏的影响（请参阅 A01:2021 – 损坏的访问控制）。

安全日志记录和监控失败 - 如何预防

开发人员应实施以下部分或全部控制措施，具体取决于应用程序的风险：

• 确保所有登录、访问控制和服务器端输入验证失败都可以用足够的用户上下文来记录，以识别可疑或恶意帐户，并保留足够的时间以允许延迟取证分析。

• 确保以日志管理解决方案可以轻松使用的格式生成日志。

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

• 确保高价值交易具有带有完整性控制的审计跟踪，以防止篡改或删除，例如仅追加数据库表或类似的。

• DevSecOps 团队应该建立有效的监控和警报，以便快速检测和响应可疑活动。

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

有商业和开源应用程序保护框架（例如 OWASP ModSecurity 核心规则集）和开源日志关联软件（例如 ELK 堆栈）具有自定义仪表板和警报功能。

A10:2021 – 服务器端请求伪造 (SSRF)    概述

此类别是从行业调查 (#1) 中添加的。数据显示发生率相对较低，测试覆盖率高于平均水平，利用和影响潜力评级高于平均水平。由于新条目可能是用于关注和意识的单个或一小部分 CWE，因此希望它们受到关注，并且可以在未来版本中纳入更大的类别。

服务器端请求伪造 (SSRF) - 描述

每当 Web 应用程序在未验证用户提供的 URL 的情况下获取远程资源时，就会出现 SSRF 缺陷。它允许攻击者强制应用程序将精心设计的请求发送到意外目的地，即使受到防火墙、VPN 或其他类型的网络 ACL 的保护也是如此。

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

服务器端请求伪造 (SSRF) - 如何预防

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

服务器端请求伪造 (SSRF) - 从网络层

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

• 强制执行“默认拒绝”防火墙策略或网络访问控制规则，以阻止除基本 Intranet 流量之外的所有流量

服务器端请求伪造 (SSRF) - 从应用层：

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

• 使用肯定的允许列表强制执行 URL 架构、端口和目标

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

• 禁用 HTTP 重定向

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

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

原文来自: woj.app