OWASP TOP 10 漏洞指南（2021）

什么是OWASP TOP 10?

OWASP，全称“开放式Web应用程序安全项目”是一个非营利性的组织，2003年该组织首次出版了“Top 10”，也就是10项最严重的Web应用程序安全风险列表。
Top 10 总结了Web应用程序最可能、最常见、最危险的十大安全漏洞。
近几年OWASP TOP的变化

A1 失效的访问控制

概述

失效的访问控制，也叫越权，攻击者通过各种手段提升自己的权限，越过访问控制，使访问控制失效，这样攻击者就可以冒充用户、管理员或拥有特权的用户，或者创建、访问、更新或删除任何记录。
常见的访问漏洞包括：
1.通过修改 URL、内部应用程序状态或 HTML 页面，或仅使用自定义 API 攻击工具来绕过访问控制检查。
2.允许将主键更改为其他用户的记录，允许查看或编辑其他人的帐户。
3.特权提升。在未登录的情况下充当用户或以用户身份登录时充当管理员。
4.元数据操作，例如重放或篡改 JSON Web 令牌 (JWT) 访问控制令牌，或用于提升权限或滥用 JWT 失效的 cookie 或隐藏字段。
5.CORS 错误配置允许未经授权的 API 访问。
6.强制以未经身份验证的用户身份浏览经过身份验证的页面或以标准用户身份浏览特权页面。访问 API 时缺少对 POST、PUT 和 DELETE 的访问控制。

分类

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

防御

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

A2 加密失败

概述

之前称为敏感数据泄露。首先是确定传输中和静止数据的保护需求。例如，密码、信用卡号、健康记录、个人信息和商业秘密需要额外保护，主要是如果该数据属于隐私法（例如欧盟的通用数据保护条例 (GDPR)）或法规（例如金融数据保护）例如 PCI 数据安全标准 (PCI DSS)。对于所有此类数据：
1.是否有任何数据以明文形式传输？这涉及 HTTP、SMTP 和 FTP 等协议。外部互联网流量是危险的。验证所有内部流量，例如，负载平衡器、Web 服务器或后端系统之间的流量。
2.默认情况下或在较旧的代码中是否使用任何旧的或弱的加密算法？
3.是否正在使用默认加密密钥、生成或重复使用弱加密密钥，或者是否缺少适当的密钥管理或轮换？
4.是否未强制执行加密，例如，是否缺少任何用户代理（浏览器）安全指令或标头？
5.用户代理（例如，应用程序、邮件客户端）是否不验证收到的服务器证书是否有效？

防御

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

A3 注入攻击

概述

应用程序在以下情况下容易受到攻击：
1.应用程序不会验证、过滤或清理用户提供的数据。
2.没有上下文感知转义的动态查询或非参数化调用直接在解释器中使用。
3.在对象关系映射 (ORM) 搜索参数中使用恶意数据来提取额外的敏感记录。
4.直接使用或连接恶意数据。SQL 或命令包含动态查询、命令或存储过程中的结构和恶意数据。
一些更常见的注入是 SQL、NoSQL、OS 命令、对象关系映射 (ORM)、LDAP 和表达式语言 (EL) 或对象图导航库 (OGNL) 注入。这个概念在所有口译员中都是相同的。源代码审查是检测应用程序是否容易受到注入攻击的最佳方法。强烈建议对所有参数、标头、URL、cookie、JSON、SOAP 和 XML 数据输入进行自动化测试。组织可以将静态源 (SAST) 和动态应用程序测试 (DAST) 工具包含到 CI/CD 管道中，以在生产部署之前识别引入的注入缺陷。

通常注入有sql注入和os（Operating System）注入
SQL注入：就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。具体来说，它是利用现有应用程序，将（恶意）的SQL命令注入到后台数据库引擎执行的能力，它可以通过在Web表单中输入（恶意）SQL语句得到一个存在安全漏洞的网站上的数据库，而不是按照设计者意图去执行SQL语句。
sql注入的防御
（1）：对输入进行严格的转义和过滤。
（2）：数据类型进行严格定义，数据长度进行严格规定。
（3）：通过waf设备启用防止sql注入的策略。
（4）：严格限制网站访问数据库的权限。

os注入：Web开发所使用的编程语言中，大多数都能通过Shell执行OS（操作系统）命令。通过Shell执行OS命令时，或者开发中用到的某个方法其内部利用了Shell时，就有可能出现OS命令被任意执行的情况。这种现象被称为OS命令注入。
os注入的防御
   1：使用安全的函数对传递给OS命令参数进行转义。
   2：不将外界输入的字符串传递给命令行参数。
   3：选择不调用OS命令的实现方法。

防御

1.防止注入需要将数据与命令和查询分开。
2.首选选项是使用安全的 API，它完全避免使用解释器，提供参数化接口，或迁移到对象关系映射工具 (ORM)。
注意：即使在参数化时，如果 PL/SQL 或 T-SQL 连接查询和数据或使用 EXECUTE IMMEDIATE 或 exec() 执行恶意数据，则存储过程仍然会引入 SQL 注入。
3.使用正面或“白名单”服务器端输入验证。这不是一个完整的防御，因为许多应用程序需要特殊字符，例如文本区域或移动应用程序的 API。
对于任何残留的动态查询，使用该解释器的特定转义语法转义特殊字符。
注意：表名、列名等 SQL 结构不能转义，因此用户提供的结构名是危险的。这是报告编写软件中的常见问题。
4.在查询中使用 LIMIT 和其他 SQL 控件以防止在 SQL 注入的情况下大量披露记录。

A4 不安全的设计

防御

1.与 AppSec 专业人员建立并使用安全的开发生命周期，以帮助评估和设计与安全和隐私相关的控制
2.建立和使用安全设计模式库或准备使用组件的铺好的道路
3.将威胁建模用于关键身份验证、访问控制、业务逻辑和关键流
4.编写单元和集成测试以验证所有关键流都能抵抗威胁模型

A5 安全配置错误

概述

安全配置错误是比较常见的漏洞，由于操作者的不当配置(默认配置，临时配置，开源云存储，http标头配置，以及包含敏感信息的详细错误)，导致攻击者可以利用这些配置获取到更高的权限，安全配置错误可以发生在各个层面，包含平台、web服务器、应用服务器、数据库、架构和代码。

防御

1.可重复的强化过程使部署另一个适当锁定的环境变得快速而轻松。开发、QA 和生产环境都应配置相同，在每个环境中使用不同的凭据。这个过程应该是自动化的，以最大限度地减少设置新安全环境所需的工作。
2.一个没有任何不必要的功能、组件、文档和示例的最小平台。删除或不安装未使用的功能和框架。
3.作为补丁管理流程的一部分，审查和更新适用于所有安全说明、更新和补丁的配置的任务（请参阅 A06:2021-易受攻击和过时的组件）。查看云存储权限（例如，S3 存储桶权限）。

4.分段应用程序架构通过分段、容器化或云安全组 (ACL) 在组件或租户之间提供有效且安全的分离。
5.向客户端发送安全指令，例如安全标头。
6.验证配置和设置在所有环境中的有效性的自动化过程。

A6 易受攻击和过时的组件

概述

你可能很脆弱：
1.如果您不知道您使用的所有组件的版本（客户端和服务器端）。这包括您直接使用的组件以及嵌套的依赖项。
2.如果软件易受攻击、不受支持或已过期。这包括操作系统、Web/应用程序服务器、数据库管理系统 (DBMS)、应用程序、API 和所有组件、运行时环境和库。
3.如果您不定期扫描漏洞并订阅与您使用的组件相关的安全公告。
4.如果您没有以基于风险的方式及时修复或升级底层平台、框架和依赖项。这通常发生在修补是变更控制下的每月或每季度任务的环境中，使组织面临数天或数月不必要地暴露于固定漏洞的风险。
5.如果软件开发人员不测试更新、升级或修补的库的兼容性。
6.如果您不保护组件的配置（请参阅 A05:2021-安全配置错误）。

防御

1.删除未使用的依赖项、不必要的功能、组件、文件和文档。
2.使用版本、OWASP Dependency Check、retire.js 等工具持续清点客户端和服务器端组件（例如框架、库）及其依赖项的版本。成分。使用软件组合分析工具来自动化该过程。订阅与您使用的组件相关的安全漏洞的电子邮件警报。
3.仅通过安全链接从官方来源获取组件。首选签名包以减少包含修改后的恶意组件的机会（请参阅 A08:2021-软件和数据完整性故障）。
4.监视未维护或未为旧版本创建安全补丁的库和组件。如果无法打补丁，请考虑部署虚拟补丁来监控、检测或防止发现的问题。

A7 认证和授权失败

概述

确认用户的身份、身份验证和会话管理对于防止与身份验证相关的攻击至关重要。如果应用程序存在以下情况，则可能存在身份验证弱点：
1.允许自动攻击，例如凭据填充，其中攻击者拥有有效用户名和密码的列表。
2.允许暴力破解或其他自动攻击。
3.允许默认、弱或已知密码，例如"Password1"或"admin/admin"。
4.使用弱或无效的凭据恢复和忘记密码过程，例如"基于知识的答案"，这些过程无法确保安全。
5.使用纯文本、加密或弱哈希密码数据存储（请参见A02：2021 -加密失败）。
6.具有缺失或无效的多重身份验证。
7.在 URL 中公开会话标识符。
8.成功登录后重用会话标识符。
9.未正确使会话 ID 失效。用户会话或身份验证令牌（主要是单一登录 （SSO） 令牌）在注销或不活动期间未正确失效。

防御

1 在可能的情况下，实施多因素身份验证以防止自动凭证填充、暴力破解和被盗凭证重用攻击。
2 不要使用任何默认凭据进行交付或部署，尤其是对于管理员用户。
3 实施弱密码检查，例如针对前 10,000 个最差密码列表测试新密码或更改的密码。
4 将密码长度、复杂性和轮换策略与 N 对齐
5 通过对所有结果使用相同的消息，确保注册、凭据恢复和 API 路径能够抵御帐户枚举攻击。
6 限制或越来越多地延迟失败的登录尝试，但注意不要造成拒绝服务场景。当检测到凭证填充、暴力破解或其他攻击时，记录所有故障并提醒管理员。
7 使用服务器端、安全、内置的会话管理器，在登录后生成新的高熵随机会话 ID。会话标识符不应在 URL 中，应安全存储，并在注销、空闲和绝对超时后失效。

A8 软件和数据完整性故障

概述

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

防御

1. 使用数字签名或类似机制来验证软件或数据来自预期来源且未被更改。 2 确保库和依赖项（例如 npm 或 Maven）正在使用受信任的存储库。如果您有较高的风险状况，请考虑托管经过审查的内部已知良好存储库。 3 确保使用软件供应链安全工具（例如 OWASP Dependency Check 或 OWASP CycloneDX）来验证组件不包含已知漏洞 4 确保对代码和配置更改有一个审查过程，以最大限度地减少恶意代码或配置可能被引入您的软件管道的机会。 5 确保您的 CI/CD 管道具有适当的隔离、配置和访问控制，以确保流经构建和部署过程的代码的完整性。 6 确保未签名或未加密的序列化数据不会在没有某种形式的完整性检查或数字签名的情况下发送到不受信任的客户端，以检测序列化数据的篡改或重放

A9 安全日志记录和监控失败

概述

它指的是在没有日志记录和监控，将无法检测到漏洞，此类故障会直接影响可见性、事件报警和取证。下面是些风险类型：
1.不记录可审计的事件，例如登录、失败登录和高价值交易。
2.警告和错误不会生成、不充分或不清楚的日志消息。
3.不会监控应用程序和 API 的日志是否存在可疑活动。
4.日志仅存储在本地。
5.适当的警报阈值和响应升级流程没有到位或有效。
6.动态应用程序安全测试 (DAST) 工具（例如 OWASP ZAP）的渗透测试和扫描不会触发警报。
7.应用程序无法实时或接近实时地检测、升级或警告主动攻击。

防御

1.确保所有登录、访问控制和服务器端输入验证失败都可以用足够的用户上下文来记录，以识别可疑或恶意帐户，并保留足够的时间以允许延迟取证分析。
2.确保以日志管理解决方案可以轻松使用的格式生成日志。
3.确保日志数据编码正确，以防止对日志或监控系统的注入或攻击。
4.确保高价值交易具有带有完整性控制的审计跟踪，以防止篡改或删除，例如仅追加数据库表或类似的。
5.DevSecOps 团队应该建立有效的监控和警报，以便快速检测和响应可疑活动。
6.制定或采用事件响应和恢复计划，例如美国国家标准与技术研究院 (NIST) 800-61r2 或更高版本。

A10 服务端请求伪造(SSRF)

概述

每当 Web 应用程序在未验证用户提供的 URL 的情况下获取远程资源时，就会出现 SSRF 缺陷。 即使受到防火墙、VPN 或其他类型的网络访问控制列表 (ACL) 的保护，它也允许攻击者强制应用程序将精心设计的请求发送到意外目的地。
随着现代 Web 应用程序为最终用户提供方便的功能，获取 URL 成为一种常见情况。 因此，SSRF 的发病率正在增加。 此外，由于云服务和架构的复杂性，SSRF 的严重性越来越高。
SSRF(Server-Side Request Forgery:服务器端请求伪造)是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下,SSRF是要目标网站的内部系统。(因为他是从内部系统访问的,所有可以通过它攻击外网无法访问的内部系统,也就是把目标网站当中 间人)。

防御

1.黑名单
(1)过滤10.0.0.0/8、172.16.0.0/12、12.168.0.0/16、localhost私有地址、Pv6地址
(2)过滤file、dict:、 gopher:、ftp:/危险 schema
(3)对返回的内容进行识别
(4)内网服务开启鉴权(Memcached, Redis, Elasticsearch and MongoDB
2.最佳防护
(1)使用地址白名单
(2)对返回内容进行识别
(3)需要使用互联网资源(比如贴吧使用网络图片)而无法使用白名单的情况:首先禁用 CURLOPT FOLLOWLOCATION:然后通过域名获取目标，并过滤内部ip；最后识别返回的内容是否与假定内容一致