【OWASP Top 10】2021版

【OWASP Top 10】2021版

A01：失效的访问控制（Broken Access Control）

失效的访问控制（Broken Access Control）从第五位上升到了第一位。94%的应用程序都经过了某种形式的访问控制失效测试。映射到访问控制失效的34个CWE在应用程序中的出现频率比其他任何类别都要多。

从第五位上升称为Web应用程序安全风险最严重的类别，常见的CWE包括：将敏感信息泄露给未经授权的参与者、通过发送的数据泄露敏感信息、跨站请求伪造（csrf）

风险说明：
​ 访问强制实施策略，使用户无法在其预期权限之外操作。失败的访问控制通常导致未经授权的信息泄露，修改或者销毁所有数据，或在用户权限之外执行业务功能。
常见的访问控制脆弱点：
违法最小权限原则或默认拒绝原则，即访问权限应只授予特定能力、角色或用户，但实际上任何人都可以访问
通过修改URL（参数修改或强制浏览），内部应用程序状态或者HTML页面，或者使用修改API请求的攻击工具绕过访问控制检查
通过提供唯一的标识符允许查看或编辑他人账户
API没有对POST、PUT和DELETE强制执行访问控制
特权提升，在未登陆的情况下假扮用户或以用户身份登入时充当管理员
…

预防措施
开发人员和QA人员应进行访问控制功能的单元测试和集成测试
访问控制只在受信服务器端代码或者无服务器API中有效，这样攻击者才无法修改访问控制检查或元数据
除公有资源外，默认访问拒绝
使用一次性的访问控制机制，并在整个应用程序中不断重用它们，包括最小化跨资源共享（CORS）的使用
建立访问控制模型以强制执行所有权记录，而不是简单接受用户创建、读取、更新或删除的任何记录
在日志中记录失败的访问控制，并在适当时向管理员告警（例如：重复故障）
…

A02：加密机制失效（Cryptographic Failure）

2021年，加密机制失效（Cryptographic Failure）——此前名为“敏感数据泄露”（Sensitive Data Exposure），这一名称只是描述了广泛的症状而非根本原因——上移到了榜单第二位。此处需要重新关注与密码学相关的故障，这些故障通常会导致敏感数据暴露或系统受损。

上升一位到第二位，以前称为“敏感数据泄露”。敏感数据泄露更像是一种常见的表象问题而不是根本原因，这项风险重点是与加密机制相关的故障（或缺乏加密机制）

风险说明
​ 首先要确认：对传输中的数据和存储数据都有哪些保护需求。例如：密码、信用卡号、医疗记录、个人信息和商业秘密需要额外保护。

对于数据，要确认：
在传输数据过程中是否使用明文传输？这和传输协议有关：HTTP、SMTP、经过TLS升级的FTP。外部网络流量是有害的，需要验证所有的内部通信
无论是在默认情况还是在旧的代码中，是否还在使用任何旧或者脆弱的加密算法或传输协议
是否默认使用加密密钥、生成或重复使用脆弱的加密密钥，或者是否缺少适当的密钥管理或密钥回转
接收到的服务器证书和信任链是否经过正确验证
…

预防措施
对应用程序处理、存储或者传输的数据分类，并根据相关要求确认哪些数据敏感
对于没有必要存储的敏感数据，应当尽快清除
确保加密存储所有的敏感数据
确保使用了最新的，强大的标准算法、协议和密钥，并且密钥管理到位
禁用缓存对包含敏感数据的响应
不要使用传统协议HTTP、FTP等来传输敏感数据

A03：注入（Injection）

2021年，注入（Injection）下滑到第三位。94%的应用程序都测试了某种形式的注入，注入类别中如今包括跨站脚本。映射到该类别的33个CWE在应用程序中出现次数第二多。

注入降至第三，常见的CWE：跨站点脚本、SQL注入、文件名或路径的外部控制

风险说明
源代码审查是检查应用程序是否易受注入攻击的最佳方法。
强烈鼓励针对所有参数、标题、URL、cookie、JSON、SOAP和XML数据输入的自动测试

风险产生情况：
应用程序不会验证、过滤或清洗用户提供的数据
动态查询或无上下文感知转义的非参数化调用之间在解释器中使用
恶意数据被直接使用或连接。SQL或命令包含动态查询、命令或存储过程中的结构和恶意数据

预防措施
防止注入需要将数据与命令和查询分开：
推荐的选择是使用安全的API
使用肯定或者白名单服务器端输入验证
对于任何残余的动态查询，使用该解释器的特定转义语法转义特殊字符
在查询中使用LIMIT和其他SQL控件，以防止在SQL注入的情况下大量披露记录

A04：不安全的设计（Insecure Design）

不安全的设计（Insecure Design）是2021年出现的新类别，并且一出场就高居第四位。此处需要重点关注与设计缺陷相关的风险。如果我们真的想作为一个行业“左移”，就需要更多地使用威胁建模、安全设计模式和原则以及参考架构。

这是2021的一个新类别，侧重于设计和体系结构缺陷相关的风险，呼吁更多的使用威胁建模、安全设计模式和参考体系结构

风险说明
​ 不安全设计和不安全实现直接存在差异，我们区别设计缺陷和实现缺陷是有原因的，安全设计仍然可能存在实现缺陷，从而导致可能被利用的漏洞。

一个不安全设计不能通过一个完美的实现来修复。
●需求和资源管理
收集应用程序的业务需求并与业务部门协商，包括所有数据资产和预期业务逻辑的机密性、完整性、可用性和真实性方面的保护需求。考虑应用程序的公开程度，以及是否需要租户隔离（(除访问控制外)。编制技术要求，包括功能性和非功能性安全要求。计划和协商所有设计、建造、测试和运营的预算，包括安全活动。
●安全设计
安全设计是一种文化和方法，它不断评估威胁，并确保代码经过稳健的设计和测试，以防止已知的攻击方法。威胁建模应整合到细化会议（或类似活动)中;查看数据流和访问控制或其他安全控制中的更改。在用户故事开发中，确定正确的流程和故障状态，确保责任方和受影响方充分理解并同意这些状态。分析预期和故障流的假设和条件，确保其仍然准确和可取。确定如何验证正确行为所需的假设和实施条件。确保结果记录在用户故事中。从错误中吸取教训，并提供积极的激励以促进改进。安全设计既不是附加组件，也不是可以添加到软件中的工具。
●安全开发生命周期
安全的软件需要安全开发生命周期、某种形式的安全设计模式、AppSec规划方法、安全的组件库、工具和威胁建模。在整个项目和软件维护过程中，在软件项目开始时联系您的安全专家。考虑利用OWASP软件保证成熟度模型(SAMM)来帮助构建您的安全软件开发工作。

预防措施
与应用安全专业人员建立并使用安全的开发生命周期，以帮助评估和设计与安全和隐私相关的控制
限制用户或服务的资源消耗
通过设计咋所有层中严格隔离租户
根据暴露和保护需要，对系统层和网络层进行分层

A05：安全配置错误（Security Misconfiguration）

2021年，安全配置错误（Security Misconfiguration）从上一版的第6位上升到了第5位。90%的应用程序都经过了某种形式的错误配置测试，随着转向高度可配置软件的趋势不可逆，看到这一类别排名上升也就不足为奇了。此前版本的XML外部实体注入（XXE）类别现在也被合并为该类别的一部分。

从上一版的第六名提升，90%都进行了某种形式的配置错误测试。

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

你的应用程序可能受到攻击，如果应用程序是：
应用程序栈的任何部分缺少适当的安全加固，或者云服务的权限配置错误
应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、账户或权限）
默认账户和密码仍然可用且没有更改
错误处理机制向用户纰漏堆栈信息或其他大量错误信息
对于升级的系统，最新的安全特性被禁用或未安全配置
应用程序服务器、应用程序框架（如：Struts、Spring、ASP。net）、库文件、数据库等没有进行安全配置
…

预防措施
应实施安全的安装过程，包括
一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的消耗
搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和实例。移除或不安装不适用的功能和框架
检查和修复安全配置来适应最新的安全说明、更新和补丁，并将作为更新管理过程的一部分
一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构
…

A06：自带缺陷和过时的组件（Vulnerable and Outdated Component）

2021年，自带缺陷和过时的组件（Vulnerable and Outdated Component）——此前名为“使用具有已知漏洞的组件”（Using Components with Known Vulnerabilities）——也从第6位一跃进入第6位。该类别是唯一一个没有任何CVE映射到所含CWE的类别，因此默认的漏洞与影响权重计5.0分。

不安全的组件是我们努力测试和评估风险的已知问题

风险说明
​ 如满足下面的某个条件，那么你的应用就易受到此类攻击：
你不知道所使用的组件版本信息（包括：服务端和客户端）。这包括了直接使用的组件或间接依赖的组件
软件易受攻击，不再支持或过时。
没有定期做漏洞扫描和订阅使用组件的安全公告
软件工程师没有对更新的、升级的或者打过补丁的组件进行兼容性测试
没有对组件进行安全配置
预防措施
每个组织都应该制定相应的计划，对整个软件生命周期进行监控、评审、升级或更改配置

制定一个补丁管理流程：
移除不使用的依赖、不需要的功能、组件、文件和文档
仅从官方渠道安全的获取组件，并使用前面机制来降低组件被篡改或加入恶意漏洞的风险
监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁，就考虑部署虚拟补丁来监控、检查或保护

A07：身份识别和身份验证错误（Identification and Authentication Failure）

2021年，身份识别和身份验证错误（Identification and Authentication Failure）——此前称为“身份验证失效”（Broken Authentication）——排名从此前的第2位降到了第7位，而且该类别目前包含更多与识别失败相关的CWE。虽然该类别仍然位列Top 10榜单，但标准化框架的可用性增加似乎有助于解决这一问题。

之前称为无效的身份认证，此类别从第二名下滑，现在包含了与身份识别失效相关的CWE

风险说明
确认用户的身分、认证、会话(session)管理对于防止与认证相关的攻击至关重要，如果应用程式存在以下情况，则可能有认证的漏洞:
允许像是攻击者已经拥有有效用户名称和密码列表的撞库自动化攻击。
允许暴力或其他自动化攻击。
允许预设、脆弱、常见的密码，像是"Password1"或"admin/admin"。
使用脆弱或无效的认证资讯回复或忘记密码的流程，如不安全的"知识相关问答"。
将密码使用明码、加密或较脆弱杂凑法的方式储存(参考 A3: 2017-敏感性资料泄漏)。
不具有或是无效的多因素认证。
于 URL 中泄漏会话(session) ID(如 URL 重写)。
成功登入后没有轮换会话(session) ID。
没有正确的注销会话(session) ID。用户的会话(session)或认证 tokens(主要是单一登入(SSO)token) 没有在登出时或一段时间没活动时被适当的注销。
…
攻击情境范例
情境 1:使用已知列表密码的撞库攻击是一种常见的攻击方式，假设应用程式没有实施自动化威胁或撞库攻击的保护，在这种情况下，应用程式会被利用为密码预报的工具来判断认证资讯是否有效。
情境 2:大多数的认证攻击是因为持续的使用密码作为唯一因素，最佳实践、密码轮换、以及复杂度的要求会鼓励用户使用和重复使用脆弱的密码。建议组织按照 NIST 800-63 停止这些做法并使用多因素认证。
情境 3:应用程式的会话超时没有被设定正确。一个用户使用公用电脑来存取应用程式时，用户没有选择"登出"而是简单的关闭浏览器分页就离开，此时一个攻击者在一小时后使用同一个浏览器，前一个用户仍然处于通过认证的状态。

预防措施
实施弱密码的检查，如测试新设定或变更的密码是否存在于前10000个最差密码清单
在可能的情况下，实施多因素认证来防止自动化撞库攻击，暴力破解，以及遭窃认证咨询被重复利用的攻击
不要交付或部署任何预设的认证凭证，特别是管理者
限制或增加登入失败尝试的延迟

A08：软件和数据完整性故障（Software and Data Integrity Failure）

软件和数据完整性故障（Software and Data Integrity Failure）是2021年新增的一个类别，主要关注缺乏完整性验证情况下做出与软件更新、关键数据和持续集成/持续交付（CI/CD）流水线相关的各种假设。CVE/CVSS数据最高加权影响之一映射到该类别中的10个CWE。此前版本中的“不安全反序列化”（Insecure Deserialization）类别如今也被归入这一更大类别。

弱点描述
程式码或基础架构未能保护软体及资料之完整性受到破坏。举例来说，物件或资料经编码或序列化到一个对攻击者可读写之结构中将导致不安全的反序列化。另一种形式则是应用程式依赖来自于不受信任来源，典藏库及内容递送网路之外挂，函式库或模组。不安全的持续性整合/部署(CI/CD)流程则会造成潜在的未经授权存取，恶意程式码或系统破坏。最后，现在许多应用程式拥有自动更新功能，但自动更新功能在缺乏充足完整性验证功能时就下载并安装更新到处于安全状态下的应用程式。攻击者能上传自制更新档案，更新档案将传播到所有已安装之应用程式并在这些应用程式上执行。
确保不受信任之客户端不会收到未签署或加密之序列化资料并利用完整性检查或数位签章来侦测窜改或重放攻击。
利用数位签章或类似机制确保软体或资料来自预期之提供者
确保函式库及从属套件，例如 npm 或 Maven，是从受信任的典藏库取得。
使用软体供应链安全工具(例如 OWASP Dependency Check 或 OWASP CycloneDX)确保元件没有已知弱点。
适当地设定持续性整合/部署(CI/CD)流程的组态及存取控制以确保程式码在组建及部署流程中的完整性。

攻击情境范例
情境 1 不安全的反序列化：一个反应式应用程式呼叫 Spring Boot 微服务。程式设计师们试图确保他们的代码是不可变的。他们的解决方案是在双向所有请求讯息中包含序列化的用户状态。攻击者注意到“R00”Java 物件签章并使用 Java Serial Killer 工具(用来执行 Java 反序列化攻击)在应用程式服务器远端执行程式码。
情境 2 未签署之更新：许多家用路由器、机上盒、装置韧体等未以通过签署之韧体验证更新档案。未签署韧体是越来越多攻击者的目标且情况只会变得更糟。这是一个主要问题，因为只能以新版本修复此机制并期待旧版本自然淘汰，没有其他方法。
情境 3 SolarWinds 恶意更新：众所周知，某些国家会攻击更新机制，最近一次值得注意的是对 SolarWinds Orion 的攻击。该软体开发商拥有安全组建和更新完整性流程。尽管如此，这些流程仍被破坏并在几个月时间中向 18,000 多个组织送出高度针对性的恶意更新，其中大约 100 个组织受到了影响。这是历史上此类性质最深远、最重大的资安事件之一。

预防措施
使用数字签名或类似机制来验证软件或数据来自预期来源，且未被修改。
确保库和依赖项目，如: npm或Maven，正在使用受信任的存储库。如果您的风险较高，请考虑托管一个经过审核的、内部已知合格的存储库。
确保使用软件供应链安全工具(如:OWASP Dependency Check或OWASP CycloneDX)来验证组件不包含已知漏洞。
确保对代码和配置更改进行审核，以最大限度地减少恶意代码或配置引入软件管道的可能性。
确保您的CI/CD管道具有适当的隔离、配置和访问控制，以确保代码在构建和部署过程中的完整性。确保通过特定形式的完整性检查或数字签名来检测序列化数据是否存在篡改或重播，所有未签名或未加密的序列化数据不会发送到不受信任的客户端。

A09：安全日志与监控故障（Security Logging and Monitoring Failure）

2021年，安全日志与监控故障（Security Logging and Monitoring Failure）——此前名为“日志记录和监控不足”（Insufficient Logging & Monitoring）——从最后一名上升至第9位。而且该类别已扩展纳入了其他类型的故障，虽然这些故障难以测试，并且在CVE/CVSS 数据中没有得到很好的体现，但却会直接影响可见性、事件警报和取证。

风险说明
如果不进行日志记录和检测，就无法发现任何违规行为，任何时候都会发现日志记录、检测、监视和主动响应不足的情况：
日志只存储在本地
渗透测试和动态应用安全测试工具的扫描没有触发情报
警告和错误生成的日志或日志记录不充分或日志消息不清晰
…

预防潜施
开发人员应根据应用的风险，实施以下部分或全部控制:
确保所有的登录、访问控制和服务器端输入验证失败都可以被记录在足够的用户上下文中，以识别可疑或恶意的帐户，并保留足够的时间以允许延迟的取证分析。
确保日志是日志管理解决方案以方便使用的格式生成的。
确保日志数据被正确编码加密，以防止对日志或监控系统的注入或攻击。
确保高价值交易有完整性控制的审计跟踪，以防止篡改或删除，例如:只附加数据库表或类似的内容。
DevSecOps团队应该建立有效的监控和警报，以便发现可疑的活动并迅速做出反应。
建立或采用事故应对和恢复计划，例如:美国国家标准技术研究所(NIST)800-61r2或更高版本。有一些商业和开源的应用程序保护框架，如:OWASP ModSecurity核心规则集，以及开源的日志相关软件，如: Elasticsearch、Logstash、Kibana (ELK)，具有自定义仪表盘和告警功能。

A10：服务器端请求伪造（Server-Side Request Forgery）

排在最后一位的服务器端请求伪造（Server-Side Request Forgery）是2021年新增的类别。虽然数据显示其发生率相对较低，但测试覆盖率却高于平均水平，并且漏洞利用和影响潜力的评级也高于平均水平。该类别是行业安全专家为我们预警的一种重要场景，尽管目前并没有数据能够证实其危险性。

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

危害
1.内外网的端口和服务扫描
2.攻击运行在内网或本地的应用程序
3.对内网web应用进行指纹识别，识别企业内部的资产信息
4.攻击内网的web应用，主要是使用GET参数就可以实现的攻击（比如Struts2漏洞利用，SQL注入等）
5.利用file协议读取本地敏感数据文件等

预防措施
1、过滤返回的信息，如果web应用是去获取某一种类型的文件。那么在把返回结果展示给用户之前先验证返回的信息是否符合标准。
2、统一错误信息，避免用户可以根据错误信息来判断远程服务器的端口状态。
3、限制请求的端口，比如80,443,8080,8090。
4、禁止不常用的协议，仅仅允许http和https请求。可以防止类似于file:///,gopher://,ftp://等引起的问题。
5、使用DNS缓存或者Host白名单的方式。
…

其他值得关注的威胁

OWASP Top 10只能列出10大最严重的危险，但事实上，以下四个问题同样非常值得识别和修复：
（1）代码质量问题
代码质量问题包括已知的安全缺陷或模式、出于多种目的重用变量、在调试输出中暴露敏感信息、一对一错误、检查时间/使用时间（TOCTOU）竞争条件、未签名或签名转换错误等等。攻击者可能会通过使用跨多个线程的静态共享变量利用竞争条件来获取或更新敏感信息。
企业组织通常可以通过严格的编译器标志、静态代码分析工具和linter IDE插件来识别它们。现代语言的设计消除了许多这些问题，例如Rust的内存所有权和借用概念、Rust的线程设计以及 Go的严格类型和边界检查。

（2）拒绝服务（DoS）
如果具备足够的资源，拒绝服务总是可能发生的。但是，设计和编码实践对拒绝服务的严重程度有重大影响。假设任何拥有链接的人都可以访问一个大文件，或者每个页面上都会发生计算成本高的事务。在这种情况下，拒绝服务往往只需更少的努力。
企业组织可以考虑对较大对象进行访问控制，以确保只有经过授权的个人才能访问大型文件或对象，或通过边缘缓存网络为其提供服务。

（3）内存管理错误
Web应用程序倾向于使用托管内存语言编写，例如Java、.NET或node.js（JavaScript或TypeScript）。但是，这些语言是用存在内存管理问题的系统语言编写的，例如缓冲区或堆溢出、整数溢出等。多年来，有许多沙箱逃逸事件证明，Web应用程序语言名义上是内存“安全的”，而实际并非如此。
许多现代API如今都是用内存安全语言编写的，例如Rust或Go。就Rust而言，内存安全是该语言的一个关键特性。对于现有代码，使用严格的编译器标志、强类型、静态代码分析和模糊测试有助于识别内存泄漏、内存和数组溢出等。

总结

本质上来说，OWASP Top 10主要是一个意识文件。然而，这并没有阻止组织自其2003年发布以来将其用作实际上的行业AppSec标准。如果您想使用OWASP Top 10作为编码或测试标准，请记住它是底线，是起点！

OWASP Top 10榜单的目的是推动安全行业了解数据贡献公司所面临的漏洞和漏洞利用趋势，以更好地迎接和应对挑战。目前，OWASP Top 10仍处于初版阶段，还将随着安全行业不断审查其内容而发展完善。

参考

2021 OWASP Top 10榜单及变化
OWASP—Top10（2021知识总结）
2021 Owasp Top 10 逐个击破