2021版本的OWASP Top10已经出炉，目前处于同行评审阶段。本博客上已有2017版本的归纳总结，考虑到后面几年时间内，该版本（2021版）的Top10将可能对行业产生较大的影响，现单列一篇，总结其内容。

截至本文发布，该版本已经定稿

0 总览

新版本相较于2017版，引入了3个新类别（Insecure Design、Software and Data Integrity Failures、SSRF），修改了原有4个类的名称，以及进行了一些类别的整合。

这一版Top10综合考虑了大数据和行业调查的结果；由于安全人员需要对大数据分析得到的漏洞进行验证和测试，为了保证结论的与时俱进，该机构对一线安全人员进行了问卷调查，由他们来对大数据分析的结果进行补充。

1 Broken Access Control

失效的访问控制 是原榜单的 No. 5 ，现在来到了第一位。在 秋招 | 一些知识点 (gitee.io) 这篇文章中已经对这一安全问题进行了解释，在此不妨再重复一遍。

访问控制策略使得所有用户都只能在其对应的权限之下行动，而失效的访问控制将导致未授权信息的读取、修改、销毁，或导致用户执行其权限之外的功能函数。一般的访问控制漏洞包括以下几点：

• 攻击者可以通过修改URL、应用内部状态、HTML页面或使用API攻击工具来绕过访问控制检查；
• 允许攻击者将数据库主键设置为其他用户，从而导致查看或修改其他用户的信息；
• 提权。未登录时能够执行已登录用户的操作，或已登录用户执行管理员操作；
• 修改元数据，例如JSON Web Token（JWT）的重放或伪造，cookie或隐藏元数据字段的伪造，从而进行提权；
• CORS（跨域资源共享）配置不当，从而导致未授权的API调用；
• 在未登录状态下通过目录遍历找到了需要登录才能访问的界面，或同理找到了管理员界面。

防护措施 ：

• 只开放公共资源，其余资源默认禁止访问；
• 只实现一种访问控制机制，贯彻落实到整个应用中；
• 访问控制模型要明确每一条记录的拥有者，不允许用户随便创建、读取、更新、删除记录；
• 记录失败的访问控制，并及时告警。

2 Cryptographic Failures

密码算法失效 旧称 敏感数据泄露 ，是原榜单的 No. 3 ，现在来到了第二位。敏感数据泄露是现象而非本质，新版本将其表达修改为更加接近问题根源的形式。

人们总是需要考虑数据传输、存储、处理过程中的保护需求，诸如口令、信用卡号、个人信息等数据需要提供额外的保护；一般来说，只要是法律规定的敏感数据都需要进行严密的保护。参照欧盟的GDPR、金融业的PCI DSS等文件，数据保护要考虑如下的问题：

• 数据明文明文传输问题；
• 在默认配置或较老的代码中使用了脆弱的密码算法；
• 使用了默认的/脆弱的/重复使用的密钥，或密钥没有得到妥善的保管；
• 没有强制进行加密；
• 客户端没有对服务端证书进行验证。

防护措施 ：

• 对没必要存储的敏感数据予以及时销毁，存储的敏感数据确保加密。
• 使用最新的、强大的算法、协议、密钥，且密钥妥善管理。
• 确保数据传输过程中受到加密保护，如使用HSTS。

3 Injection

2017版本的OWASP Top10将注入漏洞排在第一位，因此相信很多人都对此有所了解。

以下的情况可能导致注入漏洞的出现：

• 用户提供的数据没有经过应用程序的验证、过滤；
• 未经过转义就将动态请求或非参数化的API调用放入解释器执行；
• 恶意数据被直接使用或拼接使用。

防护措施 ：

• 将数据和可执行的命令/查询语句分离。
• 使用安全的API，避免完全使用解释器，提供参数化的API调用方式。
• 对输入设置白名单，或进行输入验证。
• 转义特殊字符。
• 在查询中使用 LIMIT 或其他SQL控件，防止SQL注入时大量地泄露记录。

4 Insecure Design

你从未见过的船新种类

新版本中新增的 Insecure Design 主要关注由程序设计和架构上的缺陷所引起的安全风险，由此建议人们更多地在工程中使用对威胁进行建模，使用安全的设计模式和参考架构。

不安全设计 其实是一个较为宽泛的类型，其下包含若干常见的脆弱点，但基本可以归纳为“缺失或无效的控制设计”（missing or ineffective control design）。

防护措施 ：

• 与安全专家一起建立并使用安全的开发流程，对现有的安全或敏感数据相关的控制措施进行评估。
• 在安全的模式下构建并使用库/组件。
• 对重要的认证、访问控制、业务逻辑、关键流程等模块进行 威胁建模 。
• 编写单元和集成测试，以验证所有关键流程是否能够抵抗威胁。

5 Security Misconfiguration

不安全的配置 是原榜单的 No. 6 ，现在上升了一位。随着软件的可配置性逐渐变强，这一安全问题的加剧也就不足为奇了。

应用中常见的不安全配置有：

• 云服务中的权限配置错误；
• 安装或启用了不必要的特性（如非必要的服务、端口、页面、账号）；
• 仍在使用默认的账号或密码；
• 把应用的报错信息泄露给了用户；
• 系统升级之后没有及时启用新的安全特性；
• 没有在开发/服务框架中配置好安全属性；
• 服务端没有向客户端发送安全相关的指令或消息头；
• 使用了不安全的组件。

防护措施 ：

• 实施安全的安装过程，如开发、测试、生产环境中保持相同安全配置，且口令不同。安装过程尽量自动化，以减小出错的可能。
• 搭建最小化平台，移除所有不必要的功能、组件、文件及示例。
• 检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分。检查过程中，特别注意云存储的权限。
• 向客户端发送安全指令，如安全标头（想到了CSP、HTTP-Only）。

6 Vulnerable and Outdated Components

存在漏洞的或过时的组件 旧称 使用含有已知漏洞的组件 ，原榜单排第九。在行业调查中，这一安全问题收到了 第二多 的反馈。

这一问题一般出现在：

• 对自己使用的组件或依赖的组件的版本没有清晰的认知；
• 依赖的组件或运行环境存在漏洞或过时（如OS、DBMS等）；
• 没有定期进行组件的漏洞检测，没有关注组件开发者发布的安全公告；
• 没有修复或升级底层依赖；
• 没有对新组建的适配性进行测试；
• 没有对组件进行妥善的安全配置（见上一个问题）。

防护措施 ：

• 移除不使用的依赖、不需要的功能、组件、文档。
• 利用各种工具来持续记录客户端和服务端以及它们的依赖库的版本信息。持续监控CVE等信息来判断已有组件是否有漏洞。
• 使用官方渠道安全地获取组件，并使用签名机制来降低组件被篡改或加入恶意漏洞的风险。
• 监控那些不再维护或不发布安全补丁的库和组件。

7 Identification and Authentication Failures

身份认证和授权失败 旧称 失效的身份认证 ，由原榜 No. 2 下滑到第7位。

对用户身份的认证和授权是非常关键的过程，假如应用中存在如下的问题，则可能导致认证机制的失效：

• 不对暴力破解或其他自动化的身份认证攻击进行防御；
• 允许弱口令的存在；
• 使用不安全的口令找回机制，使得攻击者可以获取或重置用户口令；
• 使用明文或不安全的密码哈希算法（见旧版 敏感数据泄露 或新版 密码算法失效 ）；
• 没有使用或使用了脆弱的多因素认证；
• 没有妥善处理会话ID。包括：在URL中暴露了会话ID，或用户登录之后没有生成新的会话ID，或用户注销之后没有及时销毁会话ID。

防护措施 ：

• 多因素身份认证。
• 弱口令检查。
• 统一注册、凭据恢复等接口，防止用户枚举攻击。
• 会话ID的合理管理，如登录之后生成高度随机的会话ID、妥善存储（肯定不能出现在URL里……）、登出之后及时销毁。

8 Software and Data Integrity Failures

新类别~

我们经常能遇到一些与软件更新或某部分重要数据密切相关的操作，而假如这些操作不对软件和数据完整性进行验证，就会出现问题。一个很好的例子是旧版排名 No. 8 的问题——不安全的反序列化，它实际上属于该类别的一部分。

该问题通常由于代码或架构中没有对软件/数据完整性进行检查，比如程序中使用了来自不受信源的插件、模块或库。近年来，许多程序都集成了自动更新功能，这些更新内容被下载之后没有进行周到的完整性检查，就被应用在了原本受信的程序上；攻击者可能会发布一个恶意更新，并使得这些更新被所有安装了原程序的机器运行。

防护措施 ：

• 使用数字签名或其他类似的机制来保证软件或数据的来源是可信的，且传输过程中并未受到篡改；
• 确保你使用的管理和构建工具（如Maven）是从可信的仓库下载依赖；
• 使用软件供应链安全检查工具，如 OWASP Dependency Check 或 OWASP CycloneDX ，来确保项目使用的组件中没有已知漏洞；
• 建立一个 review 机制来对代码或配置的变更进行审查，防止不安全的变更被引入项目流水线中；
• 不要将未签名或未加密的序列化数据发送给不受信的客户端，防止恶意客户端篡改或重放序列化数据。

9 Security Logging and Monitoring Failures

日志和监控不足 由原版第十位上升来到第九位。日志和审计数据的重要性不言而喻，它们是攻击溯源、账号审计、告警和响应等安全功能的重要依赖。

日志和监控不足的问题一般可能发生在如下的场景：

• 有些事件应被审计，但并未被审计（如登录成功、登录失败）；
• 系统确实产生了告警或报错，但是这些消息呈现的信息不够清晰；
• 应用日志和API日志没有受到实时的监控，由此不能及时发现可疑行为；
• 日志没有妥善存储；
• 告警阈值和响应启动的过程没有设置到位；
• 渗透测试或扫描工具发起的扫描行为没能触发告警；
• 程序不能够对攻击行为进行实时或及时的告警、响应、处置。

对于这些日志和监控信息，最好还要制定适当的访问控制权限，否则也可能存在风险。

防护措施 ：

• 确保所有登录、访问控制和服务端的输入验证失败信息都受到了记录，且这些记录需要带有完整的用户上下文信息，以定位可疑账号；同时，这些记录要存留足够长的事件，以便后续的分析；
• 确保日志格式易于处理，尤其是让自动化的日志管理工具处理（宣传一波TxSOC）；
• 确保日志数据被正确地编码，防止针对日志和监控系统的注入攻击；
• 确保高额交易有完整性控制的审计信息，且审计信息必须防止篡改或删除；
• 制定应急管理预案，保障事件的有序响应和恢复。

10 Server Side Request Forgery（SSRF）

OHHHHHHHH

面试常客了，同时也是业界反馈第一高的问题，但在这一轮的测试过程中没有出现很广泛的SSRF问题。这种新条目覆盖的面一般较小，主要是为了引起人们的关注和认知，后续可能扩大成更广一点的类别。

当一个网站后端使用用户提供的URL来获取远程资源，且未对这一URL进行检查时，就可能发生SSRF。这一漏洞使得后端服务器被攻击者用来向我们不希望的目标发送恶意请求，且这种请求可以绕过WAF、VPN和其他类型的ACL。

当前的Web应用都在向用户提供越来越多的方便功能，包括从用户侧获取URL，这使得SSRF的出现概率在不断增加；同时，随着云计算的发展和程序架构的复杂化，SSRF的严重性也在不断增加。

防护措施 ：

网络层

• 对内网进行划分，尤其是具有远程资源访问功能的部分，以减轻SSRF带来的影响；
• 防火墙上配置“默认拒绝”的规则，只放行一些必要的请求；

应用层

• 检查来自客户端的所有输入数据；
• 对URL格式、端口和目的地址设置一个白名单；
• 不把原始数据返回给客户端（即远程获取到的资源要进行处理）；
• 禁用HTTP重定向；
• 留意URL的有效时间，防止DNS重绑定或TOUTOC（time of use, time of check）竞争条件攻击；

不要用黑名单来防止SSRF，因为攻击者有很多种办法绕过它们。