OWASP TOP 10你了解几个？

---

OWASP TOP 10

开放式Web应用程序安全项目

OWASP Top 10 是面向开发人员和 Web 应用程序安全性的标准意识文档。它代表了对 Web 应用程序最关键的安全风险的广泛共识。

2021

TOP1 Broken Access Control

损坏的访问控制

访问控制强制执行策略，以便用户不能在其预期权限之外进行操作。故障通常会导致未经授权的信息披露、修改或销毁所有数据，或在用户权限之外执行业务功能。常见的访问控制漏洞包括：

• 违反最小特权原则或默认情况下拒绝，仅应授予特定功能、角色或用户访问权限，但任何人都可以访问。

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

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

• 访问API时缺少POST、PUT和DELETE的访问控制。

• 特权的提升。未登录时以用户身份行事，或以用户身份登录时以管理员身份行事。

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

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

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

预防措施

• 除公共资源外，默认情况下拒绝。
• 实现一次访问控制机制，并在整个应用程序中重复使用它们，包括最小化跨源资源共享（CORS）使用。
• 模型访问控制应该强制记录所有权，而不是接受用户可以创建、读取、更新或删除任何记录。
• 独特的应用程序业务限制要求应由域模型强制执行。
• 禁用web服务器目录列表，并确保web根目录中不存在文件元数据（例如.git）和备份文件。
• 记录访问控制故障，适当时向管理员发出警报（例如，重复故障）。
• 速率限制API和控制器访问，以将自动化攻击工具的危害降至最低。
• 注销后，服务器上的有状态会话标识符应无效。无状态JWT令牌应该是短命的，以便使攻击者的机会窗口最小化。对于寿命较长的JWT，强烈建议遵循OAuth标准来撤销访问。

TOP2 Cryptographic Failures

加密失败

以前称为敏感数据暴露，这更像是一个广泛的症状而不是根本原因，重点是与加密相关的故障（或缺乏加密）。这通常会导致敏感数据的泄露。

第一件事是确定传输中和静止数据的保护需求。例如，密码、信用卡号、健康记录、个人信息和商业秘密需要额外保护，主要是如果这些数据属于隐私法，如欧盟的《一般数据保护条例》（GDPR）或条例，如PCI数据安全标准（PCI DSS）等金融数据保护。对于所有这些数据：

• 是否以明文形式传输任何数据？这涉及到HTTP、SMTP、FTP等协议，这些协议也使用像STARTTLS这样的TLS升级。外部互联网流量是危险的。验证所有内部流量，例如 负载平衡器、web服务器或后端系统之间的流量。
• 默认情况下或旧代码中是否使用了任何旧的或弱的加密算法或协议？
• 是否使用默认加密密钥，是否生成或重复使用弱加密密钥，或者是否缺少适当的密钥管理或轮换？加密密钥是否已签入源代码存储库？
• 是否未强制加密，例如，是否缺少任何HTTP头（浏览器）安全指令或头？
• 收到的服务器证书和信任链是否正确验证？
• 初始化向量是否被忽略、重用，或者生成的初始化向量对于加密操作模式是否足够安全？是否正在使用ECB等不安全的操作模式？当认证加密更合适时是否使用加密？
• 在没有密码基密钥派生功能的情况下，密码是否用作加密密钥？
• 随机性是否用于不满足加密要求的加密目的？即使选择了正确的函数，开发人员是否需要对其进行种子设定，如果不需要，开发人员是否用缺乏足够熵/不可预测性的
  种子过度编写了内置的强大种子设定功能？
• 不推荐使用的散列函数（如MD5或SHA1）是否正在使用，或者在需要加密散列函数时是否使用非加密散列函数？
• 是不推荐使用的加密填充方法，如PKCS 1 v1。5在使用中？
• 加密错误消息或侧通道信息是否可被利用，例如以填充oracle攻击的形式？

预防措施

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

TOP3 Injection

注入

一个应用程序容易受到攻击当：

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

一些更常见的注入有SQL、NoSQL、OS命令、对象关系映射（ORM）、LDAP和表达式语言（EL）或对象图导航库（OGNL）注入。这一概念在所有口译员中都是相同的。源代码审查是检测应用程序是否易受注入攻击的最佳方法。强烈鼓励自动测试所有参数、标题、URL、cookies、JSON、SOAP和XML数据输入。组织可以在CI/CD管道中包括静态（SAST）、动态（DAST）和交互式（IAST）应用程序安全测试工具，以在产品部署之前识别引入的注入缺陷。

预防措施

• 首选的选择是使用安全的API，这样可以避免完全使用解释器、提供参数化接口或迁移到对象关系映射工具（ORM）。注意：即使参数化，如果PL/SQL或T-SQL将查询和数据连接起来，或者使用EXECUTE IMMEDIATE或exec（）执行恶意数据，则存储过程仍然可以引入SQL注入。

• 使用积极的服务器端输入验证。这并不是一种完全的防御，因为许多应用程序需要特殊字符，例如移动应用程序的文本区域或API。

• 对于任何剩余的动态查询，请使用该解释器的特定转义语法转义特殊字符。注意：SQL结构（如表名、列名等）无法转义，因此用户提供的结构名是危险的。这是报表编写软件中的常见问题。

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

TOP4 Insecure Design

不安全设计

不安全设计是一个广泛的类别，代表不同的弱点，表示为“缺失或无效的控制设计”不安全设计不是所有其他前10大风险类别的来源。不安全的设计和不安全的实现之间存在差异。我们区分设计缺陷和实现缺陷是有原因的，它们有不同的根本原因和补救措施。安全设计仍然可能存在实现缺陷，从而导致可能被利用的漏洞。一个不安全的设计不能通过一个完美的实现来修复，因为根据定义，所需的安全控制从未被创建来抵御特定的攻击。导致不安全设计的因素之一是开发中的软件或系统缺乏固有的业务风险分析，因此无法确定需要何种级别的安全设计

需求和资源管理

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

安全设计

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

安全开发生命周期

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

预防措施

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

TOP5 Security Misconfiguration

安全配置错误

如果应用程序是：

• 在应用程序堆栈的任何部分缺少适当的安全强化或对云服务的权限配置不正确。
• 启用或安装了不必要的功能（例如，不必要的端口、服务、页面、帐户或权限）。
• 默认帐户及其密码仍处于启用状态且未更改。(未更改密码)
• 错误处理向用户显示堆栈跟踪或其他信息过多的错误消息。（显示错误）
• 对于升级的系统，最新的安全功能被禁用或未安全配置。
• 应用程序服务器、应用程序框架（例如，Struts、Spring、ASP.NET）、库、数据库等中的安全设置未设置为安全值。
• 服务器不发送安全标头或指令，或者它们未设置为安全值。
• 软件已过时或易受攻击（请参阅A06:2021-易受攻击和过时的组件）。

预防措施

• 可重复的强化过程使部署另一个适当锁定的环境变得快速而轻松。开发、QA 和生产环境都应配置相同，在每个环境中使用不同的凭据。此过程应自动化，以最大限度地减少设置新安全环境所需的工作。
• 一个没有任何不必要的功能、组件、文档和示例的最小平台。删除或不安装未使用的功能和框架。
• 作为补丁管理流程的一部分，审查和更新适用于所有安全说明、更新和补丁的配置的任务（请参阅A06:2021-易受攻击和过时的组件）。查看云存储权限（例如，S3 存储桶权限）。
• 分段应用程序架构通过分段、容器化或云安全组 (ACL) 在组件或租户之间提供有效且安全的分离。
• 向客户端发送安全指令，例如安全标头。
• 验证配置和设置在所有环境中的有效性的自动化过程。

TOP6 Vulnerable and Outdated Components

易受攻击和过时的组件

你可能很脆弱：

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

预防措施

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

TOP7 Identification and Authentication Failures

识别和认证失败

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

• 允许自动攻击，例如撞库，其中攻击者拥有有效用户名和密码的列表。
• 允许蛮力或其他自动攻击。
• 允许使用默认密码、弱密码或众所周知的密码，例如“Password1”或“admin/admin”。
• 使用薄弱或无效的凭据恢复和忘记密码流程，例如无法确保安全的“基于知识的答案”。
• 使用纯文本、加密或弱散列密码数据存储（请参阅 A02:2021-加密失败）。
• 缺少或无效的多因素身份验证。
• 在 URL 中公开会话标识符。
• 成功登录后重用会话标识符。
• 不会正确地使会话 ID 无效。用户会话或身份验证令牌（主要是单点登录 (SSO) 令牌）在注销或一段时间不活动期间未正确失效。

预防措施

• 在可能的情况下，实施多因素身份验证以防止自动凭证填充、暴力破解和被盗凭证重用攻击。
• 不要使用任何默认凭据进行交付或部署，尤其是对于管理员用户。
• 实施弱密码检查，例如针对前 10,000 个最差密码列表测试新密码或更改密码。
• 将密码长度、复杂性和轮换策略与美国国家标准与技术研究院 (NIST) 800-63b 的第 5.1.1 节中关于记忆秘密的指南或其他现代的、基于证据的密码策略保持一致。
• 通过对所有结果使用相同的消息，确保注册、凭证恢复和 API 路径能够抵御帐户枚举攻击。
• 限制或逐渐延迟失败的登录尝试，但注意不要造成拒绝服务场景。当检测到凭证填充、暴力破解或其他攻击时，记录所有故障并提醒管理员。
• 使用服务器端、安全、内置的会话管理器，在登录后生成新的高熵随机会话 ID。会话标识符不应在 URL 中，应安全存储，并在注销、空闲和绝对超时后失效。

TOP8 Software and Data Integrity Failures

软件和数据完整性故障

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

预防措施

• 使用数字签名或类似机制来验证软件或数据来自预期来源且未被更改。
• 确保库和依赖项（例如 npm 或 Maven）正在使用受信任的存储库。如果您有更高的风险状况，请考虑托管经过审查的内部已知良好存储库。
• 确保使用软件供应链安全工具（例如 OWASP Dependency Check 或 OWASP CycloneDX）来验证组件不包含已知漏洞
• 确保对代码和配置更改有一个审查过程，以最大限度地减少恶意代码或配置可能被引入您的软件管道的机会。
• 确保您的 CI/CD 管道具有适当的隔离、配置和访问控制，以确保流经构建和部署过程的代码的完整性。
• 确保未签名或未加密的序列化数据不会在没有某种形式的完整性检查或数字签名的情况下发送到不受信任的客户端，以检测序列化数据的篡改或重放

TOP9 Security Logging and Monitoring Failures

安全日志记录和监控失败

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

• 不记录可审计事件，例如登录、登录失败和高价值交易。
• 警告和错误不会生成、不充分或不清楚的日志消息。
• 不会监控应用程序和 API 的日志是否存在可疑活动。
• 日志仅存储在本地。
• 适当的警报阈值和响应升级过程没有到位或有效。
• 动态应用程序安全测试 (DAST) 工具（例如 OWASP ZAP）的渗透测试和扫描不会触发警报。
• 应用程序无法实时或接近实时地检测、升级或警告主动攻击。

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

预防措施

• 确保可以记录所有登录、访问控制和服务器端输入验证失败，并使用足够的用户上下文来识别可疑或恶意帐户，并保留足够的时间以允许延迟取证分析。
• 确保以日志管理解决方案可以轻松使用的格式生成日志。
• 确保日志数据编码正确，以防止对日志或监控系统的注入或攻击。
• 确保高价值交易具有带有完整性控制的审计跟踪，以防止篡改或删除，例如仅追加数据库表或类似的。
• DevSecOps 团队应该建立有效的监控和警报，以便快速检测和响应可疑活动。
• 制定或采用事件响应和恢复计划，例如美国国家标准与技术研究院 (NIST) 800-61r2 或更高版本。

TOP10 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）上部署其他安全相关服务。控制这些系统上的本地流量（例如本地主机）
• 对于具有专用和可管理用户组的前端，在独立系统上使用网络加密（例如 VPN）来考虑非常高的保护需求

翻译至:https://owasp.org/Top10/