【OWASPTOP10】2021年常见web安全漏洞TOP10排⾏
【2021】常见web安全漏洞TOP10排⾏
应⽤程序安全风险
攻击者可以通过应⽤程序中许多的不同的路径⽅式去危害企业业务。每种路径⽅法都代表了⼀种风险，这些风险都值得关注。
什么是 OWASP TOP 10
OWASP（开放式Web应⽤程序安全项⽬）是⼀个开放的社区，由⾮营利组织 OWASP基⾦会⽀持的项⽬。对所有致⼒于改进应⽤程序安全的⼈⼠开放，旨在提⾼对应⽤程序安全性的认识。
其最具权威的就是“10项最严重的Web 应⽤程序安全风险列表” ，总结并更新Web应⽤程序中最可能、最常见、最危险的⼗⼤漏洞，是开发、测试、服务、咨询⼈员应知应会的知识。
OWASP Top 10 2021 是全新的，具有新的图形设计和⼀页有⽤的信息图。
2021 年前 10 名发⽣了什么变化
有三个新类别，四个类别的命名和范围发⽣了变化，并且 2021 年的前 10 名中进⾏了⼀些合并。
A01:2021-Broken Access Control 失效的访问控制
从第五位上升；94% 的应⽤程序都经过了某种形式的破坏访问控制的测试。映射到 Broken Access Control 的 34 个 CWE 在应⽤程序中出现的次数⽐任何其他类别都多。
A02:2021-Cryptographic Failures 加密失败
上移⼀位⾄ #2，以前称为敏感数据泄露，这是⼴泛的症状⽽不是根本原因。此处重新关注与密码学相关的漏洞，这些漏洞通常会导致敏感数据泄露或系统受损。
A03:2021-Injection 注⼊
下滑到第三位。94% 的应⽤程序都针对某种形式的注⼊进⾏了测试，映射到此类别的 33 个 CWE 在应⽤程序中的出现次数排名第⼆。跨站点脚本攻击现在是此版本中此类别的⼀部分。
A04:2021-不安全的设计
是2021 年的⼀个新类别，重点关注与设计缺陷相关的风险。如果我们真的想作为⼀个⾏业“安全左移”，就需要更多地使⽤威胁建模、安全设计模式和原则以及参考架构。
A05:2021-安全配置错误
从上⼀版的第 6 位上升；90% 的应⽤程序都经过了某种形式的错误配置测试。随着更多定制性⾼度可配置的软件，看到这⼀类别上升也就不⾜为奇了。XML 外部实体 (XXE) 的前⼀个类别现在属于此类别。
A06:2021-Vulnerable and Outdated Components 易受攻击和过时的组件
之前的标题是使⽤具有已知漏洞的组件，在⾏业调查中排名第⼆，但也有⾜够的数据通过数据分析进⼊前 10 名。该类别从 2017 年的第 9 位上升，是我们难以测试和评估风险的已知问题。它是唯⼀没有任何 CVE 映射到包含的 CWE 的类别，因此默认的利⽤和影响权重 5.0 被计⼊他们的分数。
A07:2021-Identification and Authentication Failures 认证和授权失败
以前是 Broken Authentication 失效的⾝份认证并且从第⼆位下滑，现在包括与识别失败更多相关的 CWE。这个类别仍然是前 10 名的⼀个组成部分，但标准化框架的可⽤性增加似乎有所帮助。
A08:2021-Software and Data Integrity Failures 软件和数据完整性故障
是 2021 年的⼀个新类别，专注于在不验证完整性的情况下做出与软件更新、关键数据和 CI/CD 管道相关的假设。CVE/CVSS 数据的最⾼加权影响之⼀映射到该类别中的 10 个CWE。2017 年的不安全反序列化现在是这⼀更⼤类别的⼀部分。
A09:2021-Security Logging and Monitoring Failure 安全⽇志记录和监控失败
以前是⽇志记录和监控不⾜，是从⾏业调查 (#3) 中添加的，从之前的 #10 上升。此类别已扩展为包括更多类型的故障，难以测试，并且在 CVE/CVSS 数据中没有得到很好的体现。但是，此类故障会直接影响可见性、事件警报和取证。
A10:2021-Server-Side Request Forgery 服务器请求伪造
是从⾏业调查 (#1) 中添加的。数据显⽰发⽣率相对较低，测试覆盖率⾼于平均⽔平，并且利⽤和影响潜⼒的评级⾼于平均⽔平。此类别代表⾏业专业⼈⼠告诉我们这很重要的场景，即使⽬前数据中没有说明。
前 10 名的这⼀部分⽐以往任何时候都更受数据驱动，但并⾮盲⽬地受数据驱动。我们从贡献的数据中选择了⼗个类别中的⼋个，从⾼⽔平的⾏业调查中选择了两个类别。我们这样做的根本原因是，查看贡献的数据就是回顾过去。AppSec 研究⼈员花时间寻新的漏洞和测试它们的新⽅法。将这些测试集成到⼯具和流程中需要时间。当我们能够可靠地⼤规模测试漏洞时，可能已经过去了很多年。为了平衡这种观点，我们使⽤⾏业调查来询问⼀线⼈员他们认为数据可能尚未显⽰的漏洞。
有很多关于⼗⼤风险之间重叠的讨论。根据每个（包括 CWE 列表）的定义，确实没有任何重叠。但是，从概念上讲，可能存在基于更⾼级别命名的重叠或交互。维恩图多次⽤于显⽰这样的重叠。
上⾯的维恩图代表了 2017 年⼗⼤风险类别之间的相互作⽤。这样做时，⼏个要点变得明显：
有⼈可能会争辩说，跨站点脚本最终属于注⼊，因为它本质上是内容注⼊。看看 2021 年的数据，XSS 需要进⼊注⼊变得更加明显。
重叠仅在⼀个⽅向。我们通常会根据最终表现或“症状”⽽不是（可能很深的）根本原因对漏洞进⾏分类。例如，“敏感数据暴露”可能是“安全配置错误”的结果；但是，您不会从另⼀个⽅向看到它。因此，在交互区域中绘制了箭头以指⽰发⽣的⽅向。
有时这些图表是⽤A06:2021 Using Components with known Vulnerabilities 中的所有内容绘制的。虽然
其中⼀些风险类别可能是第三⽅漏洞的根本原因，但它们的管理⽅式和责任通常不同。其他类型通常代表第⼀⽅风险。
A01:2021 – 失效的访问控制概述
从第五位上升，94% 的应⽤程序都经过了某种形式的访问控制损坏测试。值得注意的CWE包括CWE-200：将敏感信息暴露给未经授权的参与者、CWE-201：通过发送的数据暴露敏
感信息和CWE-352：跨站点请求伪造。
失效的访问控制 - 描述
访问控制强制执⾏策略，使⽤户不能在其预期权限之外采取⾏动。故障通常会导致未经授权的信息泄露、修改或破坏所有数据或执⾏超出⽤户限制的业务功能。常见的访问控制漏洞包括：
通过修改 URL、内部应⽤程序状态或 HTML 页⾯，或仅使⽤⾃定义 API 攻击⼯具来绕过访问控制检查。
允许将主键更改为其他⽤户的记录，允许查看或编辑其他⼈的帐户。
特权提升。在未登录的情况下充当⽤户或以⽤户⾝份登录时充当管理员。
元数据操作，例如重放或篡改 JSON Web 令牌 (JWT) 访问控制令牌，或⽤于提升权限或滥⽤ JWT 失效的 cookie 或隐藏字段。
CORS 错误配置允许未经授权的 API 访问。
强制以未经⾝份验证的⽤户⾝份浏览经过⾝份验证的页⾯或以标准⽤户⾝份浏览特权页⾯。访问 API 时缺少对 POST、PUT 和 DELETE 的访问控制。
失效的访问控制 - 如何预防
访问控制仅在受信任的服务器端代码或⽆服务器 API 中有效，攻击者⽆法修改访问控制检查或元数据。
除公共资源外，默认拒绝。
实施⼀次访问控制机制并在整个应⽤程序中重复使⽤它们，包括最⼤限度地减少 CORS 的使⽤。
模型访问控制应该强制记录所有权，⽽不是接受⽤户可以创建、读取、更新或删除任何记录。
独特的应⽤程序业务限制要求应由领域模型强制执⾏。
禁⽤ Web 服务器⽬录列表并确保⽂件元数据（例如 .git）和备份⽂件不在 Web 根⽬录中。
记录访问控制失败，在适当时提醒管理员（例如，重复失败）。
速率限制 API 和控制器访问，以最⼤限度地减少⾃动攻击⼯具的危害。
注销后，JWT 令牌应在服务器上失效。
失效的访问控制 - 攻击场景⽰例
场景 #1：应⽤程序在访问帐户信息的 SQL 调⽤中使⽤未经验证的数据：
pstmt.setString(1, Parameter("acct"));
结果集结果 = uteQuery();
攻击者只需修改浏览器的“acct”参数即可发送他们想要的任何帐号。如果没有正确验证，攻击者可以访问任何⽤户的帐户。
场景#2：攻击者只是强制浏览到⽬标 URL。访问管理页⾯需要管理员权限。
如果未经⾝份验证的⽤户可以访问任⼀页⾯，则这是⼀个缺陷。如果⾮管理员可以访问管理页⾯，这是⼀个缺陷。
A02:2021 – 加密失败概述
上移⼀个位置到#2，以前称为敏感数据暴露，这更像是⼀个⼴泛的症状⽽不是根本原因，重点是与密码学相关的失败（或缺乏密码学）。这往往会导致敏感数据的暴露。值得注意
的CWE包括CWE-259：使⽤硬编码密码、CWE-327：损坏或风险的加密算法和CWE-331 熵不⾜。
加密失败 - 描述
⾸先是确定传输中和静⽌数据的保护需求。例如，密码、信⽤卡号、健康记录、个⼈信息和商业秘密需要额外保护，主要是如果该数据属于隐私法（例如欧盟的通⽤数据保护条例(GDPR)）或法规（例如⾦融数据保护）例如 PCI 数据安全标准 (PCI DSS)。对于所有此类数据：
是否有任何数据以明⽂形式传输？这涉及 HTTP、SMTP 和 FTP 等协议。外部互联⽹流量是危险的。验证所有内部流量，例如，负载平衡器、Web 服务器或后端系统之间的流量。
默认情况下或在较旧的代码中是否使⽤任何旧的或弱的加密算法？
是否正在使⽤默认加密密钥、⽣成或重复使⽤弱加密密钥，或者是否缺少适当的密钥管理或轮换？
是否未强制执⾏加密，例如，是否缺少任何⽤户代理（浏览器）安全指令或标头？
⽤户代理（例如，应⽤程序、邮件客户端）是否不验证收到的服务器证书是否有效？
加密失败 - 如何预防
⾄少执⾏以下操作，并查阅参考资料：
对应⽤程序处理、存储或传输的数据进⾏分类。根据隐私法、监管要求或业务需求确定哪些数据是敏感的。
根据分类应⽤控制。
不要不必要地存储敏感数据。尽快丢弃它或使⽤符合 PCI DSS 的标记化甚⾄截断。未保留的数据不能被窃取。
确保加密所有静态敏感数据。
确保拥有最新且强⼤的标准算法、协议和密钥；使⽤适当的密钥管理。
使⽤安全协议（例如具有完美前向保密 (PFS) 密码的 TLS、服务器的密码优先级和安全参数）加密所有传输中的数据。使⽤ HTTP 严格传输安全 (HSTS) 等指令强制加密。
对包含敏感数据的响应禁⽤缓存。
使⽤具有⼯作因⼦（延迟因⼦）的强⾃适应和加盐散列函数存储密码，例如 Argon2、scrypt、bcrypt 或 PBKDF2。
独⽴验证配置和设置的有效性。
加密失败 - 攻击场景⽰例
场景#1：应⽤程序使⽤⾃动数据库加密对数据库中的信⽤卡号进⾏加密。但是，此数据在检索时会⾃动解密，从⽽允许 SQL 注⼊缺陷以明⽂形式检索信⽤卡号。
场景#2：站点不使⽤或对所有页⾯强制执⾏ TLS 或⽀持弱加密。攻击者监视⽹络流量（例如，在不安全的⽆线⽹络中），将连接从 HTTPS 降级为 HTTP，拦截请求并窃取⽤户的会话 cookie。然后攻击者重放这个 cookie 并劫持⽤户的（经过⾝份验证的）会话，访问或修改⽤户的私⼈数据。除了上述之外，他们还可以更改所有传输的数据，例如，汇款的接收者。
场景#3：密码数据库使⽤未加盐或简单的哈希来存储每个⼈的密码。⽂件上传缺陷允许攻击者检索密码数据库。所有未加盐的哈希值都可以通过预先计算的哈希值彩虹表公开。由简单或快速散列函数⽣成的散列可能会被 GPU 破解，即使它们被加盐。
A03:2021 – 注⼊概述
注射向下滑动到第三个位置。94% 的应⽤程序都针对某种形式的注⼊进⾏了测试。值得注意的CWE包括CWE-79：跨站点脚本、CWE-89：SQL 注⼊和CWE-73：⽂件名或路径的外部控制。
注⼊ - 描述
应⽤程序在以下情况下容易受到攻击：
应⽤程序不会验证、过滤或清理⽤户提供的数据。
没有上下⽂感知转义的动态查询或⾮参数化调⽤直接在解释器中使⽤。
在对象关系映射 (ORM) 搜索参数中使⽤恶意数据来提取额外的敏感记录。
直接使⽤或连接恶意数据。SQL 或命令包含动态查询、命令或存储过程中的结构和恶意数据。
⼀些更常见的注⼊是 SQL、NoSQL、OS 命令、对象关系映射 (ORM)、LDAP 和表达式语⾔ (EL) 或对象图导航库 (OGNL) 注⼊。这个概念在所有⼝译员中都是相同的。源代码审查是检测应⽤程序是否容易受到注⼊攻击的最佳⽅法。强烈建议对所有参数、标头、URL、cookie、JSON、SOAP 和 XML 数据输
⼊进⾏⾃动化测试。组织可以将静态源 (SAST) 和动态应⽤程序测试 (DAST) ⼯具包含到 CI/CD 管道中，以在⽣产部署之前识别引⼊的注⼊缺陷。
注⼊ - 如何预防
防⽌注⼊需要将数据与命令和查询分开。
⾸选选项是使⽤安全的 API，它完全避免使⽤解释器，提供参数化接⼝，或迁移到对象关系映射⼯具 (ORM)。
注意：即使在参数化时，如果 PL/SQL 或 T-SQL 连接查询和数据或使⽤ EXECUTE IMMEDIATE 或 exec() 执⾏恶意数据，则存储过程仍然会引⼊ SQL 注⼊。
使⽤正⾯或“⽩名单”服务器端输⼊验证。这不是⼀个完整的防御，因为许多应⽤程序需要特殊字符，例如⽂本区域或移动应⽤程序的 API。
对于任何残留的动态查询，使⽤该解释器的特定转义语法转义特殊字符。
注意：表名、列名等 SQL 结构不能转义，因此⽤户提供的结构名是危险的。这是报告编写软件中的常见问题。
在查询中使⽤ LIMIT 和其他 SQL 控件以防⽌在 SQL 注⼊的情况下⼤量披露记录。
注⼊ - 攻击场景⽰例
场景 #1：应⽤程序在构建以下易受攻击的 SQL 调⽤时使⽤不受信任的数据：
String query = "SELECT * FROM accounts WHERE custID='" + Parameter("id") + "'";
场景#2：类似地，应⽤程序对框架的盲⽬信任可能会导致查询仍然存在漏洞（例如，Hibernate 查询语⾔ (HQL)）：
Query HQLQuery = ateQuery("FROM accounts WHERE custID='" + Parameter("id") + "'");
在这两种情况下，攻击者都会修改浏览器中的 'id' 参数值以发送：' 或 '1'='1。例如：
这将更改两个查询的含义以返回帐户表中的所有记录。更危险的攻击可能会修改或删除数据，甚⾄调⽤存储过程。
A04:2021 – 不安全的设计概述
web服务器是什么服务器
2021 年的新类别侧重于与设计和架构缺陷相关的风险，并呼吁更多地使⽤威胁建模、安全设计模式和参考架构。值得注意的CWE包括CWE-209：⽣成包含敏感信息的错误消息、CWE-256：未受保护的凭证存储、CWE-501：信任边界违规和CWE-522：受保护的凭证不⾜。
不安全的设计 - 描述
不安全设计是⼀个⼴泛的类别，代表许多不同的弱点，表现为“缺失或⽆效的控制设计”。缺少不安全的设计是缺少控制的地⽅。例如，想象⼀下应该加密敏感数据的代码，但没有⽅法。⽆效的不安全设计是可以实现威胁的地⽅，但域（业务）逻辑验证不⾜会阻⽌该操作。例如，假设域逻辑应该根据收⼊等级处理流⾏病税收减免，但不验证所有输⼊都已正确签名并提供⽐应授予的更重要的减免收益。
安全设计是⼀种⽂化和⽅法，它不断评估威胁并确保代码经过稳健设计和测试，以防⽌已知的攻击⽅法。安全设计需要安全的开发⽣命周期、某种形式的安全设计模式或铺砌道路组件库或⼯具，以及威胁建模。
不安全的设计 - 如何预防
与 AppSec 专业⼈员建⽴并使⽤安全的开发⽣命周期，以帮助评估和设计与安全和隐私相关的控制
建⽴和使⽤安全设计模式库或准备使⽤组件的铺好的道路
将威胁建模⽤于关键⾝份验证、访问控制、业务逻辑和关键流
编写单元和集成测试以验证所有关键流都能抵抗威胁模型
不安全的设计 - 攻击场景⽰例
场景 #1：凭证恢复⼯作流程可能包括“问答”，这是 NIST 800-63b、OWASP ASVS 和 OWASP Top 10 所禁⽌的。不能将问答作为多个⼈⾝份的证据可以知道答案，这就是为什么它们被禁⽌。此类代码应删除并替换为更安全的设计。
场景#2：连锁影院允许团体预订折扣，并且在要求押⾦之前最多有 15 名参与者。攻击者可以对该流程进⾏威胁建模，并测试他们是否可以在⼏次请求中⼀次预订 600 个座位和所有电影院，从⽽造成巨⼤的收⼊损失。
场景 #3：零售连锁店的电⼦商务⽹站没有针对由黄⽜运⾏的机器⼈提供保护，这些机器⼈购买⾼端显卡以转售拍卖⽹站。这对视频卡制造商和零售连锁店主造成了可怕的宣传，并与⽆法以任何价格获得这些卡的爱好者之间产⽣了仇恨。仔细的反机器⼈设计和域逻辑规则，例如在可⽤性的⼏秒钟内进⾏的购买，可能会识别出不真实的购买并拒绝此类交易。
A05:2021 – 安全配置错误概述
从上⼀版的第 6 位开始，90% 的应⽤程序都经过了某种形式的错误配置测试。随着更多转向⾼度可配置的软件，看到这⼀类别上升也就不⾜为奇了。值得注意的CWE包括CWE-16 Configuration和CWE-611 Improper Restriction of XML External Entity Reference。
安全配置错误 - 描述
如果应⽤程序是：
在应⽤程序堆栈的任何部分缺少适当的安全强化或对云服务的权限配置不正确。
启⽤或安装了不必要的功能（例如，不必要的端⼝、服务、页⾯、帐户或权限）。
默认帐户及其密码仍处于启⽤状态且未更改。
错误处理向⽤户显⽰堆栈跟踪或其他信息过多的错误消息。
对于升级的系统，最新的安全功能被禁⽤或未安全配置。
应⽤程序服务器、应⽤程序框架（例如，Struts、Spring、ASP.NET）、库、数据库等中的安全设置未设置为安全值。
服务器不发送安全标头或指令，或者它们未设置为安全值。
软件已过时或易受攻击（请参阅 A06:2021-易受攻击和过时的组件）。
如果没有协调⼀致的、可重复的应⽤程序安全配置过程，系统将⾯临更⾼的风险。
安全配置错误 - 如何预防
应实施安全安装过程，包括：
可重复的强化过程使部署另⼀个适当锁定的环境变得快速⽽轻松。开发、QA 和⽣产环境都应配置相同，在每个环境中使⽤不同的凭据。这个过程应该是⾃动化的，以最⼤限度地减少设置新安全环境所需的⼯作。
⼀个没有任何不必要的功能、组件、⽂档和⽰例的最⼩平台。删除或不安装未使⽤的功能和框架。
作为补丁管理流程的⼀部分，审查和更新适⽤于所有安全说明、更新和补丁的配置的任务（请参阅 A06:2021-易受攻击和过时的组件）。查看云存储权限（例如，S3 存储桶权限）。
分段应⽤程序架构通过分段、容器化或云安全组 (ACL) 在组件或租户之间提供有效且安全的分离。
向客户端发送安全指令，例如安全标头。
验证配置和设置在所有环境中的有效性的⾃动化过程。
安全配置错误 - 攻击场景⽰例
场景#1：应⽤程序服务器带有未从⽣产服务器中删除的⽰例应⽤程序。这些⽰例应⽤程序具有攻击者⽤来破坏服务器的已知安全漏洞。假设这些应⽤程序之⼀是管理控制台，并且默
认帐户未更改。在这种情况下，攻击者使⽤默认密码登录并接管。
场景#2：服务器上没有禁⽤⽬录列表。攻击者发现他们可以简单地列出⽬录。攻击者到并下载已编译的 Java 类，对其进⾏反编译和逆向⼯程以查看代码。然后攻击者发现应⽤程序中存在严重的访问控制缺陷。
场景#3：应⽤服务器的配置允许将详细的错误消息（例如堆栈跟踪）返回给⽤户。这可能会暴露敏感信息或潜在缺陷，例如已知易受攻击的组件版本。
场景#4：云服务提供商拥有其他 CSP ⽤户对 Internet 开放的默认共享权限。这允许访问存储在云存储中的敏感数据。
A06:2021 – 易受攻击和过时的组件概述
它在⾏业调查中排名第⼆，但也有⾜够的数据通过数据进⼊前 10 名。易受攻击的组件是我们难以测试和评估风险的已知问题，并且是唯⼀没有任何 CVE 映射到包含的 CWE 的类
别，因此使⽤默认的漏洞利⽤/影响权重 5.0。值得注意的CWE包括CWE-1104：使⽤未维护的第三⽅组件和来⾃ 2013 年和 2017 年前 10 名的两个 CWE。
易受攻击和过时的组件 - 描述
你可能很脆弱：
如果您不知道您使⽤的所有组件的版本（客户端和服务器端）。这包括您直接使⽤的组件以及嵌套的依赖项。
如果软件易受攻击、不受⽀持或已过期。这包括操作系统、Web/应⽤程序服务器、数据库管理系统 (DBMS)、应⽤程序、API 和所有组件、运⾏时环境和库。
如果您不定期扫描漏洞并订阅与您使⽤的组件相关的安全公告。
如果您没有以基于风险的⽅式及时修复或升级底层平台、框架和依赖项。这通常发⽣在修补是变更控制下的每⽉或每季度任务的环境中，使组织⾯临数天或数⽉不必要地暴露于固定漏洞的风险。
如果软件开发⼈员不测试更新、升级或修补的库的兼容性。
如果您不保护组件的配置（请参阅 A05:2021-安全配置错误）。
易受攻击和过时的组件 - 如何预防
应该有⼀个补丁管理流程来：
删除未使⽤的依赖项、不必要的功能、组件、⽂件和⽂档。
使⽤版本、OWASP Dependency Check、retire.js 等⼯具持续清点客户端和服务器端组件（例如框架、库）及其依赖项的版本。成分。使⽤软件组合分析⼯具来⾃动化该过程。订阅与您使⽤的组件相关的安全漏洞的电⼦邮件警报。
仅通过安全链接从官⽅来源获取组件。⾸选签名包以减少包含修改后的恶意组件的机会（请参阅 A08:2021-软件和数据完整性故障）。
监视未维护或未为旧版本创建安全补丁的库和组件。如果⽆法打补丁，请考虑部署虚拟补丁来监控、检测或防⽌发现的问题。
每个组织都必须确保在应⽤程序或产品组合的⽣命周期内制定持续的监控、分类和应⽤更新或配置更改的计划。
易受攻击和过时的组件 - 攻击场景⽰例
场景#1：组件通常以与应⽤程序本⾝相同的权限运⾏，因此任何组件中的缺陷都可能导致严重影响。此类缺陷可能是偶然的（例如，编码错误）或有意的（例如，组件中的后门）。
发现的⼀些可利⽤组件漏洞的⽰例是：
CVE-2017-5638 是⼀个 Struts 2 远程代码执⾏漏洞，可以在服务器上执⾏任意代码，已被归咎于重⼤漏洞。
虽然物联⽹ (IoT) 通常很难或不可能修补，但修补它们的重要性可能很⼤（例如，⽣物医学设备）。
有⼀些⾃动化⼯具可以帮助攻击者到未打补丁或配置错误的系统。例如，Shodan IoT 搜索引擎可以帮助您到仍然存在 2014 年 4 ⽉修补的 Heartbleed 漏洞的设备。
A07:2021 – 认证和授权失败概述
以前称为Broken Authentication，此类别从第⼆位下滑，现在包括与识别失败相关的 CWE。包括的值得注意的CWE包括CWE-297：不正确的证书验证与主机不匹配、CWE-287：不正确的⾝份验证和CWE-384：会话固定。
认证和授权失败 - 描述
确认⽤户的⾝份、⾝份验证和会话管理对于防⽌与⾝份验证相关的攻击⾄关重要。如果应⽤程序存在以下情况，则可能存在⾝份验证漏洞：
允许⾃动攻击，例如撞库，其中攻击者拥有有效⽤户名和密码的列表。
允许蛮⼒或其他⾃动攻击。
允许使⽤默认密码、弱密码或众所周知的密码，例如“Password1”或“admin/admin”。
使⽤弱或⽆效的凭据恢复和忘记密码流程，例如⽆法确保安全的“基于知识的答案”。
使⽤纯⽂本、加密或弱散列密码（请参阅 A3:2017-敏感数据暴露）。
缺少或⽆效的多因素⾝份验证。
在 URL 中公开会话 ID（例如，URL 重写）。
成功登录后不要轮换会话 ID。
不会正确地使会话 ID ⽆效。⽤户会话或⾝份验证令牌（主要是单点登录 (SSO) 令牌）在注销或⼀段时间不活动期间未正确失效。
认证和授权失败 - 如何预防
在可能的情况下，实施多因素⾝份验证以防⽌⾃动凭证填充、暴⼒破解和被盗凭证重⽤攻击。
不要使⽤任何默认凭据进⾏交付或部署，尤其是对于管理员⽤户。
实施弱密码检查，例如针对前 10,000 个最差密码列表测试新密码或更改的密码。
将密码长度、复杂性和轮换策略与 NIST 800-63b 的第 5.1.1 节中关于记忆秘密的指南或其他现代的、基于证据的密码策略保持⼀致。
通过对所有结果使⽤相同的消息，确保注册、凭据恢复和 API 路径能够抵御帐户枚举攻击。
限制或增加延迟失败的登录尝试。当检测到凭证填充、暴⼒破解或其他攻击时，记录所有故障并提醒管理员。
使⽤服务器端、安全、内置的会话管理器，在登录后⽣成新的⾼熵随机会话 ID。会话 ID 不应在 URL 中，安全存储，并在注销、空闲和绝对超时后失效。
认证和授权失败 - 攻击场景⽰例
场景#1：凭证填充（使⽤已知密码列表）是⼀种常见的攻击。假设应⽤程序没有实施⾃动化威胁或凭证填充保护。在这种情况下，应⽤程序可以⽤作密码预⾔机来确定凭证是否有效。
场景#2：⼤多数⾝份验证攻击是由于继续使⽤密码作为唯⼀因素⽽发⽣的。⼀经考虑，最佳实践、密码轮换和复杂性要求会⿎励⽤户使⽤和重复使⽤弱密码。建议组织按照 NIST 800-63 停⽌这些做法并使⽤多因素⾝份验证。
场景 #3：应⽤程序会话超时设置不正确。⽤户使⽤公共计算机访问应⽤程序。⽤户没有选择“注销”，⽽是简单地关闭浏览器选项卡并⾛开。攻击者在⼀个⼩时后使⽤同⼀个浏览器，⽽⽤户仍然通过⾝份验证。
A08:2021 – 软件和数据完整性故障概述
2021 年的新类别侧重于在不验证完整性的情况下做出与软件更新、关键数据和 CI/CD 管道相关的假设。来⾃ CVE/CVSS 数据的最⾼加权影响之⼀。著名的CWE包括CWE-502：不可信数据的反序列化、CWE-829：包含不受信任的控制领域的功能和CWE-494：下载没有完整性检查的代码。
软件和数据完整性故障 - 描述
软件和数据完整性故障与不能防⽌完整性违规的代码和基础设施有关。例如，在对象或数据被编码或序列化为攻击者可以看到和修改的结构的情况下，很容易受到不安全的反序列化的影响。另⼀种形式是应⽤程序依赖来⾃不受信任的来源、存储库和内容交付⽹络 (CDN) 的插件、库或模块。不安全的 CI/CD 管道可能会导致未经授权的访问、恶意代码或系统受损。最后，许多应⽤程序现在包括⾃动更新功能，其中更新在没有充分完整性验证的情况下被下载并应⽤于以前受信任的应⽤程序。攻击者可能会上传⾃⼰的更新以分发并在所有安装上运⾏。
软件和数据完整性故障 - 如何预防
确保未签名或未加密的序列化数据不会在没有某种形式的完整性检查或数字签名的情况下发送到不受信任的客户端，以检测序列化数据的篡改或重放
通过签名或类似机制验证软件或数据来⾃预期来源
确保库和依赖项（例如 npm 或 Maven）使⽤受信任的存储库
确保使⽤软件供应链安全⼯具（例如 OWASP Dependency Check 或 OWASP CycloneDX）来验证组件不包含已知漏洞
确保您的 CI/CD 管道具有正确的配置和访问控制，以确保流经构建和部署过程的代码的完整性。
软件和数据完整性故障 - 攻击场景⽰例
场景 #1 不安全的反序列化： React 应⽤程序调⽤⼀组 Spring Boot 微服务。作为函数式程序员，他们试图确保他们的代码是不可变的。他们提出的解决⽅案是序列化⽤户状态并在每个请求中来回传递它。攻击者注意到“R00”Java 对象签名并使⽤ Java Serial Killer ⼯具在应⽤服务器上获取远程代码执⾏权。
场景 #2 ⽆需签名即可更新：许多家⽤路由器、机顶盒、设备固件和其他固件不通过签名固件验证更新。未签名固件是攻击者越来越多的⽬标，预计只会变得更糟。这是⼀个主要问题，因为很多时候除了在未来版本中修复并等待以前的版本过时之外，没有任何补救机制。
场景#3 SolarWinds 恶意更新：众所周知，国家会攻击更新机制，最近的⼀次著名攻击是 SolarWinds Orion 攻击。开发该软件的公司拥有安全的构建和更新完整性流程。尽管如此，这些还是能够被破坏，并且在⼏个⽉的时间⾥，该公司向 18,000 多个组织分发了⼀个⾼度针对性的恶意更新，其中⼤约 100
个组织受到了影响。这是历史上此类性质最深远、最重⼤的违规⾏为之⼀。
A09:2021 – 安全⽇志记录和监控失败概述
安全⽇志记录和监控来⾃⾏业调查（#3），⽐ 2017 年 OWASP 前 10 名中的第⼗位略有上升。⽇志记录和监控可能很难测试，通常涉及采访或询问是否在渗透测试期间检测到攻击。此类别的 CVE/CVSS 数据不多，但检测和响应漏洞⾄关重要。尽管如此，它对于可见性、事件警报和取证仍然⾮常有影响⼒。此类别扩展到CWE-778 ⽇志记录不⾜之外，包括CWE-117 ⽇志的不当输出中和、CWE-223 安全相关信息的遗漏和CWE-532将敏感信息插⼊⽇志⽂件。
安全⽇志记录和监控失败 - 描述
回到 2021 年 OWASP 前 10 名，该类别旨在帮助检测、升级和响应主动违规⾏为。如果没有⽇志记录和监控，就⽆法检测到漏洞。任何时候都会发⽣⽇志记录、检测、监控和主动响应不⾜的情况：
不记录可审计的事件，例如登录、失败登录和⾼价值交易。
警告和错误不会⽣成、不充分或不清楚的⽇志消息。
不会监控应⽤程序和 API 的⽇志是否存在可疑活动。
⽇志仅存储在本地。
适当的警报阈值和响应升级流程没有到位或有效。
DAST ⼯具（例如 OWASP ZAP）的渗透测试和扫描不会触发警报。
应⽤程序⽆法实时或接近实时地检测、升级或警告主动攻击。
通过使⽤户或攻击者可以看到⽇志记录和警报事件，您很容易受到信息泄漏的影响（请参阅 A01:2021 – 损坏的访问控制）。
安全⽇志记录和监控失败 - 如何预防
开发⼈员应实施以下部分或全部控制措施，具体取决于应⽤程序的风险：
确保所有登录、访问控制和服务器端输⼊验证失败都可以⽤⾜够的⽤户上下⽂来记录，以识别可疑或恶意帐户，并保留⾜够的时间以允许延迟取证分析。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。