owasp top 10最新版本（owasp官网）

文章前言

2021年版OWASP Top 10的编制比以往更受数据驱动，但又并非盲目地受数据驱动，我们从公开收集的数据中选定了8个类别，之后又从Top 10社区调查结果中选择了2个高级别的类别，组成了10个类别。我们这样做是为了一个根本原因——通过查看收集到的数据来回顾过去。因为应用安全研究人员寻找新的漏洞和测试它们的新方法需要时间，将这些测试集成到工具和流程中也需要时间，当我们能够可靠地大规模测试弱点时，可能已经过去了很长时间，为了平衡这种观点，我们使用社区调查来向一线应用程序安全和开发专家征求意见，询问他们认为数据可能尚未体现出来的、极其重要的弱点。

差异对比

2021年版Top 10产生了三个新类别，原有四个类别的命名和范围也发生了变化且进行了一些 整合，考虑到应关注根本原因而非症状，我们更改了一些类别的名称(*来源于社区调查结果)

2021版本变化说明：

漏洞类型

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

风险因素

风险概述

从第五位上升到第一位，94%的应用程序都接受了某种形式的针对\\”失效的访问控制\\”测试，该事件的平均发生率为3.81%，该漏洞在提供的数据集中出现漏洞的应用数量最多，总发生漏洞应用数量超过31.8万多次，此类值得注意的常见CWE包括:CWE-200: Exposure of Sensitive Information to an Unauthorized Actor(将敏感信息泄漏给未经授权的参与者)、CWE-201: Exposure of Sensitive Information Through Sent Data(通过发送的数据泄漏敏感信息)、CWE-352: Cross-Site Request Forgery(跨站请求伪造)

风险说明

访问控制强制实施策略使用户无法在其预期权限之外进行操作，失败的访问控制通常会导致未经授权的信息泄露、修改或销毁所有数据、或在用户权限之外执行业务功能，常见的访问控制脆弱点包括：

• 违反最小特权原则或默认拒绝原则，即访问权限应该只授予特定能力、角色或用户，但实际上任何人都可以访问

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

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

• API没有对POST、PUT 和DELETE强制执行访问控制

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

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

• CORS配置错误以致允许未授权或不可信的API访问

• 以未通过身份验证的用户身份强制浏览的通过身份验证时才能看到的页面或作为标准用户身份访问特权页面

防御措施

访问控制只在受信服务器端代码或无服务器API中有效，这样攻击者才无法修改访问控制检查或元数据

• 除公有资源外，默认为\\”拒绝访问\\”

• 使用一次性的访问控制机制，并在整个应用程序中不断重用它们，包括最小化跨源资源共享(CORS)的使用

• 建立访问控制模型以强制执行所有权记录，而不是简单接受用户创建、读取、更新或删除的任何记录

• 特别的业务应用访问限制需求应由领域模型强制执行

• 禁用Web服务器目录列表，并确保文件元数据(例如:git)和备份文件不存在于Web的根目录中

• 在日志中记录失败的访问控制，并在适当时向管理员告警(例如：重复故障)

• 对API和控制器的访问进行速率限制，以最大限度地降低自动化攻击工具带来的危害

• 当用户注销后服务器上的状态会话标识符应失效，无状态的JWT令牌应该是短暂的，以便让攻击者的攻 击机会窗口最小化，对于时间较长的JWT，强烈建议遵循OAuth标准来撤销访问

攻击范例

范例1：应用程序在访问帐户信息的SQL调用中使用 了未经验证的数据

pstmt.setString(1, request.getParameter(\\\"acct\\\")); ResultSet results = pstmt.executeQuery( );

攻击者只需修改浏览器的\\”acct\\”参数即可发送他们想要的任何帐号，如果没有正确验证，攻击者可以访问任何用户帐户

https://example.com/app/accountInfo?acct=not myacct

范例2：攻击者仅强制浏览目标URL，访问管理页面一定需要管理员权限

https://example.com/app/getappInfohttps://example.com/app/admin_getappInfo

如果一个未经身份验证的用户可以访问任何页面，那么这是一个缺陷，而如果一个非管理员权限的用户可以访问管理页面，那么这同样也是一个缺陷

A02：2021-加密机制失效Cryptographic Failures

风险因素

风险概述

上升一位到第二名，以前称为\\”敏感数据泄漏\\”，\\”敏感数据泄漏\\”更像是一种常见的表象问题而不是根本原因，这项风险重点是与加密机制相关的故障(或缺乏加密机制)，这往往会导致敏感数据泄漏，值得注意的常见CWE包括：CWE-259: Use of Hard-coded Password(使用硬编码密码)、CWE-327: Broken or Risky Crypto Algorithm(损坏或有风险的加密算法)、CWE-331 Insufficient Entropy(熵不足)

风险说明

首先要确认对传输中数据和存储数据都有哪些保护需求，例如:密码、信用卡号、医疗记录、个人信息和商业秘密需要额外保护，尤其是在这些数据属于隐私保护法(如:欧盟GDPR)或法规条例(如:金融数据保护标准PCI DSS)适用范围的情况下，对于这些数据要确定：

• 在传输数据过程中是否使用明文传输？这和传输协议有关，例如：HTTP、SMTP、经过TLS升级(如 STARTTLS)的FTP，外部网络流量是有害的，需要验证所有的内部通信，例如：负载平衡、Web服务器或后端系统之间的流量

• 无论是在默认情况下还是在旧的代码中，是否还在使用任何旧的或脆弱的加密算法或传输协议？

• 是否使用默认加密密钥、生成或重复使用脆弱的加密密钥，或者是否缺少适当的密钥管理或密钥回转？加密密钥是否已经提交到源代码存储库？

• 是否未执行强制加密，例如:是否缺少安全相关的HTTP(浏览器)指令或标头？

• 接收到的服务器证书和信任链是否经过正确验证？

• 初始化向量是否忽略，重用或生成的密码操作模式是否不够安全？ 是否正在使用不安全的操作模式，例如:欧洲央行正在使用的操作模式？当认证加密更合适时是否使用加密？

• 在缺乏密码基密钥派生函数的情况下，是否将密码用作加密密钥？

• 随机性是否用于并非旨在满足加密要求的加密目的？ 即使选择了正确的函数，它是否需要由开发人员播种， 如果不需要，开发人员是否用缺乏足够熵/不可预测性的种子覆盖了内置的强大播种功能？

• 是否使用过时的散列函数，例如:MD5或SHA1，或者在散列函数需要加密时使用非加密散列函数？

• 是否在使用已弃用的加密填充方法，例如:PCKS number 1 v1.5？

• 加密的错误消息或侧信道信息是否可以利用，例如使用填充预言机攻击的形式？

防御措施

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

• 对于没有必要存储的敏感数据，应当尽快清除，或者通过PCI DSS标记化或拦截，未存储的数据不能窃取

• 确保加密存储的所有敏感数据

• 确保使用了最新的、强大的标准算法、协议和密钥，并且密钥管理到位

• 确保加密传输过程中的数据，如使用安全协议(例如:具有前向保密(FS)密码的TLS、服务器的密码优先级和安全参数)，确保强制执行数据加密，如使用HTTP 严格安全传输协议(HSTS)等指令

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

• 根据数据分类应用实施所需的安全控制

• 不要使用FTP和SMTP等传统协议来传输敏感数据

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

• 必须选择适合操作模式的初始化向量，对于大多数模式，可以使用CSPRNG(密码安全伪随机数生成器)，对于需要随机数的模式，则初始化向量(IV)不需要使用CSPRNG，在所有情况下，对于一个固定密钥，永远不应该使用两次IV

• 始终使用经过验证的加密，而不仅仅是加密

• 密钥应以加密方式随机生成并作为字节数组存储在内存中，如果使用密码，则必须通过适当的密码基密钥 派生函数将其转换为密钥

• 确保在适当的地方使用加密随机性，并且没有以可预测的方式或低熵进行播种，大多数现代API不需要开 发人员为CSPRNG设置种子以获得安全性

• 避免使用的已废弃的加密函数和填充方案，例如：MD5、SHA1、PKCS number 1 v1.5

• 单独验证每个安全配置项的有效性

攻击范例

范例1：一个应用程序使用自动化的数据加密系统加密存储中数据库中的信用卡号，但是这些数据在检索时会自动解密， 这就使得SQL注入漏洞以明文形式获得信用卡号

范例2：一个网站对所有网页没有使用或对强制使用TLS 或者使用弱加密，攻击者经过监测网络流量(例如:在不安全的无线网络中)将网络连接从HTTPS降级到HTTP，就可以拦截请求并窃取用户会话cookie，之后攻击者重放这个cookie并劫持用户的(经过身份验证的)会话， 访问或修改用户的私人数据，除此之外，攻击者还可以更改所有传输过程中的数据，例如：汇 款的接收人

范例3：密码数据库使用未加盐或弱:哈希算法来存储每个人的密码，一个文件上传漏洞允许攻击者获取密码数据库，所有未加盐哈希的密码都可以 通过预先计算的哈希值彩虹表破解，由简单或快速散列函数生成的加盐哈希也可能通过GPU破解

A03：2021-注入 Injection

风险因素

风险概述

注入降至第三，94%的统计应用针对某种形式的注入进行了测试，最大发生率为19%，平均发生率为3%，共计发生了27.4万次，值得注意的常见弱点枚举(CWE)包括CWE-79： Cross-site Scripting(跨站点脚本)、CWE-89：SQL Injection(SQL注入)和CWE-73：External Control of File Name or Path(文件名或路径的外部控制)

风险说明

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

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

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

• 恶意数据在对象关系映射(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注入

• 使用肯定(positive)或\\”白名单\\”服务器端输入验证，这并不是一种完美的防御，因为许多应用 程序需要特殊字符，例如:移动应用程序中的文本区域或API

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

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

攻击范例

范例1：应用程序在构造以下易受攻击的:SQL调用时使用不受信任的数据： 

String query = \\\"SELECT \\\\* FROM accounts WHERE custID=\\\'\\\" + request.getParameter(\\\"id\\\") + \\\"\\\'\\\";

范例2：:类似地应用程序对框架的盲目信任可能会导致易受攻击的查询(例如:Hibernate查询语言(HQL)）

Query HQLQuery = session.createQuery(\\\"FROM accounts WHERE custID=\\\'\\\" + request.getParameter(\\\"id\\\") + \\\"\\\'\\\");

在这两种情况下攻击者都会修改浏览器中的\\”id\\”参数值， 以发送\\’或\\’1\\’=\\’1，例如

http://example.com/app/accountView?id=\\\' or \\\'1\\\'=\\\'1

这将更改两个查询的含义，以返回accounts表中的所有记录，更危险的攻击可能会修改或删除数据，甚至调用存储过程

A04：2021-不安全设计 Insecure Design

风险因素

风险概述

2021年版的一个新类别，侧重于与设计和体系结构缺陷相关的风险，呼吁更多地使用威胁建模、 安全设计模式和参考体系结构，作为一个应用安全技术社区，我们需要超越软件开发过程编码空间中的\\”左移\\”，转向对设计安全原则至关重要的预编码活动，值得注意的常见弱点枚举(CWE)包括CWE209：Generation of Error Message Containing Sensitive Information(生成包含敏感信息的错误消息)、CWE-256：Unprotected Storage of Credentials(凭证的未保护存储)、CWE-501：Trust Boundary Violation(信任边界冲突)和CWE-522：Insufficiently Protected Credentials(凭证保护不足)

风险说明

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

A、安全设计 

安全设计是一种文化和方法，它不断评估威胁并确保代码经过稳健的设计和测试，以防止已知的攻击方法。威胁建模应整合到细化会议(或类似活动)中，查看数据流和访问控制或其他安全控制中的更改，在用户故事开发中确定正确的流程和故障状态，确保责任方和受影响方充分理解并同意这些状态，分析预期和故障流的假设和条件，确保其仍然准确和可取，确定如何验证正确行为所需的假设和实施条件，确保结果记录在用户故事中，从错误中吸取教训，并提供积极的激励以促进改进，安全设计既不是附加 组件也不是可以添加到软件中的工具

B、需求和资源管理 

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

C、安全开发生命周期 

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

预防措施

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

• 建立并使用安全设计模式的库，或使用AppSec规划中现有的要素

• 对关键身份验证、访问控制、业务逻辑和密钥流使用威胁建模

• 将安全语言和安全控制集成到用户故事中

• 在应用程序的每一层(从前端到后端)集成合理性检查

• 编写单元和集成测试，以验证所有关键流是否能够抵抗威胁模型，为应用程序的每一层编译正确用 例和误用案例

• 根据暴露和保护需要，对系统层和网络层进行分层

• 通过设计在所有层中严格隔离租户

• 限制用户或服务的资源消耗

攻击范例

范例1：身份凭证恢复工作流可能包括NIST 800-63b 、 OWASP ASVS和OWASP Top 10中已禁止的\\”问题和答案\\”功能，\\”问题和答案\\”不能作为可信的证据来证明身份，因为不止一个人知道答案，这就是为什么它们被禁止的原因，应删除此类代码，并用更安全的设计替换

范例2： 一家连锁电影院允许团体预订折扣，支持最多15名观众而不要押金。攻击者可以对这种流量进行威胁建模，并测试他们是否可以在几个请求中同时预订600个座位和所有电影院，从而造成巨大的收入损失

范例3：零售连锁店的电子商务网站没有针对黄牛党运行的机器人的保护，黄牛党购买高端显卡然后在拍卖网站上销售，这给显卡制造商和零售连锁店老板创造了糟糕的形象，并与那些无法以任何价格获得这些卡的爱好者产生了持久的伤害，适当的反机器人设计和域逻辑规则， 例如在可用的几秒钟内进行的购买可能会被识别为不可信的购买并拒绝此类交易

A05：2021-安全配置错误Security Misconfiguration

风险因素

风险概述

从上一版本的第六名提升，90%的调查应用都进行了某种形式的配置错误测试，平均发生率为4%，并且在此风险类别的CWE出现了超过20.8万次，随着当今软件正转向高度可配置，看到这一类别上升也就不足为奇了，需要注意的是CWE包括： CWE-16 Configuration(配置)和CWE-611 Improper Restriction of XML External Entity Reference(XML外部实体引用的不当限制)

风险说明

您的应用程序可能受到攻击，如果应用程序是：

• 应用程序栈的任何部分缺少适当的安全加固或者云服务的权限配置错误

• 应用程序启用或安装了不必要的功能(例如：不必要的端口、服务、网页、帐户或权限)

• 默认帐户和密码仍然可用且没有更改

• 错误处理机制向用户纰漏堆栈信息或其他大量错误信息

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

• 应用程序服务器、应用程序框架(如：Struts、Spring、ASP.NET)、库文件、数据库等没有进 行安全配置

• 服务器不发送安全标头或指令或未被设定安全参数

• 您的应用软件已过期或易受攻击(参见\\”A6:2021-脆弱和过时的组件\\”）

• 缺少一个体系的、可重复的应用程序安全配置过程，系统将处于高风险中:

预防措施

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

• 可以快速且易于部署在另一个锁定环境的可重复的加固过程，开发、质量保证和生产环境都应 该进行相同配置，并且在每个环境中使用不同的密码，这个过程应该是自动化的，以尽量减少安装一个新安全环境的耗费

• 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例，移除或不安装不适用的功能和框架

• 检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分(参见\\”A6:2021-脆弱和过时的组件\\”)，在检查过程中应特别注意云存储权限(如:S3桶权限)

• 一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括:分段、容器化和云安全组(ACL)

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

• 一个能够验证所有环境中进行了正确的安全配置和设置的自动化过程

攻击范例

范例1：应用程序服务器附带了未从产品服务器中删除的应用程序样例，这些样例应用程序具有已知的安全漏洞，攻击者利用这些漏洞来攻击服务器，假设其中一个应用程序是管理员控制台，并且没有更改默认账户，攻击者就可以通过默认密码登录，从而接管服务器

范例2：目录列表在服务器端未被禁用，攻击者发现他们很容易就能列出目录列表，攻击者找到并下载所有已编译的Java类，他们通过反编译来查看代码，然后攻击者在应用程序中找到一个严重的访问控制漏洞

范例3：应用程序服务器配置允许将详细的错误信息(如:堆栈信息)返回给用户，这可能会暴露敏感信息或潜在的漏洞，例如:已知含有漏洞的组件的版本信息

范例4：云服务提供商向其他CSP用户提供默认的网络共享权限，这允许攻击者访问存储在云端的敏感数据

A06：2021-自带缺陷和过时的组件 Vulnerable and Outdated Components

风险因素

风险概述

它在Top 10社区调查中排名第二，也有足够的数据让它进入前十，不安全的组件是我们努力测 试和评估风险的已知问题，并且它是在CWE中唯一没有任何CVE对应的类别，因此使用默认的利用/影响加权值为5.0，值得注意的是CWE包括：CWE-1104 Use of Unmaintained Third-Party Components(使用未维护第三方组件)，以及2013年和2017年Top 10中关于此问题的两个CWE

风险说明

如果满足下面的某个条件，那么您的应用就易受此类攻击：

• 如果您不知道所有使用的组件版本信息(包括:服务端和客户端)，这包括了直接使用的组件或间接依赖的组件

• 如果软件易受攻击，不再支持或者过时，包括：系统、Web服务器、应用程序服务器、数据库 管理系统(DBMS)、应用程序、API和所有的组件、运行环境和库

• 如果您没有定期做漏洞扫描和订阅使用组件的安全公告

• 如果您不基于风险及时修复或升级底层平台、框架和依赖库，那么很可能发生这种情况：根据变更控制， 每月或每季度进行升级，这使得组织在这段时间内会受到已修复但未修补的漏洞的威胁

• 如果软件工程师没有对更新的、升级的或打过补丁的组件进行兼容性测试

• 如果您没有对组件进行安全配置(参见\\”A05:2021–安全配置错误\\”)

预防措施

应制定一个补丁管理流程：

• 移除不使用的依赖、不需要的功能、组件、文件和文档

• 利用如Versions、OWASP Dependency Check、Retire.js等工具来持续的记录客户端和服务器端以及它们的依赖库的版本信息，持续监控如CVE和NVD等是否发布已使用组件的漏洞信息，可以使用软件分析工具来自动完成此功能，订阅关于使用组件安全漏洞的警告邮件

• 仅从官方渠道安全的获取组件并使用签名机制来降低组件被篡改或加入恶意漏洞的风险(参见\\”A08:2021-软件和数据完整性故障”)

• 监控那些不再维护或者不发布安全补丁的库和组件，如果不能打补丁可以考虑部署虚拟补丁来监控、检测或保护

攻击范例

范例1：通常组件都是以与应用相同的权限运行的，这使得组件里的缺陷可能导致各式各样的问题，这些缺陷可能是偶然的(例如:编码错误)，也可能是蓄意的(例如:组件里的后门)，下面是一些已被利用的漏洞： 

• CVE-2017-5638：一个Struts2远程执行漏洞，可在服务端远程执行代码并已造成巨大的影响

• 虽然物联网(IoT)设备一般难以通过打补丁来修复，但对它打补丁非常重要(例如:医疗设备)

• 有些自动化工具能帮助攻击者发现未打补丁的或配置不正确的系统，例如：Shodan IOT搜索引擎能帮助您发现从2014年4月至今仍存在心脏出血漏洞的设备

A07：2021-身份识别和身份验证错误 Identification and Authentication Failures

风险因素

风险概述

很早之前被称之为\\”无效的身份认证\\”，此类别从第二名下滑，现在包含了与身份识别失效相关的CWE，如知名的\\”CWE-297: Improper Validation of Certificate with Host Mismatch(与不匹配的服务端进行不适当的凭证确认)\\”, \\”CWE-287: Improper Authentication(不适当的认证)\\”, \\”CWE-384: Session Fixation(会话固定攻击)\\”

风险说明

• 允许像是攻击者已经拥有有效用户名称和密码列表的撞库自动化攻击

• 允许暴力或其他自动化攻击

• 允许预设、脆弱、常见的密码，像是\\”Password1\\”或\\”admin/admin\\”

• 使用脆弱或无效的认证资讯回复或忘记密码的流程，如不安全的\\”知识相关问答\\”

• 使用明码、被加密的或使用较脆弱杂凑法的密码(参考A3: 2017-敏感性资料泄漏)，(TODO)https://github.com/OWASP/Top10/issues/553

• 不具有或是无效的多因素认证

• 于URL中泄漏会话(session) ID(如URL重写)

• 成功登入后没有轮换会话(session) ID

• 没有正确的注销会话(session)ID，用户的会话(session)或认证tokens(主要是单一登入(SSO)token)没有在登出时或一段时间没活动时被适当的注销

预防措施

• 在可能的情况下，实施多因素认证来防止自动化撞库攻击、暴力破解、以及遭窃认证资讯被重复 利用的攻击

• 要交付或部署任何预设的认证凭证，特别是管理者

• 实施弱密码的检查，如测试新设定或变更的密码是否存在于前10000个最差密码清单

• 将密码长度、复杂度和轮换政策与NIST 800-63b文件\\”第5.1.1节-被记忆的秘密或其他现代基于证据的密码政策\\”的内容保持一致

• 对所有结果使用相同的讯息回应，确保注册、认证凭据回复以及API路径能够抵御帐号枚举攻击

• 限制或增加登入失败尝试的延迟，记录所有失败并于侦测到撞库、暴力破解或其他攻击时发出告警

• 使用服器端、安全的内建会话管理器，在登入后产生有高熵值的新随机会话ID，会话ID不应出现在URL中，必须被安全的储存，并且在登出后、闲置、超时后被注销

攻击范例

情境1: 使用已知列表密码的撞库攻击是一种常见的攻击方式，假设应用沒有实施自动化威胁或撞库攻击的保护，在这种情況下应用会被利用为密码预报的工具来判断认证凭据是否有效

情境2: 大多数身份验证攻击都是由于密码作为单一因素持续使用而发生的，一旦考虑最佳实践、 密码轮换和复杂性要求鼓励用户使用和重用弱密码，建议组织按照NIST 800-63停止这些做法并使用多因素认证

情境3: 应用会话超时设置错误，一个用户使用公用电脑来访问应用时，用户没有选择\\”登出\\”而是简单的关闭浏览器标签页就离开，一小时后一个攻击者使用同一个浏览器，而那个应用仍处于前面用户认证通过的状态

A08：2021-软件和数据完整性故障 Software and Data Integrity Failures

风险因素

风险概述

2021年版本的一个新类别，聚焦于在未验证完整性的情况下做出与软件更新、关键数据和CI/CD管道相关的假设，这是来自漏洞披露/通用漏洞评估系统(CVE/CVSS)数据的最高权重影响之一，值得注意的是CWE包括：CWE-829：Inclusion of Functionality from Untrusted Control Sphere(包含来自不受信任控制领域的功能)，CWE-494：Download of Code Without Integrity Check(不进行完整性检查的代码下载)和CWE-502：Deserialization of Untrusted Data(不可信数据的反序列化)

风险说明

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

预防措施

• 使用数字签名或类似机制来验证软件或数据来自预期来源且未被修改

• 确保库和依赖项目，例如:npm或Maven，正在使用受信任的存储库，如果您的风险较高，请考虑托管一个经过审核的、内部已知合格的存储库

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

• 确保对代码和配置更改进行审核，以最大限度地减少恶意代码或配置引入软件管道的可能性

• 确保您的CI/CD管道具有适当的隔离、配置和访问控制，以确保代码在构建和部署过程中的完整性

• 确保通过特定形式的完整性检查或数字签名来检测序列化数据是否存在篡改或重播，所有未签名或 未加密的序列化数据不会发送到不受信任的客户端

攻击范例

范例1：无需签名既可更新许多家庭路由器、机顶盒、设备固件和其他设备通过没有签 名的固件进行更新，未签名固件是越来越多的攻击者的目标， 预计情况只会变得更糟，这是 一个主要问题，因为很多时候除了在未来的版本中修复和等待以前的版本过期之外，没有任何其他补救措施

范例2：SolarWinds恶意更新众所周知一种新的攻击机制， 即最近值得注意的SolarWinds Orion攻击，开发该软件的公司具有安全的构建和更新完整性流程，尽管如此，这些都能够被颠覆，几个月来，该公司向18,000多个组织分发了一个高度针对性的恶意更新，其中大约100个组织受到影响，这是历史上同类性质中影响最深远和最严重的违 规行为之一

范例3：不安全的反序列化一个React应用程序调用一组Spring Boot微服务，作为函数程序员，他们试图确保他们的代码是不可变的，他们提出的解决方案是将用户状态序列化，并在每个请求中来回传递，攻击者注意到\\”rO0\\”Java 对象签名(在base64中)，并使用Java Serial Killer工具在 应用服务器上获取远程代码执行权

A09：2021-安全日志和监控故障 Security Logging and Monitoring Failures

风险因素

风险概述

安全日志和监控故障来自于Top 10的社区调查(排名第3位)，比2017年OWASP Top 10社区调查时的第10位略有上升，日志记录和监控是一项具有挑战性的测试，通常涉及访谈或询问渗透测试期间是否检测到攻击，这个类别的CVE/CVSS数据不多，但检测和应对违规行为是至关重要的，同时它对问责制、可见性、事件告警和取证仍有很大的影响，这个类别除了CWE-778 Insufficient Logging(日志记录不足)外，还包括CWE-117 Improper Output Neutralization for Logs(日志输出不当)，CWE-223 Omission of Security-relevant Information(安全事件信息漏报)，以及CWE-532 Insertion of Sensitive Information into Log File(在日志文件中包含敏感信息)

风险说明

2021年版OWASP Top 10中，该类别是为了帮助检测、升级和应对活跃的违规行为，如果不进行日志记录和监测就无法发现违规行为，任何时候都会发生日志记录、检测、监视和主动响应不足的情况

• 需要审计的事件，例如：登录、失败的登录和高价值交易，但未记录

• 警告和错误未生成日志或日志记录不充分或日志消息不清晰

• 应用程序和 API的日志未进行安全可疑活动的监控

• 日志只存储在本地

• 适当的警报阈值和响应升级过程不到位或无效

• 渗透测试和动态应用安全测试(DAST)工具(例如：OWASP ZAP)的扫描没有触发警报

• 应用无法实时或接近实时地检测、升级或或对主动攻击发出警报

• 如果让用户或攻击者看到日志和警报事件，您就容易受到信息泄露的攻击(查看\\”A01:2021-失效的访问控制\\”)

预防措施

开发人员应根据应用的风险，实施以下部分或全部控制：

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

• 确保日志是日志管理解决方案以方便使用的格式生成的

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

• 确保高价值交易有完整性控制的审计跟踪，以防止篡改或删除，例如：只附加数据库表或类似的内容

• DevSecOps团队应该建立有效的监控和警报，以便发现可疑的活动并迅速做出反应

• 建立或采用事故应对和恢复计划，例如：美国国家标准技术研究所(NIST)800-61r2或更高版本

• 有一些商业和开源的应用程序保护框架，如：OWASP ModSecurity核心规则集，以及开源的日志相关软件，如：Elasticsearch、Logstash、Kibana(ELK)，具有自定义仪表盘和告警功能

攻击范例

范例1：一家儿童健康计划供应商的 网站运营者由于缺乏安全监控和记录而无法发现漏洞，一个外部团体告知儿童健康 计划供应商，某恶意攻击者已经获取并修改了超过350万 儿童的数千份敏感健康记录， 事后审查发现网站开发人员没有修复重大漏洞，由于没有对系统进行日志记录或监控，因此数据泄露可能自2013年以来一直在进行，时间超过7年

范例2：印度一家大型航空公司发生数据泄露事件，涉及数百万乘客十多年的个人信息，包括护照和信用卡信息，数据泄露发生在一家第三方云托管服务提供商，该提供商在一段时间后通知了航空公司此次泄露事件

范例3：欧洲一家大型航空公司遭遇一起可报告的GDPR违规事件，据报道攻击者利用支付应用程序的安全漏洞，获取了超过40万客户的支付记录，从而导致了此次攻击，该航空公司因此被隐私监管机构处以2000万英镑的罚款

A10：2021-服务端请求伪造 Server-Side Request Forgery

风险因素

风险概述

这个类别是从Top 10社区调查(排名第1位)中新添加的，数据显示该类别安全事件发生率相对较低，测试覆盖率高于平均水平，平均漏洞利用脚本数和影响潜力等级高于平均水平，因为新类别可能是单一或小型集群的CWE，为了引起关注和认识希望这个类别能受到关注并且在未来的版本可以推出一个更大的类别

风险说明

Web应用在获取远程资源时没有验证用户提供的URL就会出现SSRF缺陷，它允许攻击者强制应用程序发送一个精心构建的请求到一个意外目的地，即使是在有防火墙、VPN或其他类型的网络访问控制列表(ACL)保护的情况下

随着现代Web应用为终端用户提供便利的功能，获取URL成为一种常见的场景，因此SSRF安全攻击事件也在不断增加，此外由于云服务和架构的复杂性，SSRF的严重性也越来越高

预防措施

开发者可以通过实现以下部分或全部防御手段，纵深防御来阻止SSRF: 

A、网络层防御建议：

在隔离的网络中设置多个远程资源访问功能的网段以减少SSRF的影响

执行\\”默认拒绝\\”防火墙策略或网络访问控制规则以阻止除必要的内部网通信外的所有通信

B、应用层防御建议：

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

• 使用白名单允许列表允许列表执行URL统一资源标志符、端口和目标

• 不要给客户端发送原始的回复

• 禁用HTTP重定向

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

• 不要通过使用黑名单拒绝列表或正则表达式来缓解SSRF，攻击者拥有有效载荷列表、工具和绕过 拒绝列表的技能

C、需额外考虑的措施

• 不要在前端系统上部署其他与安全相关的服务(例如：OpenID)，控制这些系统上的本地流量(例如:localhost)

• 对于专用和可管理的前端用户可以在独立系统上使用网络加密(例如：vpn）来满足非常高的安全 保护需求

攻击范例

范例1：内部服务器端口扫描如果网络架构未进行网络隔离，攻击者可以访 问并绘制出内部网络地图并根据连接结果或SSRF有效载荷连接的运行时间和拒绝时间判断内部服务器端口是打开还是关闭

范例2：敏感数据泄露攻击者可以访问本地文件或内部服务以获得敏感信息，例如： file:///etc/passwd http://localhost:280 17/

范例3：访问云服务的元数据存储大多数云服务提供商都有元数据存储，比如：通过http://169.254.169.254/访问，攻击者可以通过读取元数据来获取敏感信息

范例4：危害内部服务攻击者可以滥用内部服务进行进一步的攻击，比如：远程代码执行(RCE)或者拒绝服务攻击(DoS)