OWASP—Top10（2021知识总结）

Posted 2023-04-04 1erkeU

OWASP top10

2021年版TOP 10产生三个新类别，且进行了一些整合

考虑到应关注根本原因而不是症状。

A01：失效的访问控制

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

风险说明：

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

常见的访问控制脆弱点：

• 违法最小权限原则或默认拒绝原则，即访问权限应只授予特定能力、角色或用户，但实际上任何人都可以访问
• 通过修改URL（参数修改或强制浏览），内部应用程序状态或者html页面，或者使用修改API请求的攻击工具绕过访问控制检查
• 通过提供唯一的标识符允许查看或编辑他人账户
• API没有对POST、PUT和DELETE强制执行访问控制
• 特权提升，在未登陆的情况下假扮用户或以用户身份登入时充当管理员

…

预防措施

开发人员和QA人员应进行访问控制功能的单元测试和集成测试

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

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

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

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

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

  …

A02：加密机制失效

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

风险说明

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

对于数据，要确认：

• 在传输数据过程中是否使用明文传输？这和传输协议有关：HTTP、SMTP、经过TLS升级的FTP。外部网络流量是有害的，需要验证所有的内部通信

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

• 是否默认使用加密密钥、生成或重复使用脆弱的加密密钥，或者是否缺少适当的密钥管理或密钥回转

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

  …

预防措施

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

…

A03：注入

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

风险说明

源代码审查是检查应用程序是否易受注入攻击的最佳方法。

强烈鼓励针对所有参数、标题、URL、cookie、JSON、SOAP和XML数据输入的自动测试

风险产生情况：

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

预防措施

防止注入需要将数据与命令和查询分开：

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

A04：不安全设计

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

风险说明

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

一个不安全设计不能通过一个完美的实现来修复。

预防措施

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

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

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

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

  …

A05：安全配置错误

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

风险说明

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

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

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

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

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

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

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

• 应用程序服务器、应用程序框架（如：Struts、Spring、ASP。net）、库文件、数据库等没有进行安全配置

  …

预防措施

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

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

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

• 检查和修复安全配置来适应最新的安全说明、更新和补丁，并将作为更新管理过程的一部分

• 一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构

  …

A06：自带缺陷和过时的组件

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

风险说明

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

• 你不知道所使用的组件版本信息（包括：服务端和客户端）。这包括了直接使用的组件或间接依赖的组件
• 软件易受攻击，不再支持或过时。
• 没有定期做漏洞扫描和订阅使用组件的安全公告
• 软件工程师没有对更新的、升级的或者打过补丁的组件进行兼容性测试
• 没有对组件进行安全配置

预防措施

每个组织都应该制定相应的计划，对整个软件生命周期进行监控、评审、升级或更改配置

制定一个补丁管理流程：

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

A07：身份识别和身份验证错误

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

风险说明

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

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

• 允许预设、脆弱、常见的密码

• 使用脆弱或无效的认证资讯回复或忘记密码的流程

• 使用明码，被加密的或使用较脆弱杂凑法的密码

  …

预防措施

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

A08：软件和数据完整性故障

预防措施

A09：安全日志和监控故障

风险说明

如果不进行日志记录和检测，就无法发现任何违规行为，任何时候都会发现日志记录、检测、监视和主动响应不足的情况：

• 日志只存储在本地

• 渗透测试和动态应用安全测试工具的扫描没有触发情报

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

  …

预防措施

A10：服务端请求伪造（ssrf）

风险说明

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

预防措施

日志记录不充分或日志消息不清晰

…

预防措施

[外链图片转存中…(img-yH0HcwVi-1648013618727)]

A10：服务端请求伪造（ssrf）

风险说明

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

预防措施

OWASP TOP 10

TOP1-注入

注入往往是应用程序缺少对输入进行安全型检查引起的，攻击者把一些包含指令的数据发送给解释器，解释器收到数据后转换成指令执行，常见的注入包括SQL注入、系统命令注入、IDAP注入，xpath注入等

危害：

注入可以导致数据的丢失，或者敏感数据的泄露，有时注入漏洞可以导致主机完全失陷。

防范：

1、使用安全的API，避免使用解释器

2、对输入的特殊字符进行转义处理

3、利用白名单来规范输入验证

TOP2-失效的身份认证和会话管理

开发者通常会建立自定义的认证和会话管理方案。但与身份认证和回话管理相关的应用程序功能往往得不到正确的实现，要正确实现这些方案却很难，结果在退出、密码管理、超时、密码找回、帐户更新等方面存在漏洞，这就导致了攻击者破坏密码、密钥、会话令牌或攻击其他的漏洞去冒充其他用户的身份

危害：

可能导致部分甚至全部账户遭到攻击，一旦攻击成功，攻击者就能执行合法的任何操作

检测：

• 用户身份验证凭证没有使用哈希或加密保护
• 认证凭证可猜测，或者能够通过薄弱的的帐户管理功能（例如账户创建、密码修改、密码恢复, 弱会话ID）重写
• 会话ID暴露在URL里 （例如URL重写）
• 会话ID容易受到会话固定（session fixation）的攻击
• 会话ID没有超时限制，或者用户会话或身份验证令牌特别是单点登录令牌在用户注销时没有失效
• 成功注册后,会话ID没有轮转
• 密码、会话ID和其他认证凭据使用未加密连接传输

TOP3-跨站XSS

危害：

攻击者在受害者访问的浏览器中执行脚本以实现会话劫持、恶意内容植入、重定型等行为

防范：

1、输入验证

2、输入编码

3、设置httponly,禁止js读取页面cookie

TOP4-不安全的对象直接引用

当开发人员公开对内部实现对象(如文件、目录或数据库键)的引用时，就会出现直接对象引用。如果没有访问控制检查或其他保护，攻击者可以操纵这些引用来访问未经授权的数据。

防范：

1、使用基于用户或者会话的间接对象访问，防止攻击者直接攻击未授权对象资源

2、对于不受信任源的访问进行访问控制

3、避免在url或者页面中直接引用内部关键参数

4、验证用户输入和url请求

TOP5-伪造跨站请求（CSRF）

攻击者利用可以预测网站特定操作及浏览器自动发送会话cookie等认证凭证等特点，伪造恶意的请求来诱导受害者访问，导致网站敏感操作被执行。

防范：

1、给每个HTTP请求添加一个不可预测的令牌，保证该令牌对每个用户会话来说是唯一性，避免该令牌在url中暴露出来

2、在关键操作时进行重新认证

TOP6-安全误配置

安全配置错误可以发生在一个应用程序堆栈的任何层面，包括平台，web服务器，应用服务器，数据库，架构和自定义的代码。攻击者通过访问默认账户，未使用的网页，未安装的补丁的漏洞，未被保护的文件和目录等，以获得对系统为授权的访问。

危害：

系统可能在未知的情况下被完全攻破，用户数据可能随时被篡改或者盗走，甚至整个系统被完全破坏。

防范：

1、实施漏洞扫描和安全审计

TOP7-限制URL访问失败（缺少功能级访问控制）

大多数web应用程序在实现UI中可见的功能之前，都要验证功能级别的访问权限。但是，当访问每个函数时，应用程序需要在服务器上执行相同的访问控制检查。如果请求没有得到验证，攻击者将能够伪造请求，以便在没有适当授权的情况下访问功能。

防范：

1、检查管理权限的过程并确保能够容易进行升级和审计

2、默认缺省情况下，应该拒绝所有访问的执行权限。对于每个功能的访问，都需要明确角色授权

3、检查每个功能分配的权限合理有效

TOP8-未验证的重定向和转发

在Web应用中重定向是极为普通的，并且通常重定向所引发的目的是带有用户输入参数的目的url，而如果这些重定向未被验证，那么攻击者就可以引导用户访问他们想要用户访问的站点

同样，转发也是极为普遍的，本质上转发是在同一个应用中对一个新页面发送请求，并且有时是用参数来定义目标页面的。同样，如果参数未被验证，那么攻击者就可以利用其来绕过认证或是授权检查。

危害：

利用重定向可以试图安装恶意软件或诱使受害者泄露密码等敏感信息

防范：

1、避免使用重定向和转发

2、如果使用了转发和重定向，则不要在确定目标时涉及到用户参数。

3、如果无法避免使用目标参数，则应保证目标参数对于当前用户是有效的并已授权。

TOP9-应用已知脆弱性的组件

应用程序使用带有已知漏洞的组件会破坏应用程序防御系统，可能导致严重的数据丢失或服务器接管

防范：

1、识别正在使用的组件和版本，包括所有的依赖

2、更新组件或引用的库文件到最新

3、简历安全策略来管理组件的使用

TOP10-敏感信息暴露

保护与加密敏感数据已经成为网络应用的最重要的组成部分。最常见的漏洞是应该进行加密的数据没有进行加密。使用加密的情况下常见问题是不安全的密钥和使用弱算法加密。