OWASP TOP 10-2021详解

目录

TOP10-2017和TOP10-2021对比

 什么是OWASP？

A01-2021 失效的访问控制          

A02-2021-加密控制失效

A03-2021-注入

A04-2021-不安全设计

A05-2021-安全配置错误

A06-2021- 自带缺陷和过时的组件

A07-2021-身份识别和身份验证错误

A08-2021-软件和数据完整性故障

A09-2021-安全日志和监控故障

A10-2021-服务端请求伪造

---

TOP10-2017和TOP10-2021对比

 什么是OWASP？

OWASP（开放式Web应用程序安全项目）是一个开放的社区，由非营利组织 OWASP基金会支持的项目。对所有致力于改进应用程序安全的人士开放，旨在提高对应用程序安全性的认识。 其最具权威的就是“10项最严重的Web 应用程序安全风险列表” ，总结并更新Web应用程序中最可能、最常见、最危险的十大漏洞，是开发、测试、服务、咨询人员应该会的应用知识。

 2003年该组织首次出版了“Top 10”，也就是10项最严重的Web应用程序安全风险列表。

A01-2021 失效的访问控制          

访问控制概论

访问控制是一种策略，在这种策略的控制下，用户的操作不能逾越预设好的权限边界。而访问控制一旦失效通常会导致未认证信息泄露、内部数据篡改、数据删除和越权操作等后果。

失效的访问控制概论

失效的访问控制，也叫越权，攻击者通过各种手段提升自己的权限，越过访问控制，使访问控制失效，这样攻击者就可以冒充用户、管理员或拥有特权的用户，或者创建、访问、更新或删除任何记录。

常见类型

• 通过修改 URL、内部应用程序状态或 HTML 页面，或仅使用自定义 API 攻击工具来绕过访问控制检查。
• 允许将主键更改为其他用户的记录，允许查看或编辑其他人的帐户。
• 特权提升。在未登录的情况下充当用户或以用户身份登录时充当管理员。
• 元数据操作，例如重放或篡改 JSON Web 令牌 (JWT) 访问控制令牌，或用于提升权限或滥用 JWT 失效的 cookie 或隐藏字段。
• CORS 错误配置允许未经授权的 API 访问。
• 强制以未经身份验证的用户身份浏览经过身份验证的页面或以标准用户身份浏览特权页面。访问 API 时缺少对 POST、PUT 和 DELETE 的访问控制。

分类

垂直越权，攻击者可以从普通的用户权限提升到管理员的权限访问应用程序
水平越权，攻击者可以从普通用户A的权限提升到普通用户B的权限访问应用程序

防御

访问控制仅在受信任的服务器端代码或无服务器 API 中有效，攻击者无法修改访问控制检查或元数据。

• 除公共资源外，默认拒绝。
• 实施一次访问控制机制并在整个应用程序中重复使用它们，包括最大限度地减少 CORS 的使用。
• 模型访问控制应该强制记录所有权，而不是接受用户可以创建、读取、更新或删除任何记录。
• 独特的应用程序业务限制要求应由领域模型强制执行。
• 禁用 Web 服务器目录列表并确保文件元数据（例如 .git）和备份文件不在 Web 根目录中。
• 记录访问控制失败，在适当时提醒管理员（例如，重复失败）。⑦速率限制 API 和控制器访问，以最大限度地减少自动攻击工具的危害。
• 注销后，JWT 令牌应在服务器上失效。

常见攻击场景举例

用户轻松的修改URL的参数内容，从而轻而易举的访问到admin页面。一下是两个假设URL，第一个是普通用户，第二个是管理员用户页面，如果普通用户访问第二个页面成功，那就说明访问控制策略存在问题。

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

由于实现过程中未对用户访问参数设置边界，导致了很多越权问题的发生，下方示例URL中，攻击者可以尝试修改 API 接口中的 order_id 参数，使其在程序接口上的输入合法，但是对于用户而言却是越权行为。

https://example.com/order/?order_id=2021102617429999

HTTP PUT 方法最早目的用于文件管理操作，可以对网站服务器中的文件实现更改删除的更新操作，该方法往往可以导致各种文件上传漏洞，造成严重的网站攻击事件，下方示例代码，在支持 PUT 方法的环境中，上传 Webshell 进行提权；在实际运用中，若必须启用该方法，则需要对该方法涉及文件资源做好严格的访问权限控制。

put /root/Desktop/shell.php

Web 应用将身份认证结果直接存储在 Cookie 中，并未施加额外的保护措施，下方示例中，攻击者通过web前端拦截cookie,实现对cookie的修改，从而达到未授权访问的效果

Cookie: role=user --> Cookie: role=admin

有些开发者为了方便，直接在 Access-Control-Allow-Origin 中反射请求的 Origin 值。比如下配置，意味着nginx相信任何网站，允许所有访问跨域读取器资源，造成隐私数据被窃取。

add_header "Access-Control-Allow-Origin" $http_origin;
add_header “Access-Control-Allow-Credentials” “true”;

A02-2021-加密控制失效

在之前的Top10中，“加密控制失效”以前叫做“敏感数据泄露”，敏感数据泄露的根本原因是对数据加密存在有机可乘的漏洞，因此2021版改称为“加密控制失效”更贴切一些。

敏感信息泄露

简单来说，如果我们的应用系统向一个未得到访问授权的用户暴露了敏感信息，那么这就是一种敏感数据泄露风险。

 敏感数据泄露即使在今天仍然是相当严重且普遍存在的一个风险点，主要原因是数据泄露并非一个纯粹的技术性问题，很多时候与业务流程、功能设计都息息相关。

单纯从漏洞危害程度来看，敏感数据泄露主要分为两种，一种是业务敏感数据泄露，另一种是技术敏感信息泄露。业务敏感数据的泄露危害性是巨大的，会直接影响到公司的品牌和业务运行；技术敏感信息泄露往往不能对应用系统安全性产生直接威胁，但配合其他漏洞的综合利用可以实现 1+1>2 的效果。

常见类型

• 数据采用明文形式传输，例如使用HTTP、SMTP和FTP等协议。
• 默认情况下或在老代码中使用弱加密算法或过时的加密算法。
• 未强制执行加密。
• 用户代理不验证服务器证书是否有效。

防御

• 对应用程序处理、存储或传输的数据进行分类。根据隐私法、监管要求或业务需求确定哪些数据是敏感的。
• 根据分类应用控制。
• 不要不必要地存储敏感数据。尽快丢弃它或使用符合 PCI DSS 的标记化甚至截断。未保留的数据不能被窃取。
• 确保加密所有静态敏感数据。
• 确保拥有最新且强大的标准算法、协议和密钥；使用适当的密钥管理。
• 使用安全协议（例如具有完美前向保密 (PFS) 密码的 TLS、服务器的密码优先级和安全参数）加密所有传输中的数据。使用 HTTP 严格传输安全 (HSTS) 等指令强制加密。
• 对包含敏感数据的响应禁用缓存。
• 使用具有工作因子（延迟因子）的强自适应和加盐散列函数存储密码，例如 Argon2、scrypt、bcrypt 或 PBKDF2。
• 独立验证配置和设置的有效性。

A03-2021-注入

注入攻击

一个 注入攻击 是指恶意代码的输入攻击者到应用程序迫使其执行命令妥协数据或整个应用程序。最常见的注入攻击类型是 SQL 注入和跨站点脚本 (XSS) 攻击，但也有代码注入、命令注入、CCS 注入等。

SQL注入

就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。

sql注入的防御

• 对输入进行严格的转义和过滤。
• 数据类型进行严格定义，数据长度进行严格规定。
• 通过waf设备启用防止sql注入的策略。
• 严格限制网站访问数据库的权限
• 使用无需使用解释器或使用参数化查询的安全 API 
• 引入积极的服务器端输入验证（白名单）
• 如果应用程序中需要特殊字符，则应尽可能通过特定解释器的转义语法避免使用这些字符
• 在查询中使用数据库控件，例如 LIMIT SQL 子句，以最大限度地减少注入成功时暴露的数据量

A04-2021-不安全设计

“不安全设计”是2021年新增的一个类型，它重点关注的是设计缺陷的风险，“不安全设计”代表的是一类漏洞。

相关漏洞

漏洞产生的原因

在开发软件时，在关键身份验证、访问控制、业务逻辑和关键流部位没有进行安全的设计。

怎么发掘？
业务逻辑的显性体现：

• 支付逻辑
• 密码找回
• 验证码暴力破解
• 验证码的重复使用
• 验证码客户端回显
• 验证码绕过
• 验证码自动识别

怎么利用？
发现这些漏洞之后，或者是可以获得管理员的账号密码或者是私密用户的账号密码或者是造成对网站的业务上的损害。

1.支付逻辑漏洞
所有涉及购买、支付等方面的功能处就有可能存在支付漏洞。
三个重要因素：用户、商品、商家。
这三个因素在支付流程中都可能造成支付漏洞。
挖掘：寻找网站的支付系统、或兑换系统，抓包判断有没有敏感信息可以修改。
利用：1.修改支付价格 2.修改支付状态 3.修改购买数量 4.修改优惠券、积分 5.修改支付接口 6.多重替换支付 7.重复支付 8.最小额支付 9.值为最大值支付问题 10.无限制试用

2.找回密码
利用漏洞修改他人账号密码，甚至修改管理员的密码。
一般流程：
首先尝试正常找回密码流程，选择不同的找回方式，记录所有数据包
分析数据包，找到敏感部分
分析后台找回机制所采用的验证手段
修改数据包验证推测
可能产生漏洞的情况
1.验证码爆破时，对验证码有效期和请求次数没有进行限制
2.token验证之类的，直接将验证内容返回给用户
3.找回密码功能的进行身份验证内容未加密或者加密算法较弱，容易被猜解
4.对用户的身份验证在前端进行，导致验证被抓包绕过
5.在最后一步修改密码的动作时，没有校验账号是否通过了验证、短信与手机号是否对应

过程：
1.密码找回的凭证太弱，如只需要填入一个四位或者六位的纯数字，就可以重置密码
2.url返回验证码及token，密码返回凭证在页面中，返回短信验证码
3.邮箱弱token：时间戳的MD5、用户名、服务器时间
4.短信验证码，邮箱token，重置密码token
5.重新绑定：手机绑定（任意用户绑上自己可控的安全手机，就可以重置别人的手机号），邮箱绑定
6.服务器验证：最终提交步骤，服务器验证可控内容（在最后重置密码处跟随一个用户ID，改成其他用户ID，即可把其他用户改成你刚刚设置的密码）、服务器验证逻辑为空
7.用户身份验证：账号与手机号码的绑定、账号与邮箱账号的绑定
8.跳过验证步骤、找回方式，直接道设置新密码页面
9.在本地验证服务器的返回信息，确定是否执行重置密码，但是其返回的信息是可控的内容，或者可以得到的内容、发送短信等验证信息的动作在本地进行，可以通过修改返回包进行控制
10.在找回密码处存在注入漏洞
11.token生成可控
12.注册重复的用户名
13.session覆盖

3.验证码暴力破解
一些比较弱的，并且只是在前端作用的验证码，可以用工具来识别爆破。

4.验证码的重复使用
在设计验证码的时候没有设计时效性，灵活性。

5.验证码客户端回显
点击发送验证码之后查看返回包，发现验证码没有加密，或者有一个可以用来确认验证码正确的正确值。

A05-2021-安全配置错误

90%的web应用程序都经历过错误配置测试，这些将导致安全风险。安全配置错误 是打开攻击面的常见问题。

原因

• 不安全的默认配置
• 不完整或临时配置
• 未修补的缺陷
• 未使用的页面
• 未受保护的文件和目录
• 开放云存储
• 错误配置的 HTTP 标头或加密
• 包含敏感信息的详细错误消息

常见的漏洞

• 在应用程序堆栈的任何部分缺少适当的安全强化或对云服务的权限配置不正确。
• 启用或安装了不必要的功能（例如，不必要的端口、服务、页面、帐户或权限）。
• 默认帐户及其密码仍处于启用状态且未更改。
• 错误处理向用户显示堆栈跟踪或其他信息过多的错误消息。
• 对于升级的系统，最新的安全功能被禁用或未安全配置。
• 应用程序服务器、应用程序框架（例如，Struts、Spring、ASP.NET）、库、数据库等中的安全设置未设置为安全值。
• 服务器不发送安全标头或指令，或者它们未设置为安全值。
• 软件已过时或易受攻击（请参阅 A06:2021-易受攻击和过时的组件）。

防御

OWASP 建议实施安全安装过程。除此之外，你应该：

• 开发和自动化一个流程，该流程允许快速轻松地部署配置相同但可通过不同凭据访问的安全环境
• 部署最小平台并删除未使用的功能和框架或不安装
• 引入分离组件和租户的分段应用架构
• 查看和更新​​所有安全说明、更新和补丁的配置，尤其是云存储权限
• 在所有环境中自动监控和验证安全配置的有效性
• 借助自动化工作流程实时解决安全问题

A06-2021- 自带缺陷和过时的组件

不安全的组件是我们努力测试和评估风险的已知问题。如果客户端和服务器使用了易受攻击的组件版本，就可能成为被攻击者攻击的目标。库、框架和其他软件模块等组件的权限与应用程序的权限相同。如果利用易受攻击的组件，则可能会丢失数据和服务器接管。使用具有已知漏洞的组件的应用程序和 API 可能会破坏应用程序防御并引发各种攻击和影响。这是一个普遍存在的问题。

常见漏洞

• 不知道所使用的组件的版本
• 不定期扫描漏洞，不关注所使用组件的官方公告
• 没有以基于风险的方式及时修复或升级底层平台、框架和依赖项。这通常发生在修补是变更控制下的每月或每季度任务的环境中，使组织面临数天或数月不必要地暴露于固定漏洞的风险。
• 软件开发人员不测试、升级或修补库的兼容性
• 不保护组件的配置

防御

• 仅通过安全链接使用来自官方来源的组件。使用签名的包来最小化包中包含恶意组件的可能性
• 监控任何未维护且未为旧版本提供安全补丁的库和组件
• 部署虚拟补丁以监控、检测和防范未打补丁组件的问题
• 删除所有未使用的依赖项以及不需要的功能、组件、文件和文档
• 保持客户端和服务器端组件及其版本和依赖项的最新清单。监控组件漏洞的重要来源，并尽可能自动化流程
• 在应用程序的生命周期内创建并持续执行监视、分类、更新或更改配置

A07-2021-身份识别和身份验证错误

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

通俗地说，该漏洞会导致攻击者使用用户的用户名和密码进行填充，从而入侵系统。

名词解释

Session

服务器端记录用户的信息，当用户完成身份认证后，存储所需要的用户资料。

Cookie

服务器端发送，存储在客户端。在用户访问网站的时候建立（登陆），用于跟踪用户在网站中的活动，每次请求和客户端都需要发送此信息至服务器端进行校验。

身份认证(token)

常用于系统登陆，比较常见的就是密码和用户名的校验，安全性更高的还有图片/手机验证码、证书或者ukey等。

会话管理

通过会话机制来进行身份认证，用户登陆时生成唯一的token，服务器端存储在session中，客户端存储在cookie中，之后的身份识别均校验token即可，不需要再校验用户名和密码等。

常见漏洞

• 允许自动攻击，例如撞库，其中攻击者拥有有效用户名和密码的列表。
• 允许蛮力或其他自动攻击。
• 允许使用默认密码、弱密码或众所周知的密码，例如“Password1”或“admin/admin”。
• 使用弱或无效的凭据恢复和忘记密码流程，例如无法确保安全的“基于知识的答案”。
• 使用纯文本、加密或弱散列密码（请参阅 A3:2017-敏感数据泄露）。
• 缺少或无效的多因素身份验证。
• 在 URL 中公开会话 ID（例如，URL 重写）。
• 成功登录后不要轮换会话 ID。
• 不会正确地使会话 ID 无效。用户会话或身份验证令牌（主要是单点登录 (SSO) 令牌）在注销或一段时间不活动期间未正确失效。

防御

• 划定范围,区分公共范围和受限区域.
• 对账户使用限定锁定策略,避免暴力攻击.
• 支持密码有效期,避免密码单一性
• 必要时禁用账户
• 不要储存密码,可以利用哈希技术加密密码传输,进行对比
• 要求使用强密码
• 不要明文传输密码
• 使用 SSL 保护会话身份验证 Cookie.
• 对 Cookie 内容进行加密
• 限制会话时长
• 进行多因素身份验证
• 避免未经授权的会话状态.

A08-2021-软件和数据完整性故障

这也是一个新增的类型，指的是在不验证完整性的情况下做出与软件更新、关键数据和CI/CD管道相关的假设。

我们软件和数据完整性故障可以分为两个方向，即软件完整性故障及数据完整性故障 。

软件完整性故障代表应用的运行代码可能受到篡改，攻击者可以将恶意代码加入到应用程序中，使得应用程序运行时，恶意代码也被执行。

数据完整性故障则代表应用发送的数据可能受到篡改，攻击者可以通过修改一些数据，实现欺骗其他用户乃至绕过访问控制。

软件完整性故障

对于攻击者来说，执行这一步操作有多种方式：

• 当应用依赖于一些来源不可信的插件或模块时，攻击者就可以尝试对这些依赖项的代码进行修改，这样应用在引入依赖项时也会将恶意代码引入，从而导致软件完整性被破坏。这种方法可说是供应链攻击的一种方式。
• 利用应用更新过程来进行攻击，如果一个应用在更新时，没有对其更新的内容进行完整性验证就将它添加到应用中，那么在这个过程中，就可能会存在恶意代码的添加。

数据完整性故障

数据的完整性故障就是应用发送的数据可能受到了篡改，比如受到了常见的中间人攻击。

当然，也可能是不安全的反序列化等，关于序列化与反序列化，可以参考序列化与反序列化详解。不安全的反序列化漏洞曾经一度冲上过OWASP的TOP 10漏洞榜单，但是在最新的一期排名中，则被归类为了数据的完整性故障。

不安全的反序列化

不安全反序列化 是一种攻击，其中将被操纵的对象注入到 Web 应用程序的上下文中。如果存在应用程序漏洞，则对象被反序列化并执行，从而导致 SQL 注入、路径遍历、应用程序拒绝服务和远程代码执行。

防御

对于防御，我们可以根据软件和数据完整性故障产生的不同原因，针对性地执行防御措施 。

比如为了防止用户下载被修改过的应用或者修改应用发送的数据，我们可以在应用中增加数字签名机制。

A09-2021-安全日志和监控故障

2017年以前，“安全日志记录和监控失败”叫做“日志记录和监控不足”，此类型已经扩展包括很多类型的漏洞。它指的是在没有日志记录和监控，将无法检测到漏洞，此类故障会直接影响可见性、事件报警和取证。

常见漏洞

• 不记录可审计的事件，例如登录、失败登录和高价值交易。
• 警告和错误不会生成、不充分或不清楚的日志消息。
• 不会监控应用程序和 API 的日志是否存在可疑活动。
• 日志仅存储在本地。
• 适当的警报阈值和响应升级流程没有到位或有效。
• DAST 工具（例如 OWASP ZAP）的渗透测试和扫描不会触发警报。
• 应用程序无法实时或接近实时地检测、升级或警告主动攻击。

防御

• 在登录、访问控制失败和服务器端输入验证失败期间记录足够的用户上下文，并且日志数据保留足够长的时间。这将帮助您发现可疑活动和帐户
• 使用日志管理解决方案易于处理的日志格式
• 对所有高价值交易实施具有完整性控制的审计跟踪，以避免删除或篡改企图
• 使用监控和警报及时发现可疑活动并采取措施
• 引入事件响应和恢复计划以有效应对攻击

A10-2021-服务端请求伪造

服务端请求伪造(SSRF)

这一漏洞是在行业调查中添加的，数据显示发生概率较低。

SSRF 即为 Server Side Request Forgery 的缩写，它意为服务端请求伪造。指的是当攻击者无法访问 Web 应用的内网时，在未能取得服务器所有权限的情况下，利用服务器存在的漏洞，以服务器的身份发送一条精心构造好的请求给服务器所在内网，从而成功对内网发起请求。

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

例子

这是一个web程序发起的POST请求：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

 服务器向指定的URL发出请求，检索库存状态，然后将其返回给用户。在这种情况下，攻击者可以修改请求以指定服务器本身本地的URL。例如：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

在这里，服务器可能会获取/admin的内容并将其返回给用户。

此时攻击者可以直接访问/admin；但是，通常只有适当的经过身份验证的用户才能访问管理功能。因此，直接访问URL时将不会看到任何有价值的内容。但是，当对/admin的请求来自本地计算机时，将绕过常规的访问控制，该应用程序授予对管理功能的完全访问权限，因为该请求来自受信任的位置。

对于SSRF攻击，有多种利用方式，比如内网资产扫描、读取文件甚至执行系统命令等。详细的攻击利用方法可以参考：web渗透测试–SSRF漏洞、SSRF请求伪造基础、SSRF漏洞中用到的协议。

防御