OWASP Top 10 2021 - Broken Access Control Jumps to the Top Spot
目录
A01:失效的访问控制
什么是越权漏洞：
原因：
分类：
修复防御方案
A02: 加密失败
如何预防
A03:注入
如何预防
A04:不安全的设计
如何预防
A05:安全配置错误
防御
A06:易受攻击和过时的组件
防御
A07:认证和授权失败
防御
A08:软件和数据完整性故障
如何预防
A09:安全日志记录和监控失败
防御
A10:服务器请求伪造
防御
A01:2021-Broken Access Control失效的访问控制
失效的访问控制也就是越权漏洞，从2017年的第五位上升到第一位。超过94%的应用程序都经历过某种形式的越权访问测试。对应到越权访问由24个CWE，比任何其他在应用程序中出现的主题次数都多。
什么是越权漏洞：
该漏洞是指应用在检查授权时存在纰漏，使得攻击者在获得低权限用户账户后，利用一些方式绕过权限检查，访问或者操作其他用户或者更高权限。
原因：
越权漏洞的成因主要是因为开发人员在对数据进行增、删、改、查询时对客户端请求的数据过分相信而遗漏了权限的判定，一旦权限验证不充分，就易致越权漏洞。
分类：
水平越权：可以获得同级别用户权限
垂直权限：享受高几个层次的用户权限
修复防御方案
1、前后端同时对用户输入信息进行校验，双重验证机制
2、调用功能前验证用户是否有权限调用相关功能
3、执行关键操作验证用户身份，验证是否有操作数据的权限
4、直接对象引用的资源ID，防止攻击者枚举ID，敏感数据特殊化处理
5、对可控参数进行严格的检查和过滤
A02:2021-Cryptographic Failures 加密失败
较2017年相比上升1位至第2位。以前被称为敏感数据公开（Sensitive Data Exposure），但只是一种基本症状表现，并不是根本原因。最新版OWASP重新聚焦于与密码学相关的缺陷，这些缺陷通常会导致敏感数据公开或系统受损。这往往会导致敏感数据的暴露。
如何预防
对应用程序处理、存储或传输的数据进行分类。根据隐私法、监管要求或业务需求确定哪些数据是敏感的。
根据分类应用控制。
不要不必要地存储敏感数据。尽快丢弃它或使用符合 PCI DSS 的标记化甚至截断。未保留的数据不能被窃取。
确保加密所有静态敏感数据。
确保拥有最新且强大的标准算法、协议和密钥；使用适当的密钥管理。
使用安全协议（例如具有完美前向保密 (PFS) 密码的 TLS、服务器的密码优先级和安全参数）加密所有传输中的数据。使用 HTTP 严格传输安全 (HSTS) 等指令强制加密。
对包含敏感数据的响应禁用缓存。
使用具有工作因子（延迟因子）的强自适应和加盐散列函数存储密码，例如 Argon2、scrypt、bcrypt 或 PBKDF2。
独立验证配置和设置的有效性。
A03:2021-Injection 注入
较2017版相比下滑至第3位。94% 的应用程序都针对某种形式的注入进行了测试，映射到此类别的 33 个 CWE 在应用程序中的出现次数排名第二。跨站点脚本攻击（XSS）现在是此版本注入的一部分。
如何预防
防止注入需要将数据与命令和查询分开。
首选选项是使用安全的 API，它完全避免使用解释器，提供参数化接口，或迁移到对象关系映射工具 (ORM)。
注意：即使在参数化时，如果 PL/SQL 或 T-SQL 连接查询和数据或使用 EXECUTE IMMEDIATE 或 exec() 执行恶意数据，则存储过程仍然会引入 SQL 注入。
使用正面或“白名单”服务器端输入验证。这不是一个完整的防御，因为许多应用程序需要特殊字符，例如文本区域或移动应用程序的 API。
对于任何残留的动态查询，使用该解释器的特定转义语法转义特殊字符。
注意：表名、列名等 SQL 结构不能转义，因此用户提供的结构名是危险的。这是报告编写软件中的常见问题。
在查询中使用 LIMIT 和其他 SQL 控件以防止在 SQL 注入的情况下大量披露记录。
A04:2021-Insecure Design不安全的设计
2021年的新类别，侧重于与设计缺陷相关的风险，并提倡更多地使用威胁建模、安全设计模式和参考架构。
如何预防
与 AppSec 专业人员建立并使用安全的开发生命周期，以帮助评估和设计与安全和隐私相关的控制
建立和使用安全设计模式库或准备使用组件的铺好的道路
将威胁建模用于关键身份验证、访问控制、业务逻辑和关键流
编写单元和集成测试以验证所有关键流都能抵抗威胁模型
A05:2021-Security Misconfiguration安全配置错误
较前版的第6位相比上升1位。90% 的应用程序都需要经过某种形式的错误配置测试。之前的XML外部实体（XXE）主题现在也属于安全配置错误这个类别。
防御
可重复的强化过程使部署另一个适当锁定的环境变得快速而轻松。开发、QA 和生产环境都应配置相同，在每个环境中使用不同的凭据。这个过程应该是自动化的，以最大限度地减少设置新安全环境所需的工作。
一个没有任何不必要的功能、组件、文档和示例的最小平台。删除或不安装未使用的功能和框架。
作为补丁管理流程的一部分，审查和更新适用于所有安全说明、更新和补丁的配置的任务（请参阅 A06:2021-易受攻击和过时的组件）。查看云存储权限（例如，S3 存储桶权限）。
分段应用程序架构通过分段、容器化或云安全组 (ACL) 在组件或租户之间提供有效且安全的分离。
向客户端发送安全指令，例如安全标头。
验证配置和设置在所有环境中的有效性的自动化过程。
A06:2021-Vulnerable and Outdated Components 易受攻击和过时的组件
之前版本名称是“只用已知漏洞组件”（Known Vulnerabilities），在行业调查中位列第2，并有足够的数据通过数据分析进入Top 10排名。该类别从 2017 年的第9位上升，是一个难以测试和评估风险的已知问题。这是唯一没有任何 CVE 映射到包含的 CWE 的类别，因此以默认的利用和影响权重5.0计入评分标准。
防御
删除未使用的依赖项、不必要的功能、组件、文件和文档。
使用版本、OWASP Dependency Check、retire.js 等工具持续清点客户端和服务器端组件（例如框架、库）及其依赖项的版本。成分。使用软件组合分析工具来自动化该过程。订阅与您使用的组件相关的安全漏洞的电子邮件警报。
仅通过安全链接从官方来源获取组件。首选签名包以减少包含修改后的恶意组件的机会（请参阅 A08:2021-软件和数据完整性故障）。
监视未维护或未为旧版本创建安全补丁的库和组件。如果无法打补丁，请考虑部署虚拟补丁来监控、检测或防止发现的问题。
A07:2021-Identification and Authentication Failures 认证和授权失败
以前称为失效的身份认证（Broken Authentication），从第2位下滑至第7位。该主题仍然是前10的一个组成部分，但标准化框架可用性增加的由一定的帮助。
防御
在可能的情况下，实施多因素身份验证以防止自动凭证填充、暴力破解和被盗凭证重用攻击。
不要使用任何默认凭据进行交付或部署，尤其是对于管理员用户。
实施弱密码检查，例如针对前 10,000 个最差密码列表测试新密码或更改的密码。
将密码长度、复杂性和轮换策略与 NIST 800-63b 的第 5.1.1 节中关于记忆秘密的指南或其他现代的、基于证据的密码策略保持一致。
通过对所有结果使用相同的消息，确保注册、凭据恢复和 API 路径能够抵御帐户枚举攻击。
限制或增加延迟失败的登录尝试。当检测到凭证填充、暴力破解或其他攻击时，记录所有故障并提醒管理员。
使用服务器端、安全、内置的会话管理器，在登录后生成新的高熵随机会话 ID。会话 ID 不应在 URL 中，安全存储，并在注销、空闲和绝对超时后失效。
A08:2021-Software and Data Integrity Failures软件和数据完整性故障
2021 年的一个新主题，着眼于在不验证完整性的情况下，做出与软件更新、关键数据和 CI/CD 管道相关的假设。CVE/CVSS 数据中最高加权影响之一可以对应到A08中的10个CWE。2017年的不安全反序列化（Insecure Deserialization） 现也属于软件和数据完整性故障的一部分。
如何预防
确保未签名或未加密的序列化数据不会在没有某种形式的完整性检查或数字签名的情况下发送到不受信任的客户端，以检测序列化数据的篡改或重放
通过签名或类似机制验证软件或数据来自预期来源
确保库和依赖项（例如 npm 或 Maven）使用受信任的存储库
确保使用软件供应链安全工具（例如 OWASP Dependency Check 或 OWASP CycloneDX）来验证组件不包含已知漏洞
确保您的 CI/CD 管道具有正确的配置和访问控制，以确保流经构建和部署过程的代码的完整性。
A09:2021-Security Logging and Monitoring Failures安全日志记录和监控失败
在此之前被称为日志记录和监控不足（ Insufficient Logging &Monitoring ）。是从行业调查第3位中添加的，从之前的第10位上升。此类别被扩大成为一个能够包含更多故障类型的主题，对于我们进行测试有一定的挑战性，而且在 CVE/CVSS 数据中也没有很好的表现。此类故障会直接影响到可见（visibility）、事件警报（incident alerting）和取证（forensics）的准确性。
防御
确保所有登录、访问控制和服务器端输入验证失败都可以用足够的用户上下文来记录，以识别可疑或恶意帐户，并保留足够的时间以允许延迟取证分析。
确保以日志管理解决方案可以轻松使用的格式生成日志。
确保日志数据编码正确，以防止对日志或监控系统的注入或攻击。
确保高价值交易具有带有完整性控制的审计跟踪，以防止篡改或删除，例如仅追加数据库表或类似的。
DevSecOps 团队应该建立有效的监控和警报，以便快速检测和响应可疑活动。
制定或采用事件响应和恢复计划，例如 NIST 800-61r2 或更高版本。
A10:2021-Server-Side Request Forgery 服务器请求伪造
是从行业调查第1位 中添加的。数据显示发生率相对较低，测试覆盖率高于平均水平，并且利用和影响潜力的评级高于平均水平。这也正表示了行业专业人士在告诉我们，就算目前数据中没有显示出来，服务器请求伪造还是很重要的事实。
防御
从网络层
在单独的网络中分段远程资源访问功能以减少 SSRF 的影响
强制执行“默认拒绝”防火墙策略或网络访问控制规则，以阻止除基本 Intranet 流量之外的所有流量
从应用层：
清理和验证所有客户端提供的输入数据
使用肯定的允许列表强制执行 URL 架构、端口和目标
不要向客户端发送原始响应
禁用 HTTP 重定向
注意URL一致性，以避免DNS重新绑定和“检查时间、使用时间”(TOCTOU) 竞争条件等攻击
不要通过使用拒绝列表或正则表达式来缓解 SSRF。攻击者拥有有效负载列表、工具和技能来绕过拒绝列表。