OWASP Top 10：2021

我最近开始学习信息安全相关的知识，从OWASP TOP 10入手。结果上网想找中文版内容逃课的时候，发现要么翻译质量差，要么版本较老（2017年的版本），只好自己花了点时间手动翻译了一遍，应当比当下互联网上大多数能找到的中文版本要好一些。

OWASP

OWASP是开放式Web应用程序安全项目（Open Web Application Security Project），是一个非营利组织。它提供有关计算机和互联网应用程序的公正、实际、有成本效益的信息。其目的是协助个人、企业和机构来发现和使用可信赖软件。

OWASP Top 10 列出了最常见的10类漏洞，用以分类和标记网络安全漏洞的严重程度。

Common Weakness Enumeration 常见缺陷列表(CWE) 是一个软件社区项目，列出了软硬件的弱点和漏洞，让人们更好理解软件的缺陷，并自动化地识别、修复以及预防这些缺陷。

A01 无效的访问控制

Broken Access Control 无效的访问控制

从第5位上升成为Web应用程序安全风险最严重的类别；提供的数据表明，平均1.81%的测试应用程序具有一个或多个CWE，且此类风险中CWE总发生漏洞应用数超过31.8万次。在应用程序中出现的34个匹配为“失效的访问控制”的CWE次数比任何其他类别都多。

描述

失效的访问控制，也叫越权，指的是在未对通过身份验证的用户，实施恰当的访问控制。攻击者可以利用这一漏洞，访问未经授权的功能或数据。

分为水平越权和垂直越权：

• 水平越权：用户能够访问和修改同级别的其他用户的私有内容。
• 垂直越权：用户能够获得等级更高的管理员权限，如修改敏感信息，更改访问权限等。

常见的访问漏洞包括：

1. 默认情况下，违反最小特权或拒绝原则，将本应仅授予特定功能、角色或用户的访问权限提供给任何人访问。
2. 通过修改 URL、内部应用程序状态或 HTML 页面，或仅使用自定义 API 攻击工具来绕过访问控制检查。
3. 允许将 URL 中的参数更改为其他用户的记录，允许查看或编辑其他人的帐户。
4. 特权提升。在未登录的情况下充当用户或以用户身份登录时获得管理员权限。
5. 元数据操作，例如重放或篡改 JSON Web 令牌 (JWT) 访问控制令牌，或用于提升权限或滥用 JWT 失效的 cookie 或隐藏字段。
6. 跨域资源共享 （CORS） 错误配置，允许未经授权的 API 访问。
7. 访问 API 时缺少对 POST、PUT 和 DELETE 的访问控制。

预防

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

1. 除公共资源外，默认情况下拒绝访问。
2. 只实施一次访问控制，并在整个应用程序中重复使用它们，包括最大限度地减少跨域资源共享 （CORS） 的使用。
3. 模型访问控制应强制实施记录所有权，而不是接受用户可以创建、读取、更新或删除任何记录。
4. 域模型应强制实施唯一的应用程序业务限制要求。
5. 禁用 Web 服务器文件列表，并确保 Web 根目录中不存在文件元数据（例如 .git）和备份文件。
6. 记录访问控制失败日志，在适当的时候提醒管理员（例如，多次登录失败）。
7. 限制 API 和控制器访问的频率，以最大程度地减少自动攻击工具的危害。
8. 注销后，服务器上的有状态会话标识符应失效。无状态 JWT 令牌应该是短暂的，以便将攻击者的机会之窗降至最低。对于寿命较长的 JWT，强烈建议遵循 OAuth 标准来撤销访问权限。

A02 加密机制失效

Cryptographic Failures 加密机制失效

排名上升1位，以前被称为“A3:2017-敏感信息泄漏（SensitiveData Exposure）”。敏感信息泄漏是常见的症状，而非根本原因。更新后的名称侧重于与密码学相关的风险，即之前已经隐含的根本原因。此类风险通常会导致敏感数据泄露或系统被攻破。

在之前的Top10中，“加密失败”以前叫做“敏感数据泄露”，敏感数据泄露的根本原因是对数据加密存在有机可乘的漏洞，因此2021版改称为“加密失败”更贴切一些。

描述

首先应当确认数据的保密需求，对于需要加密或加密传输的数据，常见的漏洞包括：

1. 数据采用明文形式传输，例如使用HTTP、SMTP和FTP等协议。
2. 默认情况下或在老代码中使用弱加密算法或过时的加密算法。
3. 加密算法中忽视初始化向量，或者使用了安全性较低的操作模式（如 AES 的 ECB 模式）。
4. 使用了弱密码或者默认密码。
5. 未强制执行加密，或缺少 HTTP 安全指令或标头。
6. 用户代理不验证服务器证书是否有效。
7. 使用了安全性低的随机数生成方法。
8. 未适当使用哈希函数，或使用了低安全性的哈希函数（如 MD5 或 SHA1）。
9. 使用了低安全性的加密填充方法。
10. 对于某些结构化消息的加密有可能被用于密文分析。

预防

1. 对数据进行分类，确认数据的敏感级别，并应用安全分级控制。
2. 数据使用完毕后尽快销毁。
3. 加密所有静态的敏感数据。
4. 使用最新最安全的加密算法，妥当保管密钥。
5. 使用安全协议加密传输中的数据。
6. 禁止缓存敏感数据。
7. 不使用 FTP 和 SMTP 等旧协议来传输敏感数据。
8. 不使用过时的哈希算法，使用高强度哈希算法并且加盐。
9. 使用经过身份验证的加密，而不仅仅是加密。
10. 不要直接使用密码加密，而应该基于密码生成密钥。
11. 独立验证配置和设置的有效性。

A03 注入

Injection 注入

排名下滑两位。94%的应用程序进行了某种形式的注入风险测试，发生安全事件的最大率为19%，平均率为1.37%，匹配到此类别的33个CWE共发生21.4万次，是出现第二多的风险类别。原“A07:2017-跨站脚本（XSS）”在2021年版中被纳入此风险类别。

随着大量主流框架被使用，发生注入攻击的概率也随之下降，“注入”也从2017年的第一位下降到第三位。

描述

注入的本质是业务数据被当成控制语句来执行。

SQL 注入是典型的注入攻击，攻击者可以在 web 应用程序中事先定义好的查询语句的结尾，添加额外的 SQL 语句，从而实现非法操作。

XSS 跨站脚本攻击是 Web 应用中非常常见的攻击，后端服务器从前端获取用户的输入，拼接到动态页面或者服务器的代码当中。当攻击者在输入中添加获取关键信息并回显的代码，就可以进行攻击。

此外，各种语言中的exec()，eval()执行函数是注入攻击的重灾区。

常见的漏洞包括：

1. 不验证、过滤和清理用户提供的数据。
2. 没有上下文感知转义的动态查询，或非参数化调用直接在解释器中使用。
3. 在对象关系映射 (ORM) 搜索参数中使用恶意数据来提取额外的敏感记录。
4. 直接使用或连接恶意数据。SQL 或命令包含动态查询、命令或存储过程中的结构和恶意数据。

预防

1. 使用安全的 API，使用参数化、预编译的数据库接口，避免使用解释器。也要避免直接拼接用户输入的内容到查询语句上。
2. 使用对象-关系映射(Object Relational Mapping, ORM)。在面向对象编程中，将关系型数据库的数据映射到内存中的业务对象实体。
3. 不信任任何的用户输入，主动验证服务器端的输入，尤其是特殊字符。在涉及大量特殊字符的应用中，这一条很难做到。
4. 使用 LIMIT 和其他 SQL 控制语句，避免大规模的泄露。

A04 不安全的设计

Insecure Design 不安全的设计

2021年版的一个新类别，其重点关注与设计缺陷相关的风险。如果我们真的想让整个行业“安全左移” ，我们需要更多的威胁建模、安全设计模式和原则，以及参考架构。不安全设计是无法通过完美的编码来修复的；因为根据定义，所需的安全控制从来没有被创建出来以抵御特定的安全攻击。

描述

“不安全设计”是2021年新增的一个类型，它重点关注的是设计缺陷的风险。“不安全设计”代表的是一类漏洞，常见的例子是短信或图形验证码的设计。

不安全的设计和不安全的实现是有区别的，安全的设计可能存在不安全的实现，但不安全的设计无法通过完美的实现来弥补。这类安全问题的原因是对软件系统缺乏应有的业务风险分析。

预防

1. 建立和使用安全的开发周期。
2. 使用符合安全设计模式的库。
3. 在关键的身份认证、访问控制、业务逻辑等地方使用威胁建模。
4. 在应用的每一层集成合理性审计。
5. 使用单元测试和集成测试。
6. 根据暴露和保护的需求对不同层次的资源和实体进行隔离，例如，不同功能的网段区域之间不能互相访问。
7. 根据用户或者业务的不同，限制资源消耗。
8. 应用“纵深防御”原则，在应用的不同位置根据需要应用合适的防御手段。

A05 安全配置错误

Security Misconfiguration 安全配置错误

排名上升一位。90%的应用程序都进行了某种形式的配置错误测试，平均发生率为1.5%，超过21.8万次的CWE匹配到此风险类别。随着可高度配置的软件越来越多 ， 这一类别 的风险也开始 上 升 。原 “A04:2017-XML External Entities(XXE) XML外部实体”在2021年版中被纳入此风险类别。

90%的web应用程序都经历过错误配置测试，这些将导致安全风险。

描述

常见的漏洞：

1. 在应用程序堆栈的任何部分缺少适当的安全强化，或对云服务的权限配置不正确。
2. 启用或安装了不必要的功能（例如，不必要的端口、服务、页面、帐户或权限）。
3. 默认帐户及其密码仍处于启用状态且未更改。
4. 发给用户的错误消息暴露的信息过多，如堆栈信息等。
5. 对于升级的系统，最新的安全功能被禁用或未安全配置。
6. 应用程序服务器、应用程序框架（例如，Struts、Spring、ASP.NET）、库、数据库等中的安全设置未设置为安全值。
7. 服务器不发送安全标头或指令，或者它们未设置为安全值。

预防

1. 应针对不同环境对安全配置进行统一化、自动化配置，以降低设置新的安全环境所需的工作量。
2. 删除或不安装未使用的功能、框架、组件、文档和示例。

A06 自带缺陷和过时的组件

Vulnerable and Outdated Components 自带缺陷和过时的组件

排名上升三位。在社区调查中排名第2。同时，通过数据分析也有足够的数据进入前10名，是我们难以测试和评估风险的已知问题。它是唯一一个没有发生CVE漏洞的风险类别。因此，默认此类别的利用和影响权重值为1.0。原类别命名为“A09:2017-Using Componentswith Known Vulnerabilities 使用含有已知漏洞的组件”。

描述

如果客户端和服务器使用了易受攻击的组件版本，就可能成为被攻击者攻击的目标。

常见的漏洞有：

1. 不知道所使用的组件的版本。
2. 不定期扫描漏洞，不关注所使用组件的官方公告。
3. 没有以基于风险的方式及时修复或升级底层平台、框架和依赖项。这通常发生在按月或者按季度进行安全修复的环境中，使组织面临数天或数月不必要地暴露于固定漏洞的风险。
4. 软件开发人员不测试、升级或修补库的兼容性。
5. 不保护组件的配置。

预防

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

1. 删除未使用的依赖项、不必要的功能、组件、文件和文档。
2. 使用版本、OWASP 依赖项检查、停用.js等工具，持续清点客户端和服务器端组件（例如框架、库）的版本及其依赖项。持续监控常见漏洞和披露 （CVE） 以及国家漏洞数据库 （NVD） 等来源，以了解组件中的漏洞。使用软件成分分析工具自动执行该过程。订阅与你使用的组件相关的安全漏洞的电子邮件警报。
3. 仅通过安全链接从官方来源获取组件。首选已签名的程序包，以减少包含已修改的恶意组件的可能性。
4. 监视未维护或未为旧版本创建安全修补程序的库和组件。如果无法进行修补，请考虑部署虚拟修补程序来监视、检测或防范发现的问题。
5. 每个组织都必须确保在应用程序或产品组合的生存期内持续制定计划，用于监视、分类和应用更新或配置更改。

A07 身份识别和认证失效

Identification and Authentication Failures 身份识别和认证失效

排名下滑五位。原标题“A02:2017-Broken Authentication失效的身份认证”。现在包括了更多与识别错误相关的CWE。这个类别仍然是Top 10的组成部分，但随着标准化框架使用的增加，此类风险有减少的趋势。

描述

通俗地说，该漏洞会导致攻击者使用用户的用户名和密码进行填充，从而入侵系统。

常见的漏洞有：

1. 允许自动攻击，例如撞库、字典攻击或暴力破解。
2. 允许使用默认密码、弱密码或众所周知的密码，例如“Password1”或“admin/admin”。
3. 使用弱或无效的凭据恢复和忘记密码流程，例如无法确保安全的“基于知识的答案”。
4. 使用纯文本、加密或弱散列密码。
5. 不使用或无效的多因素身份验证。
6. 在 URL 中公开会话 ID。
7. 成功登录后不轮换会话 ID。
8. 用户会话或身份验证令牌（主要是单点登录 (SSO) 令牌）缺少定时失效机制。

预防

1. 如果可能，请实施多因素身份验证（实体所知、实体所有、实体特征三者包含二者以上），以防止自动撞库、暴力破解和凭据被盗重用攻击。
2. 保证多因素身份验证的安全性。譬如，身份卡应当有安全的加密机制，不能被简单地复制；人脸识别不能被照片或者面具欺骗；指纹识别不能被指纹模型欺骗。
3. 不要使用任何默认密码，特别是对于管理员用户。
4. 实施密码复杂性和密码轮换策略。
5. 遵循最小信息原则，对于不同的注册、登录、凭据恢复等操作，统一返回的消息格式，信息应当尽量地概括和模糊。如用户登录密码输错时应显示“登录失败”或“用户名或密码错误”，而不是“密码错误”，后者会暴露用户名信息。
6. 对于失败的登录尝试进行限制，连续失败次数过多时进行账户锁定。记录所有错误，并在检测到凭据填充、暴力破解或其他攻击时向管理员发出警报。
7. 在服务器端使用安全的内置会话管理器，会话ID应具有足够强的随机性。会话标识符不应位于 URL 中，应安全存储，并在注销、空闲和超时后失效。

A08 软件和数据完整性故障

Software and Data Integrity Failures 软件和数据完整性故障

2021年版的一个新类别，其重点是：在没有验证完整性的情况下做出与软件更新、关键数据和CI/CD管道相关的假设。此类别共有10个匹配的CWE类别，并且拥有最高的平均加权影响值。原“A08:2017-Insecure Deserialization不安全的反序列化”现在是本大类的一部分。

描述

同样，这也是一个新增的类型，指的是在不验证完整性的情况下做出与软件更新、关键数据和CI/CD管道相关的假设。

CI/CD: 持续集成、持续交付、持续部署(Continuous Integration, Continuous Delivery, Continuous Deployment)，指在应用开发阶段自动化地向用户交付应用。

常见漏洞包括：

• 软件或固件的更新不使用签名机制
• 软件更新源被恶意修改，如数据投毒、SolarWinds被黑客植入后门等
• 不安全的反序列化

预防

1. 使用数字签名或类似机制来验证软件或数据是否来自预期来源且未被更改。
2. 使用软件供应链安全工具来验证组件是否不包含已知漏洞。
3. 对代码与配置进行审计。
4. 确保 CI/CD 管道具有适当的隔离、配置和访问控制，以确保流经生成和部署过程的代码的完整性。
5. 确保在没有某种形式的完整性检查或数字签名的情况下，不会将未签名或未加密的序列化数据发送到不受信任的客户端，以检测序列化数据的篡改或重播。

A09 安全日志和监控失效

Security Logging and Monitoring Failures 安全日志和监控失效

排名上升一位。来源于社区调查（排名第3）。原名为“A10:2017-Insufficient Logging & Monitoring 不足的日志记录和监控”。此类别现扩大范围，包括了更多类型的、难以测试的故障。此类别在CVE/CVSS 数据中没有得到很好的体现。但是，此类故障会直接影响可见性、事件告警和取证。

2017年以前，“安全日志记录和监控失败”叫做“日志记录和监控不足”，此类型已经扩展包括很多类型的漏洞。它指的是在没有日志记录和监控，将无法检测到漏洞，此类故障会直接影响可见性、事件报警和取证。

描述

此类别旨在帮助检测，升级和响应活动违规行为。如果没有日志记录和监视，则无法检测到违规行为。常见的漏洞：

1. 不记录可审计的事件，例如登录、失败登录和高价值交易。
2. 警告和错误不生成，或者生成不充分不清楚的日志消息。
3. 不会监控应用程序和 API 的日志是否存在可疑活动。
4. 未对用户输入的内容进行验证导致日志注入（譬如，用户名中包含换行符\n\r，导致日志被迫分行而失效）。
5. 日志仅存储在本地。
6. 警报阈值和响应升级流程不到位。
7. 渗透测试工具（例如 OWASP ZAP）的渗透测试和扫描不会触发警报。
8. 应用程序无法实时或接近实时地检测、升级或警告主动攻击。
9. 用户或攻击者可以看到日志记录和警报事件，导致信息泄漏。

预防

1. 确保所有登录、访问控制和服务器端输入验证失败都可以使用足够的用户上下文进行记录，以识别可疑或恶意帐户，并保留足够的时间以允许延迟的取证分析。
2. 以清晰的格式生成日志，使日志管理软件能够进行有效的分析。
3. 确保正确编码日志数据，以防止对日志记录或监视系统进行注入或攻击。
4. 确保高价值事务具有具有完整性控制的审计跟踪，以防止篡改或删除。
5. 开发、运营和安全团队应建立有效的监控和警报，以便快速检测和响应可疑活动。
6. 建立或采用事件响应和恢复计划。

A10 服务端请求伪造

Server Side Request Forgery (SSRF) 服务端请求伪造

2021年版的一个新类别，来源于社区调查（排名第1）。数据显示发生率相对较低，测试覆盖率高于平均水平，并且利用和影响潜力的评级高于平均水平。加入此类别风险是说明：即使目前通过数据没有体现，但是安全社区成员告诉我们，这也是一个很重要的风险。

描述

一般而言，用户是只能访问暴露在公网的 Web 服务器，而无法访问内网的资源。

但是，由于现代 Web 应用程序常常提供 API，以 url 作为参数来进行资源的访问。此时，Web 服务器成了用户的代理服务器。

当攻击者利用这一特性并构造 url 进行服务器内网的访问，而内网又缺少相应的访问控制时，由于请求的发起者是 Web 服务器，所以访问不会被拦截，攻击者就能够非法地从外网访问到内网的机密内容。

预防

• 从网络层

  • 在单独的网络中分段远程资源访问功能，以减少 SSRF 的影响
  • 强制实施“默认拒绝”防火墙策略或网络访问控制规则，以阻止除基本 Intranet 流量之外的所有流量。

• 从应用层

  • 清理并验证所有客户提供的输入数据。
  • 使用白名单记录允许的 URL。
  • 不要向客户端发送原始响应，应当进行过滤。
  • 禁用 HTTP 重定向。
  • 请注意 URL 一致性，以避免 DNS 重新绑定和“检查时间、使用时间”（TOC、TOU） 争用条件等攻击。

不要通过使用黑名单或正则表达式过滤来缓解 SSRF。攻击者拥有绕过拒绝列表的有效负载列表、工具和技能（例如短链接）。