一、 失效的访问控制

1.概述

访问控制强制执行策略，使用户不能在其预期权限之外采取行动。故障通常会导致未经授权的信息泄露、修改或破坏所有数据或执行超出用户限制的业务功能。常见的访问控制漏洞包括：[出自:jiwo.org]

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

2.攻击情景范例

（1）：应用程序在访问帐户信息的 SQL 调用中使用未经验证的数据：

（2）pstmt.executeQuery(); ```

（3）攻击者只需修改浏览器的“acct”参数即可发送他们想要的任何帐号。如果没有正确验证，攻击者可以访问任何用户的帐户。

二、加密失败

1.概述

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

是否有任何数据以明文形式传输？这涉及 HTTP、SMTP 和 FTP
等协议。外部互联网流量是危险的。验证所有内部流量，例如，负载平衡器、Web 服务器或后端系统之间的流量。
默认情况下或在较旧的代码中是否使用任何旧的或弱的加密算法？
是否正在使用默认加密密钥、生成或重复使用弱加密密钥，或者是否缺少适当的密钥管理或轮换？
是否未强制执行加密，例如，是否缺少任何用户代理（浏览器）安全指令或标头？
用户代理（例如，应用程序、邮件客户端）是否不验证收到的服务器证书是否有效？

2.攻击情景范例

场景#1：应用程序使用自动数据库加密对数据库中的信用卡号进行加密。但是，此数据在检索时会自动解密，从而允许 SQL
注入缺陷以明文形式检索信用卡号。 场景#2：站点不使用或对所有页面强制执行 TLS
或支持弱加密。攻击者监视网络流量（例如，在不安全的无线网络中），将连接从 HTTPS 降级为 HTTP，拦截请求并窃取用户的会话
cookie。然后攻击者重放这个 cookie
并劫持用户的（经过身份验证的）会话，访问或修改用户的私人数据。除了上述之外，他们还可以更改所有传输的数据，例如，汇款的接收者。

三、 注入

1.概述

应用程序在以下情况下容易受到攻击：

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

2.攻击情景范例

场景 #1：应用程序在构建以下易受攻击的 SQL 调用时使用不受信任的数据：

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

四、不安全的设计

1.概述

不安全设计是一个广泛的类别，代表许多不同的弱点，表现为“缺失或无效的控制设计”。缺少不安全的设计是缺少控制的地方。例如，想象一下应该加密敏感数据的代码，但没有方法。无效的不安全设计是可以实现威胁的地方，但域（业务）逻辑验证不足会阻止该操作。例如，假设域逻辑应该根据收入等级处理流行病税收减免，但不验证所有输入都已正确签名并提供比应授予的更重要的减免收益。

安全设计是一种文化和方法，它不断评估威胁并确保代码经过稳健设计和测试，以防止已知的攻击方法。安全设计需要安全的开发生命周期、某种形式的安全设计模式或铺砌道路组件库或工具，以及威胁建模。

2.攻击情景范例

场景 #1：凭证恢复工作流程可能包括“问答”，这是 NIST 800-63b、OWASP ASVS 和 OWASP Top 10
所禁止的。不能将问答作为多个人身份的证据可以知道答案，这就是为什么它们被禁止。此类代码应删除并替换为更安全的设计。

场景#2：连锁影院允许团体预订折扣，并且在要求押金之前最多有 15
名参与者。攻击者可以对该流程进行威胁建模，并测试他们是否可以在几次请求中一次预订 600 个座位和所有电影院，从而造成巨大的收入损失。

五、安全配置错误

1.概述

如果应用程序是：

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

2.攻击情景范例

场景#1：应用程序服务器带有未从生产服务器中删除的示例应用程序。这些示例应用程序具有攻击者用来破坏服务器的已知安全漏洞。假设这些应用程序之一是管理控制台，并且默认帐户未更改。在这种情况下，攻击者使用默认密码登录并接管。

六、易受攻击和过时的组件

1.描述

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

2.攻击情景范例

场景#1：组件通常以与应用程序本身相同的权限运行，因此任何组件中的缺陷都可能导致严重影响。此类缺陷可能是偶然的（例如，编码错误）或有意的（例如，组件中的后门）。发现的一些可利用组件漏洞的示例是：

CVE-2017-5638 是一个 Struts 2 远程代码执行漏洞，可以在服务器上执行任意代码，已被归咎于重大漏洞。 虽然物联网
(IoT) 通常很难或不可能修补，但修补它们的重要性可能很大（例如，生物医学设备）。
有一些自动化工具可以帮助攻击者找到未打补丁或配置错误的系统。例如，Shodan IoT 搜索引擎可以帮助您找到仍然存在 2014 年 4
月修补的 Heartbleed 漏洞的设备。

七、认证和授权失败

1.描述

确认用户的身份、身份验证和会话管理对于防止与身份验证相关的攻击至关重要。如果应用程序存在以下情况，则可能存在身份验证漏洞：

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

2.攻击情景范例

场景#1：凭证填充（使用已知密码列表）是一种常见的攻击。假设应用程序没有实施自动化威胁或凭证填充保护。在这种情况下，应用程序可以用作密码预言机来确定凭证是否有效。

场景#2：大多数身份验证攻击是由于继续使用密码作为唯一因素而发生的。一经考虑，最佳实践、密码轮换和复杂性要求会鼓励用户使用和重复使用弱密码。建议组织按照
NIST 800-63 停止这些做法并使用多因素身份验证。

场景
#3：应用程序会话超时设置不正确。用户使用公共计算机访问应用程序。用户没有选择“注销”，而是简单地关闭浏览器选项卡并走开。攻击者在一个小时后使用同一个浏览器，而用户仍然通过身份验证。

八、软件和数据完整性故障

1.描述

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

2.攻击情景范例

场景 #1 不安全的反序列化： React 应用程序调用一组 Spring Boot
微服务。作为函数式程序员，他们试图确保他们的代码是不可变的。他们提出的解决方案是序列化用户状态并在每个请求中来回传递它。攻击者注意到“R00”Java
对象签名并使用 Java Serial Killer 工具在应用服务器上获取远程代码执行权。

场景 #2
无需签名即可更新：许多家用路由器、机顶盒、设备固件和其他固件不通过签名固件验证更新。未签名固件是攻击者越来越多的目标，预计只会变得更糟。这是一个主要问题，因为很多时候除了在未来版本中修复并等待以前的版本过时之外，没有任何补救机制。

九、 安全日志记录和监控失败

1.描述

回到 2021 年 OWASP 前 10
名，该类别旨在帮助检测、升级和响应主动违规行为。如果没有日志记录和监控，就无法检测到漏洞。任何时候都会发生日志记录、检测、监控和主动响应不足的情况：

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

2.攻击情景范例
场景#1：由于缺乏监控和日志记录，一家儿童健康计划提供商的网站运营商无法检测到违规行为。外部方通知健康计划提供者，攻击者访问并修改了超过 350 万儿童的数千份敏感健康记录。事后审查发现网站开发人员没有解决重大漏洞。由于没有对系统进行日志记录或监控，数据泄露可能自 2013 年以来一直在进行，时间超过七年。
场景#2：印度一家大型航空公司发生数据泄露事件，涉及数百万乘客超过十年的个人数据，包括护照和信用卡数据。数据泄露发生在第三方云托管服务提供商处，该提供商在一段时间后将泄露事件通知了航空公司。
场景 #3：一家主要的欧洲航空公司遭遇了 GDPR 可报告的违规行为。据报道，该漏洞是由攻击者利用的支付应用程序安全漏洞引起的，他们收集了超过 400,000 条客户支付记录。该航空公司因此被隐私监管机构罚款 2000 万英镑。

十、:服务器请求伪造

1.描述

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

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

2.攻击情景范例

场景#1：端口扫描内部服务器。如果网络架构是未分段的，攻击者可以绘制内部网络，并根据连接结果或连接或拒绝 SSRF
负载连接所用的时间来确定内部服务器上的端口是打开还是关闭。

场景#2：敏感数据暴露。攻击者可以访问本地文件，例如 或内部服务以获取敏感信息。

场景#3：访问云服务的元数据存储。大多数云提供商都有元数据存储，例如http://169.254.169.254/。攻击者可以读取元数据来获取敏感信息。

场景#4：破坏内部服务——攻击者可以滥用内部服务进行进一步的攻击，例如远程代码执行 (RCE) 或拒绝服务 (DoS)。