关于OWASP Top 10 2021的整理

前言

OWASP(open web application security project)是一个开放的在线社区,致力于使组织能够开发、购买和维护可信赖的应用程序和API。而owasp top 10是该组织统计当年内出现频率和问题最高的漏洞。进行排名和相关说明，来帮助开发者进行修改和发展。

2021版的owasp也已经更新，分别依次是：失效的访问控制、加密失败、注入、不安全的设计、安全配置错误、易受攻击和过时的组件、认证和授权失败、软件和数据完整性故障、安全日志记录和监控失败、服务端请求伪造（SSRF）。2021中出现了三个新类别，四个类别的命名和范围发生了变化。

A01:2021 失效的访问控制

链接地址：https://owasp.org/Top10/A01_2021-Broken_Access_Control/

数据要素

CWES 映射	最大发生率	平均发生率	平均加权漏洞利用率	平均加权漏洞影响率	最大覆盖范围	平均覆盖范围	总发生次数	CVE总数
34	55.97%	3.81%	6.92	5.93	94.55%	47.72%	318487	19013

概述

在2021中从之前的第五名跃升到榜首；94%的应用程序都经过了某种形式的破坏访问控制的测试。映射到失效的访问控制的34个CWE在应用程序中出现的次数比任何其他类别都多。其中值得关住的常见CWE有：CWE-200：将敏感信息暴露给未经授权的参与者、CWE-201通过发送的数据暴露敏感信息以及CWE-352：跨站请求伪造。

描述

失效访问控制就是执行策略，使用户不能超出其预期权限行事。如果策略失败就会导致未经授权的信息被暴露、修改或者销毁相关数据，更有甚者在用户限制之外执行业务功能。另外，通俗点讲失效的访问控制其实就是一种越权操作行为，这种越权主要表现为水平越权和垂直越权行为。下面是一些主要的常见问题：

1 违反最小特权原则或默认拒绝，其中仅应授予特定能力，角色或用户访问权限，但任何人都可以访问。
2 通过修改URL（参数篡改或强制浏览）、内部应用程序状态或HTML页面，或使用攻击工具修改API请求来绕过访问控制检查
3 访问API时缺少对POST、PUT和DELETE的访问控制。
4 特权提升。在未登录的情况下充当用户或以用户身份登录时充当管理员。
5 元数据操作，例如重放或篡改JSON web令牌（JWT）访问控制令牌，或用于提升权限或滥用JWT失效的cookie或隐藏字段。
6 CORS（跨域）错误配置允许来自未经授权/不受信任的来源的API访问。
7 强制以未经身份验证的用户身份浏览经过身份验证的页面或以标准用户浏览特权页面。

对于上述提到的问题其实说具体点可以说是文件包含或这目录遍历，由于控制不严使用户可以对网站进行非法操作，得到一些敏感信息和对网站不利的信息；还有就是权限绕过和提升，例如网站存在漏洞使恶意者得到一个账户就可以对其它平级用户实现操作，或者严重一点的可以借此获得管理员权限；还有就是对不安全直接对象的引用，有时候网站在跨站访问一些资源的时候由于配置错误或者控制不严，使网站暴露在危险之中。

失效的访问控制的防御思路

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

1 除公共资源外，默认拒绝。
2 实施一次访问控制机制并在整个应用程序中重复使用它们，包括最大限度地减少跨源资源共享 (CORS) 的使用。
3 模型访问控制应该强制记录所有权，而不是接受用户可以创建、读取、更新或删除任何记录。
4 独特的应用程序业务限制要求应由领域模型强制执行。
5 禁用Web服务器目录列表并确保文件元数据（例如 .git）和备份文件不在 Web 根目录中。 记录访问控制失败，在适当时提醒管理员（例如，重复失败）。
6 速率限制API和控制器访问，以最大限度地减少自动攻击工具的危害。
7 注销后，服务器上的有状态会话标识符应失效。无状态JWT令牌应该是短暂的，以便最小化攻击者的机会窗口。对于寿命较长的 JWT，强烈建议遵循OAuth标准来撤销访问。

做到检查访问——对每一个来自于不信任的源的直接对象引用都必须包含访问控制检查，从而确信该用户对该对象拥有访问权。
如果这个URL不是公开的，那么必须限制能够访问他的授权用户。
完全禁止访问未被授权的页面类型（如配置文件、日志文件、源文件等）。

A02:2021 加密失败

链接地址：https://owasp.org/Top10/A02_2021-Cryptographic_Failures/

数据要素

CWES 映射	最大发生率	平均发生率	平均加权漏洞利用率	平均加权漏洞影响率	最大覆盖范围	平均覆盖范围	总发生次数	CVE总数
29	46.44%	4.49%	7.29	6.81	79.33%	34.85%	233788	3075

概述

加密失败在之前的第三位上上升到了第二位，在这之前还叫做敏感数据泄露，这更像是一种广泛的症状而不是根本原因，在2021中重新重点关注与密码学相关的漏洞，因为这些密码学上的相关故障通常会导致敏感数据的泄露或者系统受损。从文章的解释中我理解为主要是采用的相关加密算法是不安全的，因为使用了这些不安全的加密算法,使被加密的数据有被破解的风险，从而导致相关敏感数据的泄露。

描述

针对加密失败首先要确定传输中和静止数据的保护需求。例如，密码、信用卡号、健康记录、个人信息和商业秘密需要额外保护，主要是如果该数据属于隐私法（例如欧盟的通用数据保护条例 (GDPR)）或法规（例如金融数据保护）例如 PCI 数据安全标准 (PCI DSS)。对于所有此类数据：

1 是否有任何数据以明文形式传输？这涉及 HTTP、SMTP、FTP 等协议也使用 TLS 升级，如 STARTTLS。外部互联网流量是危险的。2 验证所有内部流量，例如，负载平衡器、Web 服务器或后端系统之间的流量。
3 默认情况下或在较旧的代码中是否使用任何旧的或弱的加密算法或协议？
4 是否正在使用默认加密密钥、生成或重复使用弱加密密钥，或者是否缺少适当的密钥管理或轮换？加密密钥是否已签入源代码存储库？
5 是否未强制执行加密，例如，是否缺少任何 HTTP 标头（浏览器）安全指令或标头？
6 收到的服务器证书和信任链是否经过正确验证？
7 初始化向量是否被忽略、重用或生成的加密操作模式不够安全？是否使用了不安全的操作模式，例如欧洲央行？当认证加密更合适时是否使用加密？
8 在没有密码基密钥派生函数的情况下，是否将密码用作加密密钥？
9 随机性是否用于并非旨在满足加密要求的加密目的？即使选择了正确的函数，它是否需要由开发人员播种，如果不需要，开发人员是否用缺乏足够熵/不可预测性的种子覆盖了内置的强大播种功能？
10 是否使用过时的哈希函数，例如 MD5 或 SHA1，或者在需要加密哈希函数时使用非加密哈希函数？
11 是否在使用已弃用的加密填充方法，例如 PCKS number 1 v1.5？
12 加密错误消息或边信道信息是否可利用，例如以填充预言机攻击的形式？

预防思路

1 对应用程序处理、存储或传输的数据进行分类。根据隐私法、监管要求或业务需求确定哪些数据是敏感的。
2 不要不必要地存储敏感数据。尽快丢弃它或使用符合 PCI DSS 的标记化甚至截断。未保留的数据不能被窃取。
3 确保加密所有静态敏感数据。
4 确保拥有最新且强大的标准算法、协议和密钥；使用适当的密钥管理。
5 使用安全协议（例如具有前向保密 (FS) 密码的 TLS、服务器的密码优先级和安全参数）加密所有传输中的数据。使用 HTTP 严格传输安全 (HSTS) 等指令强制加密。
6 对包含敏感数据的响应禁用缓存。
7 根据数据分类应用所需的安全控制。
8 不要使用旧协议（例如 FTP 和 SMTP）来传输敏感数据。
9 使用具有工作因子（延迟因子）的强自适应和加盐散列函数存储密码，例如 Argon2、scrypt、bcrypt 或 PBKDF2。
10 必须选择适合操作模式的初始化向量。对于许多模式，这意味着使用 CSPRNG（密码安全伪随机数生成器）。对于需要随机数的模式，则初始化向量 (IV) 不需要 CSPRNG。在所有情况下，对于一个固定密钥，IV 永远不应该被使用两次。
11 始终使用经过身份验证的加密，而不仅仅是加密。
12 密钥应该以加密方式随机生成并作为字节数组存储在内存中。如果使用密码，则必须通过适当的密码基密钥派生函数将其转换为密钥。
13 确保在适当的地方使用加密随机性，并且它没有以可预测的方式或低熵进行播种。大多数现代 API 不需要开发人员为 CSPRNG 设置种子以获得安全性。
14 避免不推荐使用的加密函数和填充方案，例如 MD5、SHA1、PKCS number 1 v1.5。
15 独立验证配置和设置的有效性。

A03:2021 注入

数据要素

CWES 映射	最大发生率	平均发生率	平均加权漏洞利用率	平均加权漏洞影响率	最大覆盖范围	平均覆盖范围	总发生次数	CVE总数
33	19.09%	3.37%	7.25	7.15	94.04%	47.90%	274228	32078

概述

注入从之前的榜首下滑到了2021的第三位，94% 的应用程序针对某种形式的注射进行了测试，最大发生率为 19%，平均发生率为 3%，出现次数为 274k。值得注意的常见弱点枚举 (CWE) 包括 CWE-79：跨站点脚本、CWE-89：SQL 注入和 CWE-73：文件名或路径的外部控制。

描述

关于注入：当用户发送不可信地数据到解释器的时候，就可能出现注入漏洞，比如SQL, NoSQL, LDAP注入，解释器可能会将用户发送的恶意数据视为指令或数据库查询，使得用户在没有权限的情况下访问数据，甚至导致用户完全控制服务器。

部分成因

1 应用程序不会验证、过滤或清理用户提供的数据。
2 没有上下文感知转义的动态查询或非参数化调用直接在解释器中使用。
3 在对象关系映射 (ORM) 搜索参数中使用恶意数据来提取额外的敏感记录。
4 直接使用或连接恶意数据。SQL 或命令包含动态查询、命令或存储过程中的结构和恶意数据。

源代码审查是检测应用程序是否容易受到注入攻击的最佳方法。强烈建议对所有参数、标头、URL、cookie、JSON、SOAP 和 XML 数据输入进行自动化测试。组织可以将静态源 (SAST) 和动态应用程序测试 (DAST) 工具包含到 CI/CD 管道中，以在生产部署之前识别引入的注入缺陷。

预防思路

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

补充：一个强大的防御waf也是不错的选择，可以相对有效的避免。

A04:2021 不安全设计

链接地址：https://www.cnblogs.com/byErichas/p/15378374.html

数据要素

CWES 映射	最大发生率	平均发生率	平均加权漏洞利用率	平均加权漏洞影响率	最大覆盖范围	平均覆盖范围	总发生次数	CVE总数
40	24.19%	3.00%	6.46	6.78	77.25%	42.51%	262407	2691

概述

这是2021新出现的类别，侧重于设计和架构缺陷相关的风险，同时呼吁更多地使用威胁建模、安全设计模式和参考架构。值得注意的CWE包括 CWE-209：生成包含敏感信息的错误消息、 CWE-256：未受保护的凭证存储、CWE-501：信任边界违规和CWE-522：受保护的凭证不足。

描述

不安全设计是一个广泛的类别，代表许多不同的弱点，表现为“缺失或无效的控制设计”。缺少不安全的设计是缺少控制的地方。例如，想象一下应该加密敏感数据的代码，但没有方法。无效的不安全设计是可以实现威胁的地方，但域（业务）逻辑验证不足会阻止该操作。

收集并与企业协商应用程序的业务需求，包括有关所有数据资产的机密性、完整性、可用性和真实性以及预期业务逻辑的保护要求。考虑您的应用程序的公开程度以及您是否需要隔离租户（除了访问控制之外）。编译技术要求，包括功能性和非功能性安全要求。规划和协商涵盖所有设计、构建、测试和运营（包括安全活动）的预算。。安全设计是一种文化和方法，它不断评估威胁并确保代码经过稳健设计和。

我们所熟悉的应用程序未容错也是属于这种，以一个登录界面为例，如果登录的时候涉及到内容的加密和解密.那么登录时用非常规手段传了一串非法的字符串进行登录.在解密的时候可能会出现一些异常,如索引越界,这样就会把异常的英文内容直接提示给页面了。应该在编写代码的时候在登录接口中处理异常的时候, 要根据不同的异常进行处理. 业务的异常, 如密码错误,账户冻结等, 就按业务异常提示.其他意外的错误, 则统一给提示语, 屏蔽掉异常的英文内容，防止通过攻击者构造不同的。

预防思路

1 与 AppSec 专业人员建立并使用安全的开发生命周期，以帮助评估和设计与安全和隐私相关的控制
2 建立和使用安全设计模式库或准备使用组件的铺好的道路
3 将威胁建模用于关键身份验证、访问控制、业务逻辑和关键流
4 将安全语言和控件集成到用户故事中
5 在应用程序的每一层（从前端到后端）集成合理性检查
6 编写单元和集成测试以验证所有关键流都能抵抗威胁模型。 为应用程序的每一层编译用例和误用用例。
7 根据暴露和保护需求分离系统层和网络层上的层
8 通过设计在所有层中强有力地隔离租户
9 限制用户或服务的资源消耗

A05:2021 安全配置错误

链接地址：https://owasp.org/Top10/A05_2021-Security_Misconfiguration/

数据要素

CWES 映射	最大发生率	平均发生率	平均加权漏洞利用率	平均加权漏洞影响率	最大覆盖范围	平均覆盖范围	总发生次数	CVE总数
20	19.84%	4.51%	8.12	6.56	89.58%	44.84%	208387	789

概述

从2之前的第6位上升了2021的第5位，90% 的应用程序都接受了某种形式的错误配置测试，平均发生率为 4.%，并且在此风险类别中出现了超过 208k 次常见弱点枚举 (CWE)。随着更多转向高度可配置的软件，看到这一类别上升也就不足为奇了。值得注意的 CWE 包括 CWE-16 配置和 CWE-611 XML 外部实体引用的不当限制。

描述

安全配置错误可以发生在一个应用程序堆栈的任何层面，包括网络服务、平台、Web服务器、应用服务器、数据库、框架、自定义代码和预安装的虚拟机、容器和存储。自动扫描器可用于检测错误的安全配置、默认帐户的使用或配置、不必要的服务、遗留选项等。

下面几种情况应用程序会受到攻击：

1 应用程序栈堆的任何部分都缺少适当的安全加固，或者云服务的权限配置错误。
2 应用程序启用或安装了不必要的功能（例如：不必要的端口、服务、网页、帐户或权限）。
3 默认帐户的密码仍然可用且没有更改。
4 错误处理机制向用户披露堆栈跟踪或其他大量错误信息。
5 对于更新的系统，禁用或不安全地配置最新的安全功能。
6 应用程序服务器、应用程序框架（如：Struts、Spring、ASP.NET）、库文件、数据库等没有进行安全配置。
7 服务器不发送安全标头或指令，或者未对服务器进行安全配置。
8 您的应用软件已过期或易受攻击（参见A9：2017-使用含有已知漏洞的组件）。

预防思路

1 一个可以快速且易于部署在另一个锁定环境的可重复的加固过程。开发、质量保证和生产环境都应该进行相同配置，并且，在每个环境中使用不同的密码。这个过程应该是自动化的，以尽量减少安装一个新安全环境的耗费。
2 搭建最小化平台，该平台不包含任何不必要的功能、组件、文档和示例。移除或不安装不适用的功能和框架。
3 检查和修复安全配置项来适应最新的安全说明、更新和补丁，并将其作为更新管理过程的一部分，（参见A9：2017-使用含有已知漏洞的组件）。在检查过程中，应特别注意云存储权限（如：S3桶权限）。
4 一个能在组件和用户间提供有效的分离和安全性的分段应用程序架构，包括：分段、容器化和云安全组。
5 向客户端发送安全指令，如：安全标头。
6 在所有环境中能够进行正确安全配置和设置的自动化过程。

A06:2021 易受攻击和过时的组件

链接地址：https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/

数据元素

CWES 映射	最大发生率	平均发生率	最大覆盖范围	平均覆盖范围	平均加权漏洞利用率	平均漏洞加权漏洞影响率	总发生次数	CVE总数
3	27.96%	8.77%	51.78%	22.47%	5.00	5.00	30457	0

概述

它在前 10 名社区调查中排名第二，但也有足够的数据通过数据进入前 10 名。易受攻击的组件是我们难以测试和评估风险的已知问题，并且是唯一没有任何常见弱点枚举 (CWE) 映射到包含的 CWE 的类别，因此使用默认的漏洞利用/影响权重 5.0。值得注意的 CWE 包括 CWE-1104：使用未维护的第三方组件和来自 2013 年和 2017 年前 10 名的两个 CWE。

描述

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

比如我们的产品经常出现的产品版本问题等类似的问题，旧的版本或者组件就有可能攻破，是网站或者受到损失。

预防思路

1 删除未使用的依赖项、不必要的功能、组件、文件和文档。
2 使用版本、OWASP 依赖关系检查、retire.js 等工具持续清点客户端和服务器端组件（例如框架、库）及其依赖项的版本。持续监控常见漏洞和暴露 (CVE) 等来源和国家漏洞数据库 (NVD) 以获取组件中的漏洞。使用软件组合分析工具来自动化该过程。订阅与您使用的组件相关的安全漏洞的电子邮件警报。
3 仅通过安全链接从官方来源获取组件。首选签名包以减少包含修改后的恶意组件的机会（请参阅 A08:2021-软件和数据完整性故障）。
4 监视未维护或未为旧版本创建安全补丁的库和组件。如果无法打补丁，请考虑部署虚拟补丁来监控、检测或防止发现的问题。
5 每个组织都必须确保在应用程序或产品组合的生命周期内制定持续的监控、分类和应用更新或配置更改的计划。

A07:2021 认证和授权失败

链接地址：https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/

数据要素

CWES 映射	最大发生率	平均发生率	平均加权漏洞利用率	平均加权漏洞影响率	最大覆盖范围	平均覆盖范围	总发生次数	CVE总数
22	14.84%	2.55%	7.40	6.50	79.51%	45.72%	132195	3897

概述

在这之前是叫做损坏的身份认证，从之前的第二位下滑到现在的第七位，现在包括与识别失败相关的常见弱点枚举 (CWE)。值得注意的 CWE 包括 CWE-297：主机不匹配的证书验证不当、CWE-287：身份验证不当和 CWE-384：会话固定。

描述

通过错误使用应用程序的身份认证和会话管理功能，攻击者能够破译密码、密钥或会话令牌，或者利用其它开发缺陷来暂时性或永久性冒充其他用户的身份。确认用户的身份、身份验证和会话管理对于防止与身份验证相关的攻击至关重要。如果应用程序存在以下情况，则可能存在身份验证漏洞：

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 中，应安全存储，并在注销、空闲和绝对超时后失效。

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

链接地址：https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/

数据要素

CWES 映射	最大发生率	平均发生率	平均加权漏洞利用率	平均加权漏洞影响率	最大覆盖范围	平均覆盖范围	总发生次数	CVE总数
10	16.67%	2.05%	6.94	7.94	75.04%	45.35%	47972	1152

概述

这个类别也是2021新出现的，着眼于在不验证完整性的情况下，做出与软件更新、关键数据和 CI/CD（持续集成/持续部署）管道相关的假设。CVE/CVSS(常见漏洞和暴露/常见漏洞评分系统)数据的最高加权影响之一可以对应、到此类别中的10个CWE。A8:2017-不安全的反序列化现在是这个类别的一部分。

描述

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

预防思路

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

A09:2021 安全日志记录和监控失败

链接地址：https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/

数据要素

CWES 映射	最大发生率	平均发生率	平均加权漏洞利用率	平均加权漏洞影响率	最大覆盖范围	平均覆盖范围	总发生次数	CVE总数
4	19.23%	6.51%	6.87	4.99	53.67%	39.97%	53615	242

概述

2017年以前，“安全日志记录和监控失败”叫做“日志记录和监控不足”，此类型已经扩展包括很多类型的漏洞。日志记录和监控可能难以测试，通常涉及采访或询问是否在渗透过程中检测到攻击测试。此类别的 CVE/CVSS 数据不多，但检测和响应漏洞至关重要。尽管如此，它对问责制、可见性、事件警报和取证仍然非常有影响力。此类别扩展到 CWE-778 日志记录不足之外，包括 CWE-117 日志的不当输出中和、CWE-223 安全相关信息的省略和 CWE-532 将敏感信息插入日志文件。

描述

它指的是在没有日志记录和监控，将无法检测到漏洞，此类故障会直接影响可见性、事件报警和取证。下面是些风险类型：

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

预防思路

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

A10:2021 服务端请求伪造（SSRF）

链接地址：https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/

数据要素

CWES 映射	最大发生率	平均发生率	平均加权漏洞利用率	平均加权漏洞影响率	最大覆盖范围	平均覆盖范围	总发生次数	CVE总数
1	2.72%	2.72%	8.28	6.72	67.72%	67.72%	9503	385

概述

这一类别是在行业调查中添加的。数据显示发生率相对较低，测试覆盖率高于平均水平，利用和影响潜力评级高于平均水平。由于新条目可能是单个或一小群常见弱点枚举 (CWE)，以引起注意和意识，因此希望它们受到关注，并且可以在未来版本中归入更大的类别。

描述

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

随着现代 Web 应用程序为最终用户提供方便的功能，获取 URL 成为一种常见情况。因此，SSRF 的发病率正在增加。此外，由于云服务和架构的复杂性，SSRF 的严重性越来越高。

SSRF(Server-Side Request Forgery:服务器端请求伪造)是一种由攻击者构造形成由服务端发起请求的一个安全漏洞。一般情况下,SSRF是要目标网站的内部系统。(因为他是从内部系统访问的,所有可以通过它攻击外网无法访问的内部系统,也就是把目标网站当中间人)。

形成原因

SSRF形成的原因大都是由于服务端提供了从其他服务器应用获取数据的功能,且没有对目标地址做过滤与限制。比如从指定URL地址获取网页文本内容,加载指定地址的图片, 文档,等等。也就是通过篡改获取资源的请求发送给服务器，但是服务器并没有检测这个请求是否合法的,然后服务器以他的身份来访问其他服务器的资源

用途

利用漏洞可以实现以下几种攻击：

1 可以对外网、服务器所在内网、本地进行端口扫描,获取一些服务的banner信息
2 攻击运行在内网或本地的应用程序(比如溢出)；
3 对内网web应用进行指纹识别,通过访问默认文件实现:；
4 攻击内外网的web应用,主要是使用get参数就可以实现的攻击(比如 struts2,sqli 等)
5 利用file协议读取本地文件等。

出现的位置

总的来说就是所有调用外部资源的参数都有可能存在ssrf漏洞。比如：分享（通过URL地址分享网页内容），转码服务、在线翻译、图片加载和下载（通过URL地址加载或下载图片）、图片以及文章的收藏功能、未公开的api实现以及其他调用URL的功能、从URL关键字寻找（share、WAP、URL、link、src、source、target…）

防护思路

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；最后识别返回的内容是否与假定内容一致