A01：2021 - 断路控制
因素
| CWEs 映射 | 最高发病率 | Avg 发病率 | Avg 加权利用 | Avg 加权影响 | 最大覆盖率 | Avg 覆盖范围 | 总发生数 | 简历总数 |
|---|---|---|---|---|---|---|---|---|
| 34 | 55.97% | 3.81% | 6.92 | 5.93 | 94.55% | 47.72% | 318,487 | 19,013 |
概述
从第五位上升，94%的应用程序被测试为某种形式的断路控制，平均发生率为3.81%，在贡献的数据集中发生率最高，超过318k。 包括显著的常见弱点列举 （CWEs） 是CWE-200： 敏感信息暴露给未经授权的参与者， CWE-201： 通过发送数据暴露敏感信息， 和CWE-352：跨站点请求伪造。
描述
访问控制执行策略，使用户不能超出其预期权限行事。失败通常会导致未经授权的信息披露、修改或销毁所有数据或在用户限制之外执行业务功能。常见的访问控制漏洞包括：
-
违反最低特权原则或默认拒绝原则，即只应授予特定功能、角色或用户访问权限，但任何人都可访问。
-
通过修改 URL（参数篡改或强制浏览）、内部应用程序状态或 HTML 页面，或使用修改 API 请求的攻击工具来绕过访问控制检查。
-
通过提供其唯一标识符（不安全的直接对象引用）允许查看或编辑他人帐户
-
访问 API 时缺少邮政、PUT 和删除的访问控制。
-
特权的提升。在以用户身份登录时，无需登录即可充当用户或作为管理员。
-
元数据操作，如重播或篡改 JSON Web 令牌（ JWT ）访问控制令牌，或纵以提升特权或滥用 JWT 失效的 Cookie 或隐藏字段。
-
CORS 配置错误允许从未经授权/不信任的源头访问 API。
-
强制以未经授权的用户身份浏览经过验证的页面，或以标准用户身份访问特权页面。
如何预防
访问控制仅在受信任的服务器端代码或无服务器 API 中有效，攻击者无法修改访问控制检查或元数据。
-
除了公共资源，默认拒绝。
-
实施一次访问控制机制，并在整个应用程序中重复使用这些机制，包括最大限度地减少跨源资源共享 （CORS） 的使用。
-
模型访问控制应强制执行记录所有权，而不是接受用户可以创建、读取、更新或删除任何记录。
-
域名模型应强制执行唯一的应用程序业务限制要求。
-
禁用 Web 服务器目录列表并确保 Web 根中不存在文件元数据（例如.git）和备份文件。
-
记录访问控制故障，在适当的时候提醒管理员（例如重复故障）。
-
速率限制 API 和控制器访问，以最大限度地减少自动攻击设备造成的伤害。
-
注销后，服务器上应使状态会话标识符失效。无状态 JWT 代币应是短暂的，以便最大限度地减少攻击者的机会之窗。对于寿命较长的 Jwts， 建议遵循 Oauth 标准来撤销访问权限。
开发人员和 QA 员工应包括功能访问控制单元和集成测试。
示例攻击方案
方案 #1：该应用程序在访问帐户信息的 SQL 呼叫中使用未经验证的数据：
pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
攻击者只需修改浏览器的"acct"参数即可发送所需的任何帐号。如果未正确验证，攻击者可以访问任何用户的帐户。
https://example.com/app/accountInfo?acct=notmyacct
方案 #2：攻击者只需强制浏览即可瞄准网网。访问管理员页面需要管理权限。
https://example.com/app/getappInfo
https://example.com/app/admin_getappInfo
如果未经授权的用户可以访问任一页面，则这是一个缺陷。如果非管理员可以访问管理员页面，则这是一个缺陷。
A02：2021 - 加密故障
因素
| CWEs 映射 | 最高发病率 | Avg 发病率 | Avg 加权利用 | Avg 加权影响 | 最大覆盖率 | Avg 覆盖范围 | 总发生数 | 简历总数 |
|---|---|---|---|---|---|---|---|---|
| 29 | 46.44% | 4.49% | 7.29 | 6.81 | 79.33% | 34.85% | 233,788 | 3,075 |
概述
将一个位置移到 #2，以前称为敏感数据曝光，这更像是一个广泛的症状，而不是根本原因，重点是与加密（或缺乏加密）相关的故障。这通常会导致敏感数据的暴露。包括著名的常见弱点列举 （CWEs） 是CWE-259： 使用硬编码密码， CWE-327： 破碎或危险的加密算法， 和CWE-331 熵不足。
描述
首先要确定传输和休息中数据的保护需求。例如，密码、信用卡号、健康记录、个人信息和商业机密需要额外的保护，主要是如果这些数据属于隐私法，例如欧盟的一般数据保护法规 （GDPR），或法规，例如 PCI 数据安全标准 （PCI DSS） 等财务数据保护。对于所有这些数据：
-
是否有以清晰文本传输的数据？这涉及到诸如 HTTP、SMTP、FTP 等协议，以及使用 TLS 升级（如 STARTTLS）。外部互联网流量是危险的。验证所有内部流量，例如负载平衡器、Web 服务器或后端系统之间的流量。
-
默认代码或旧代码是否使用任何旧的或弱的加密算法或协议？
-
默认加密密钥是否在使用中，生成或重复使用的加密密钥较弱，或者是否缺少适当的密钥管理或旋转？加密密钥已检查到源代码存储库吗？
-
加密是否未强制执行，例如，是否缺少任何 HTTP 头（浏览器）安全指令或头？
-
收到的服务器证书和信任链是否经过了适当的验证？
-
初始化向量是否被忽略、重复使用或生成对于加密操作模式的足够安全？欧洲央行等不安全的运营模式是否在使用中？认证加密时是否更合适？
-
在没有密码基键推导功能的情况下，密码被用作加密密钥吗？
-
随机性是否用于加密目的，而未设计为满足加密要求？即使选择了正确的函数，是否需要由开发人员进行播种，如果没有，开发人员是否过度编写了强大的种子功能，而种子缺乏足够的熵/不可预测性？
-
是否正在使用已弃用的散第奇函数（如 MD5 或 SHA1）或在需要加密散正函数时是否使用非加密散哈希函数？
-
弃用的加密填充方法（如 PCKS 1 v1.5）在使用吗？
-
加密错误消息或侧通道信息是否可被利用，例如以填充预言家攻击的形式？
请参阅 ASVS 加密 （V7）、数据保护 （V9） 和 SSL/TLS （V10）
如何预防
至少做以下工作，并查阅参考文献：
-
对应用程序处理、存储或传输的数据进行分类。根据隐私保护法、监管要求或业务需求确定哪些数据是敏感的。
-
不要不必要地存储敏感数据。尽快丢弃它或使用符合 PCI DSS 的令牌化，甚至截断。未保留的数据不能被盗。
-
请务必加密所有敏感数据。
-
确保最新的、强大的标准算法、协议和密钥到位;使用适当的密钥管理。
-
通过安全协议（如 TLS）加密所有传输中的数据，包括前向保密 （FS） 密码、服务器优先级密码和安全参数。使用 HTTP 严格运输安全 （HSTS） 等指令强制执行加密。
-
禁用缓存以响应包含敏感数据。
-
根据数据分类应用所需的安全控制。
-
不要使用旧协议（如 FTP 和 SMTP）来传输敏感数据。
-
使用具有工作因子（延迟因子）的强自适应和盐渍哈希功能存储密码，如 Argon2、刺骨、bcrypt 或 PBKDF2。
-
初始化向量必须选择适合操作模式的向量。对于许多模式，这意味着使用 CSPRNG（加密安全伪随机数生成器）。对于需要 nonce 的模式，则初始化矢量 （IV） 不需要 CSPRNG。在所有情况下，IV 都不应用于固定密钥两次。
-
始终使用经过验证的加密，而不仅仅是加密。
-
密钥应以加密方式随机生成，并作为字段阵列存储在内存中。如果使用密码，则必须通过适当的密码基键源功能将其转换为密钥。
-
确保在适当情况下使用加密随机性，并且它没有以可预测的方式或低熵播种。大多数现代 API 并不要求开发人员播种 CSPRNG 以获得安全性。
-
避免弃用加密功能和填充方案，如 MD5、SHA1、PKCS 1 v1.5。
-
独立验证配置和设置的有效性。
示例攻击方案
方案 #1： 应用程序使用自动数据库加密加密数据库中的信用卡号码。但是，当检索到此数据时，会自动解密，从而允许 SQL 注入缺陷以清晰文本检索信用卡号码。
方案 #2： 网站不使用或强制执行所有页面的 TLS 或支持弱加密。攻击者监控网络流量（例如，在不安全的无线网络中），将连接从 HTTPS 降级到 HTTP，拦截请求并窃取用户的会话 Cookie。然后，攻击者重播此 Cookie 并劫持用户的（经过验证的）会话、访问或修改用户的私人数据。而不是上述，他们可以改变所有传输的数据，例如，汇款的接收者。
方案 #3： 密码数据库使用无盐或简单的哈希来存储每个人的密码。文件上传缺陷允许攻击者检索密码数据库。所有无盐的哈希都可以暴露在预先计算的哈希彩虹表。由简单或快速的哈希功能生成的哈希可能由 GPU 破解，即使它们被盐化。
引用
映射 CES 列表
CWE-720 OWASP 2007 年十大 A9 类 - 不安全通信
A03：2021 * 注射
因素
| CWEs 映射 | 最高发病率 | Avg 发病率 | Avg 加权利用 | Avg 加权影响 | 最大覆盖率 | Avg 覆盖范围 | 总发生数 | 简历总数 |
|---|---|---|---|---|---|---|---|---|
| 33 | 19.09% | 3.37% | 7.25 | 7.15 | 94.04% | 47.90% | 274,228 | 32,078 |
概述
注射滑落到第三位置。94% 的应用进行了某种形式的注射测试，最高发病率为 19%，平均发病率为 3%，发生 274k。包括著名的常见弱点列举 （CWEs） 是CWE-79： 跨站点脚本， CWE-89： SQL 注射， 和CWE-73： 文件名称或路径的外部控制。
描述
应用程序易受攻击时：
-
用户提供的数据未经应用程序验证、过滤或消毒。
-
在口译员中直接使用动态查询或非参数化呼叫，而无需上下文感知逃逸。
-
敌对数据用于对象关系映射 （ORM） 搜索参数，以提取其他敏感记录。
-
敌对数据直接使用或串联。SQL 或命令包含动态查询、命令或存储程序中的结构和恶意数据。
一些更常见的注射是 SQL、NoSQL、操作系统命令、对象关系映射 （ORM）、LDAP 和表达语言 （EL） 或对象图形导航库 （OGNL） 注射。所有口译员的概念都是一样的。源代码审查是检测应用程序是否易受注射的最佳方法。强烈鼓励对所有参数、头、URL、Cookie、JSON、SOAP 和 XML 数据输入进行自动测试。组织可以在 CI/CD 管道中包括静态 （SAST）、动态 （DAST） 和交互式 （IAST） 应用程序安全测试工具，以便在生产部署前识别引入的注入缺陷。
如何预防
防止注射需要将数据与命令和查询分开：
-
首选选项是使用安全的 API，它避免完全使用翻译，提供参数化界面，或迁移到对象关系映射工具 （ORM）。
注意：即使参数化，如果 PL/SQL 或 T-SQL 将查询和数据串联起来，或者执行即时或执行执行（）执行敌对数据，存储的程序仍然可以引入 SQL 注入。 -
使用正数或"白名单"服务器侧输入验证。这不是一个完整的防御，因为许多应用程序需要特殊字符，如文本区域或移动应用程序的 API。
-
对于任何剩余动态查询，使用该翻译的特定逃生语法来逃避特殊字符。
注意：SQL结构（如表名、列名等）无法逃脱，因此用户提供的结构名称是危险的。这是报告编写软件中的常见问题。 -
在查询中使用限制和其他 SQL 控制，以防止在 SQL 注射的情况下大量披露记录。
示例攻击方案
方案 #1：应用程序在构建以下易受攻击的 SQL 呼叫时使用不受信任的数据：
String query = "SELECT \* FROM accounts WHERE custID='" + request.getParameter("id") + "'";
方案 #2：同样，应用程序对框架的盲目信任可能导致仍然易受攻击的查询（例如，冬眠查询语言 （HQL）：例如，Hibernate 查询语言 （HQL））：
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.getParameter("id") + "'");
在这两种情况下，攻击者都会修改浏览器中的"id"参数值以发送："或"1"=1。例如：
http://example.com/app/accountView?id=' or '1'='1
这将更改两个查询的含义，以返回帐户表中的所有记录。更危险的攻击可能会修改或删除数据，甚至调用存储的程序。
引用
映射 CES 列表
CWE-74 下游组件使用的输出中特殊元素的不当中和（"注入"）
CWE-78 操作系统命令中用的特殊元素的不当中和（"操作系统命令注入"）
CWE-79 在网页生成期间输入的不当中和（"跨站点脚本"）
CWE-80 在网页（基本 XSS）中不当中和脚本相关 HTML 标签
CWE-89 对 SQL 命令中使用的特殊元素的不当中和（"SQL 注射"）
CWE-90 对 LDAP 查询中使用的特殊元素的不当中和（"LDAP 注射"）
CWE-95 动态评估代码中指令的不当中和（"Eval 注射"）
CWE-96 静态保存代码中的指令中和不当（"静态代码注入"）
CWE-98 对 PHP 计划中包含/要求声明的文件名的不当控制（"PHP 远程文件包含"）
CWE-113 HTTP 头中CLF序列的不当中和（"HTTP 响应拆分"）
CWE-470 使用外部控制的输入来选择类或代码（"不安全反射"）
CWE-643 在 X 路径表达式中对数据的不当中和（"XPath 注射"）
CWE-652 在 X 奎里表达式中对数据的不当中和（"XQuery 注射"）
[CWE-917 表达语言陈述中使用的特殊元素的不当中和（"表达语言注入"）]（https://cwe.mitre.org/data/definitions/917.html）
A04：2021 - 不安全设计
因素
| CWEs 映射 | 最高发病率 | Avg 发病率 | Avg 加权利用 | Avg 加权影响 | 最大覆盖率 | Avg 覆盖范围 | 总发生数 | 简历总数 |
|---|---|---|---|---|---|---|---|---|
| 40 | 24.19% | 3.00% | 6.46 | 6.78 | 77.25% | 42.51% | 262,407 | 2,691 |
概述
2021 年的新类别侧重于与设计和架构缺陷相关的风险，呼吁更多地使用威胁建模、安全设计模式和参考架构。作为一个社区，我们需要超越编码空间中的"左移"，转向对设计安全原则至关重要的预编码活动。著名的常见弱点列举 （CWEs） 包括CWE-209： 包含敏感信息的错误消息生成， CWE-256： 凭据未受保护的存储， CWE-501： 信任边界违规， 和CWE-522： 保护不足的凭据。
描述
不安全设计是代表不同弱点的广泛类别，表示为"缺少或无效的控制设计"。不安全的设计不是所有其他前 10 名风险类别的来源。不安全的设计与不安全的实现是有区别的。我们区分设计缺陷和实现缺陷是有原因的，它们有着不同的根源和补救。安全设计仍可能存在实现缺陷，导致可能被利用的漏洞。不安全的设计不能通过完美的实现来修复，因为根据定义，从未创建过必要的安全控制来抵御特定的攻击。造成设计不安全的因素之一是缺乏正在开发的软件或系统固有的业务风险分析，因此无法确定需要何种安全设计水平。
需求和资源管理
收集并协商与企业申请的业务要求，包括有关所有数据资产的保密性、完整性、可用性和真实性的保护要求以及预期的业务逻辑。考虑您的应用程序将暴露在外，以及如果您需要隔离租户（此外，访问控制）。编制技术要求，包括功能和非功能性安全要求。规划和协商预算，涵盖所有设计、建造、测试和运营，包括安全活动。
安全设计
安全设计是一种文化和方法，可以不断评估威胁，并确保代码经过精心设计和测试，以防止已知的攻击方法。威胁建模应集成到改进会话（或类似活动）中;查找数据流量、访问控制或其他安全控制的变化。在用户故事开发中确定正确的流程和失败状态，确保它们得到负责任和受影响方的充分理解和同意。分析预期和故障流的假设和条件，确保它们仍然准确和可取。确定如何验证假设并执行正确行为所需的条件。确保结果记录在用户故事中。从错误中吸取教训，提供积极的激励措施，促进改进。安全设计既不是附加组件，也不是可以添加到软件的工具。
安全开发生命周期
安全软件需要安全的开发生命周期、某种形式的安全设计模式、铺路方法、安全组件库、模具和威胁建模。在整个项目和软件维护过程中，在软件项目开始时联系您的安全专家。考虑利用OWASP 软件保证成熟度模型 （SAMM）来帮助构建您的安全软件开发工作。
如何预防
-
与 AppSec 专业人员建立并使用安全开发生命周期，以帮助评估和设计安全和隐私相关控制
-
建立和使用安全设计模式库或准备使用组件的铺面道路
-
使用威胁建模进行关键身份验证、访问控制、业务逻辑和密钥流
-
将安全语言和控件集成到用户故事中
-
在应用程序的每个层（从前端到后端）集成合理性检查
-
编写单元和集成测试，以验证所有关键流量都对威胁模型具有抗性。为应用程序的每个层编译使用案例和误用案例。
-
根据曝光和保护需求，将系统和网络层的层分开
-
通过设计将租户严格隔离到所有层
-
限制用户或服务的资源消耗
示例攻击方案
方案 #1：凭据恢复工作流程可能包括"问题和答案"，NIST 800-63b、OWASP ASVS 和 OWASP 前 10 名禁止使用。问题和答案不能作为身份的证据可信，因为不止一个人可以知道答案，这就是为什么他们被禁止。应删除此类代码，代之以更安全的设计。
方案 #2：电影院连锁店允许团体预订折扣，在需要押金之前最多有十五名观众。攻击者可能会威胁模型这种流动和测试，如果他们可以预订六百个座位和所有电影院一次在几个请求，造成巨大的收入损失。
方案 #3：零售连锁店的电子商务网站没有保护，防止黄牛购买高端视频卡转售拍卖网站经营的机器人。这给视频卡制造商和零售连锁店老板造成了可怕的宣传，也给那些无法不花任何代价获得这些卡的爱好者们带来了不俗的血液。仔细的反机器人设计和域逻辑规则（如在可用后几秒钟内进行购买）可能会识别不真实的购买并拒绝此类交易。
引用
映射 CES 列表
CWE-444 对 HTTP 请求的不一致解释（"HTTP 请求走私"）
CWE-579 J2EE 不良做法：会话中存储的不可串行对象
A05：2021 * 安全配置错误
因素
| CWEs 映射 | 最高发病率 | Avg 发病率 | Avg 加权利用 | Avg 加权影响 | 最大覆盖率 | Avg 覆盖范围 | 总发生数 | 简历总数 |
|---|---|---|---|---|---|---|---|---|
| 20 | 19.84% | 4.51% | 8.12 | 6.56 | 89.58% | 44.84% | 208,387 | 789 |
概述
从上一版本的第 6 名上升至 90% 的应用程序进行了某种形式的错误配置测试，平均发生率为 4.%，在此风险类别中，常见弱项列举 （CWE） 的发生率超过 208k。随着更多转向高度可配置的软件，看到这一类别上升并不奇怪。包括著名的CWES是CWE-16配置和CWE-611不当限制XML外部实体参考。
描述
如果应用程序是：
-
缺少应用程序堆栈任何部分的适当安全硬化或云服务的不当配置权限。
-
启用或安装不必要的功能（例如，不必要的端口、服务、页面、帐户或特权）。
-
默认帐户及其密码仍然启用且保持不变。
-
错误处理向用户显示堆栈痕迹或其他信息过于丰富的错误消息。
-
对于升级后的系统，最新的安全功能会被禁用或无法安全配置。
-
应用服务器、应用程序框架（如 Struts、Spring、ASP.NET）、库、数据库等中的安全设置不设置为安全值。
-
服务器不发送安全头或指令，或者它们未设置为安全值。
-
该软件过时或易受攻击（参见A06：2021-易损和过时组件）。
如果没有一个协调一致的、可重复的应用程序安全配置流程，系统的风险就更高。
如何预防
应实施安全安装流程，包括：
-
可重复的硬化过程使部署另一个被适当锁定的环境变得快速且易于。开发、QA 和生产环境都应配置相同，每个环境中都使用不同的凭据。此过程应实现自动化，以最大限度地减少建立新安全环境所需的努力。
-
一个极简的平台，没有任何不必要的功能，组件，文档和样品。删除或不安装未使用的功能和框架。
-
作为修补程序的一部分，需要审查和更新适用于所有安全注意事项、更新和修补程序的配置（参见A06：2021-易受攻击和过时的组件）。查看云存储权限（例如 S3 存储桶权限）。
-
分段应用架构提供组件或租户之间的有效和安全分离，并具有分割、容器化或云安全组 （ACL）。
-
向客户发送安全指令，例如安全头。
-
验证所有环境中配置和设置的有效性的自动化流程。
示例攻击方案
方案 #1：应用程序服务器附带未从生产服务器中删除的示例应用程序。这些示例应用程序已知攻击者用来破坏服务器的安全缺陷。假设其中一个应用程序是管理员控制台，并且默认帐户未更改。在这种情况下，攻击者会使用默认密码登录并接管。
方案 #2：在服务器上不禁用目录列表。攻击者发现他们可以简单地列出目录。攻击者查找并下载汇编的 Java 类，他们分解并反向工程师来查看代码。然后，攻击者在应用程序中发现严重的访问控制缺陷。
方案 #3：应用服务器的配置允许将详细的错误消息（例如堆栈跟踪）返回给用户。这可能会暴露敏感信息或潜在的缺陷，如已知易受攻击的组件版本。
方案 #4：云服务提供商拥有由其他内容安全策略主管 （CSP） 用户向互联网开放的默认共享权限。这允许访问存储在云存储中的敏感数据。
引用
-
应用安全验证标准 V19 配置
映射 CES 列表
Cwe - 614 敏感饼干在 Https 会话没有 "安全" 属性
CWE-776 不当限制 DTD 中的递归实体引用（"XML 实体扩展"）
Cwe - 1004 敏感饼干没有 "Httponly" 标志
CWE-1032 OWASP 2017 年十大 A6 类 - 安全配置错误
A06：2021 * 易受攻击和过时组件
因素
| CWEs 映射 | 最高发病率 | Avg 发病率 | 最大覆盖率 | Avg 覆盖范围 | Avg 加权利用 | Avg 加权影响 | 总发生数 | 简历总数 |
|---|---|---|---|---|---|---|---|---|
| 3 | 27.96% | 8.77% | 51.78% | 22.47% | 5.00 | 5.00 | 30,457 | 0 |
概述
这是前 10 名社区调查的 #2， 但也有足够的数据， 通过数据进入前 10 名。易受攻击组件是一个已知问题，我们很难测试和评估风险，并且是唯一没有将任何常见弱点列举 （CWEs） 映射到所包含的 CWEs 的类别，因此使用 5.0 的默认漏洞利用/影响权重。包括著名的CWE-1104：使用未维护的第三方组件以及 2013 年和 2017 年前 10 名中的两个 CWEs。
描述
您可能很脆弱：
-
如果您不知道您使用的所有组件（客户端和服务器端）的版本。这包括您直接使用的组件以及嵌套依赖。
-
如果软件易受攻击、不受支持或过时。这包括操作系统、Web/应用程序服务器、数据库管理系统 （DBMS）、应用程序、API 以及所有组件、运行时间环境和库。
-
如果您不定期扫描漏洞并订阅与您使用的组件相关的安全公告。
-
如果您不及时修复或升级基础平台、框架和依赖性。当修补是每月或每季度在更改控制下的任务时，通常会发生这种情况，使组织面临数天或数月的不必要暴露在固定漏洞中。
-
如果软件开发人员不测试更新、升级或修补库的兼容性。
-
如果您无法保护组件的配置（请参阅 A05：2021-安全配置错误）。
如何预防
应有一个修补程序，以：
-
删除未使用的依赖性、不必要的功能、组件、文件和文档。
-
使用版本、OWASP 依赖性检查、退休.js等工具，持续清点客户端和服务器端组件（例如框架、库）及其依赖性版本。持续监控常见漏洞和暴露 （CVE） 和国家漏洞数据库 （NVD） 等源，以了解组件中的漏洞。使用软件组合分析工具自动处理该过程。订阅电子邮件提醒，以获得与您使用的组件相关的安全漏洞。
-
仅通过安全链接从官方来源获取组件。最好使用已签名的包来减少包含修改后的恶意组件（参见 A08：2021-软件和数据完整性故障）的机会。
-
监视未维护或未为旧版本创建安全修补程序的库和组件。如果无法修补，请考虑部署虚拟修补程序以监控、检测或防止发现的问题。
每个组织必须确保持续计划，以便在应用程序或产品组合的使用寿命内进行更新或配置更改。
示例攻击方案
方案 #1：组件通常具有与应用程序本身相同的权限运行，因此任何组件中的缺陷都可能导致严重影响。此类缺陷可能是偶然的（例如编码错误）或故意的（例如组件中的后门）。发现的一些可利用组件漏洞示例包括：
-
CVE-2017-5638 是 Struts 2 远程代码执行漏洞，可在服务器上执行任意代码，被指责为重大违规事件。
-
虽然物联网 （IoT） 经常难以修补或不可能修补，但修补它们的重要性可能很大（例如生物医学设备）。
有自动化工具帮助攻击者查找未修补或配置错误的系统。例如，Shodan 物联网搜索引擎可以帮助您找到在 2014 年 4 月修补的仍患有心血漏洞的设备。
引用
-
OWASP 应用安全验证标准：V1 架构、设计和威胁建模
-
OWASP 依赖性检查（对于 Java 和.NET 库）
-
OWASP 测试指南 - 地图应用架构 （OTG-INFO-010）
-
OWASP 虚拟修补最佳实践
-
不安全图书馆的不幸现实
-
MITRE 常见漏洞和暴露 （CVE） 搜索
-
国家漏洞数据库
-
退休.js检测已知的易受攻击的 JavaScript 库
-
节点库安全建议
-
https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf
映射 CES 列表
CWE-937 OWASP 2013 年十大前 10 名：使用已知漏洞的组件
CWE-1035 2017 前 10 名 A9：使用已知漏洞的组件
CWE-1104 使用未维护的第三方组件
A07：2021 - 识别和身份验证失败
因素
| CWEs 映射 | 最高发病率 | Avg 发病率 | Avg 加权利用 | Avg 加权影响 | 最大覆盖率 | Avg 覆盖范围 | 总发生数 | 简历总数 |
|---|---|---|---|---|---|---|---|---|
| 22 | 14.84% | 2.55% | 7.40 | 6.50 | 79.51% | 45.72% | 132,195 | 3,897 |
概述
以前称为"破碎身份验证"，此类别从第二位滑落，现在包括与标识故障相关的常见弱点列举 （CWEs）。包括著名的CWES是CWE-297：与主机不匹配的证书的不当验证，CWE-287：不当认证，和CWE-384：会话固定。
描述
确认用户的身份、身份验证和会话管理对于防止与身份验证相关的攻击至关重要。如果应用存在身份验证缺陷：
-
允许自动攻击，如凭据填充，攻击者有有效的用户名和密码列表。
-
允许暴力或其他自动攻击。
-
允许默认、弱或众所周知的密码，如"密码 1"或"管理员/管理员"。
-
使用弱或无效的凭据恢复和忘记密码过程，如"基于知识的答案"，这些程序无法安全。
-
使用纯文本、加密或弱哈希密码数据存储（参见A02：2021-加密故障）。
-
已缺少或无效的多因素身份验证。
-
在 URL 中暴露会话标识符。
-
成功登录后重复使用会话标识符。
-
未正确使会话 ID 无效。用户会话或身份验证令牌（主要是单个登录 （SSO） 令牌）在注销期间或非活动期间未正确失效。
如何预防
-
在可能的情况下，实施多因素身份验证，以防止自动凭据填充、暴力和被盗凭据重用攻击。
-
不要随任何默认凭据发货或部署，尤其是对于管理员用户。
-
实施弱密码检查，例如对前 10，000 个最差密码列表测试新密码或更改密码。
-
将密码长度、复杂性和旋转策略与 N 对齐
-
国家标准与技术研究所 （NIST） 800-63b 的准则，第 5.1.1 节中关于记忆秘密或其他基于证据的现代密码策略。
-
通过对所有结果使用相同的消息，确保注册、凭据恢复和 API 路径针对帐户列举攻击进行硬化。
-
限制或越来越多地延迟失败的登录尝试，但请注意不要创建拒绝服务场景。当检测到凭据填充、暴力或其他攻击时，记录所有故障并提醒管理员。
-
使用服务器端、安全、内置的会话管理器，该管理器在登录后生成具有高熵的新随机会话 ID。会话标识符不应位于 URL 中，应安全地存储，并在注销、怠速和绝对超时后失效。
示例攻击方案
方案 #1：凭据填充，使用已知密码列表，是一种常见的攻击。假设应用程序不实施自动威胁或凭据填充保护。在这种情况下，应用程序可以用作密码预言家，以确定凭据是否有效。
方案 #2：大多数身份验证攻击都是由于继续使用密码作为唯一因素而发生的。一旦考虑，最佳实践、密码旋转和复杂性要求鼓励用户使用和重复使用弱密码。建议组织根据 NIST 800-63 停止这些做法，并使用多因素身份验证。
方案 #3：应用会话超时设置不正确。用户使用公共计算机访问应用程序。用户只需关闭浏览器选项卡并走开，即可选择"注销"。攻击者在一小时后使用相同的浏览器，用户仍然经过身份验证。
引用
-
尼斯特 800-63b： 5.1.1 记忆秘密
映射 CES 列表
A08：2021 * 软件和数据完整性故障
因素
| CWEs 映射 | 最高发病率 | Avg 发病率 | Avg 加权利用 | Avg 加权影响 | 最大覆盖率 | Avg 覆盖范围 | 总发生数 | 简历总数 |
|---|---|---|---|---|---|---|---|---|
| 10 | 16.67% | 2.05% | 6.94 | 7.94 | 75.04% | 45.35% | 47,972 | 1,152 |
概述
2021 年的新类别侧重于在不验证完整性的情况下做出与软件更新、关键数据和 CI/CD 管道相关的假设。常见漏洞和暴露/常见漏洞评分系统 （CVE/CVSS） 数据中权重最高的影响之一。著名的常见弱点列举 （CWEs） 包括CWE-829： 包含来自不受信任控制领域的功能，CWE-494： 下载代码无完整性检查， 和CWE-502： 取消不可信数据的去系统化。
描述
软件和数据完整性故障与无法防止违反完整性的代码和基础架构有关。这方面的一个例子是，应用程序依赖于来自不受信任的源、存储库和内容交付网络 （CDN） 的插件、库或模块。不安全的 CI/CD 管道可能会带来未经授权的访问、恶意代码或系统泄露。最后，许多应用程序现在包括自动更新功能，其中更新下载时没有进行足够的完整性验证，并应用于以前受信任的应用程序。攻击者可能会上传自己的更新，以便在所有安装上分发和运行。另一个例子是，对象或数据被编码或序列化为攻击者可以看到和修改的结构，很容易受到不安全的去系统化的影响。
如何预防
-
使用数字签名或类似机制来验证软件或数据来自预期来源，并且未更改。
-
确保图书馆和依赖，如 npm 或 Maven，正在消耗受信任的存储库。如果您的风险较高，请考虑托管经过审查的内部知名存储库。
-
确保软件供应链安全工具（如 OWASP 依赖性检查或 OWASP CycloneDX）用于验证组件是否不包含已知漏洞
-
确保对代码和配置更改进行审核，以最大限度地减少恶意代码或配置引入软件管道的可能性。
-
确保您的 CI/CD 管道具有适当的隔离、配置和访问控制，以确保代码在构建和部署过程中的完整性。
-
确保未签名或未加密的序列化数据不会在没有某种形式的完整性检查或数字签名的情况下发送给未受信任的客户，以检测序列化数据的篡改或重播
示例攻击方案
场景 #1 更新而不签名：许多家庭路由器、机顶盒、设备固件和其他固件无法通过签名固件验证更新。未签名固件是攻击者不断增长的目标，预计只会变得更糟。这是一个主要问题，因为很多时候，除了在未来的版本中修复和等待以前的版本老化之外，没有其他机制可以补救。
场景 #2 太阳风恶意更新： 众所周知，民族国家攻击更新机制，最近一个值得注意的攻击是太阳风猎户座攻击。开发该软件的公司具有安全的构建和更新完整性流程。尽管如此，这些都能够被颠覆，几个月来，该公司向 18，000 多个组织分发了高度针对性的恶意更新，其中大约 100 个组织受到影响。这是历史上最深远、最严重的违反这一性质的行为之一。
方案 #3 不安全的去航空化：响应应用程序称为一组弹簧靴微服务。作为功能程序员，他们试图确保他们的代码是不变的。他们提出的解决方案是将用户状态序列化，并在每个请求中来回传递。攻击者注意到"rO0"Java 对象签名（在 base64 中），并使用 Java 串行杀手工具在应用程序服务器上获取远程代码执行。
引用
-
[OWASP 备忘单：软件供应链安全]（即将推出）
-
[OWASP 备忘单：安全构建和部署]（即将推出）
映射 CES 列表
CWE-784 在安全决策中无需验证和完整性检查即可依赖 Cookie
A09：2021 - 安全记录和监控故障
因素
| CWEs 映射 | 最高发病率 | Avg 发病率 | Avg 加权利用 | Avg 加权影响 | 最大覆盖率 | Avg 覆盖范围 | 总发生数 | 简历总数 |
|---|---|---|---|---|---|---|---|---|
| 4 | 19.23% | 6.51% | 6.87 | 4.99 | 53.67% | 39.97% | 53,615 | 242 |
概述
安全记录和监控来自前 10 名社区调查 （#3），略高于 OWASP 2017 年十大社区调查的第十位。记录和监控可能具有测试挑战性，通常涉及访谈或询问是否在渗透测试期间检测到攻击。此类别的 CVE/CVSS 数据不多，但检测和响应违规至关重要。不过，它对问责制、能见度、事件警报和取证的影响可能非常大。此类别扩展到CWE-778 不足记录范围，包括CWE-117 日志不当输出中和、CWE-223 遗漏安全相关信息以及CWE-532 将敏感信息插入日志文件。
描述
返回到 OWASP 2021 年前 10 名，此类别将帮助检测、升级和响应主动违规。如果没有记录和监控，就无法检测到违规情况。记录、检测、监控和主动响应不足随时发生：
-
未记录可审计事件，如登录、失败登录和高价值交易。
-
警告和错误不会生成不、不充分或不清楚的日志消息。
-
未监测应用和 API 的日志以发现可疑活动。
-
日志仅存储在本地。
-
适当的警报阈值和响应升级过程不到位或无效。
-
动态应用程序安全测试 （DAST） 工具（如 OWASP ZAP）的渗透测试和扫描不会触发警报。
-
应用程序无法实时或接近实时检测、升级或警报主动攻击。
通过使用户或攻击者可见记录和警报事件（参见A01：2021 中断访问控制），您很容易受到信息泄露的影响。
如何预防
开发人员应根据应用程序的风险实施以下部分或全部控制：
-
确保所有登录、访问控制和服务器端输入验证失败都可以在用户上下文中记录，以识别可疑或恶意帐户，并持有足够的时间以允许延迟的取证分析。
-
确保日志以日志管理解决方案可以轻松使用的形式生成。
-
确保对日志数据进行正确编码，以防止注射或攻击记录或监控系统。
-
确保高价值交易具有完整性控制审核跟踪，以防止篡改或删除，例如仅附录数据库表或类似内容。
-
DevSecOps 团队应建立有效的监控和警报，以便发现可疑活动并快速响应。
-
建立或采用事故响应和恢复计划，如国家标准与技术研究所 （NIST） 800-61r2 或更晚。
有商业和开源应用程序保护框架，如 OWASP Mod安全核心规则集，以及开放源日志相关软件，如弹性搜索、日志斯塔什、Kibana （ELK） 堆栈，它们具有自定义仪表板和警报功能。
示例攻击方案
方案 #1：儿童健康计划提供商的网站运营商由于缺乏监控和记录而无法检测到违规情况。一名外部人士告诉健康计划提供者，攻击者访问并修改了数千份350多万儿童的敏感健康记录。事后审查发现，网站开发人员没有解决重大漏洞。由于没有对系统进行记录或监测，数据泄露可能自 2013 年以来一直在进行，时间超过 7 年。
方案 #2：印度一家大型航空公司发生数据泄露事件，涉及数百万乘客超过十年的个人数据，包括护照和信用卡数据。数据泄露发生在第三方云托管提供商处，该提供商在一段时间后将泄露通知了航空公司。
方案 #3：欧洲一家大型航空公司遭受了 GDPR 报告的违规事件。据报道，造成这一漏洞的是攻击者利用的付款应用程序安全漏洞，攻击者获取了 400，000 多份客户付款记录。由于隐私监管机构，这家航空公司被罚款2000万英镑。
引用
映射 CES 列表
A10：2021 - 服务器侧请求伪造 （SSRF）
因素
| CWEs 映射 | 最高发病率 | Avg 发病率 | Avg 加权利用 | Avg 加权影响 | 最大覆盖率 | Avg 覆盖范围 | 总发生数 | 简历总数 |
|---|---|---|---|---|---|---|---|---|
| 1 | 2.72% | 2.72% | 8.28 | 6.72 | 67.72% | 67.72% | 9,503 | 385 |
概述
此类别从前 10 名社区调查 （#1） 中添加。数据显示，发病率相对较低，测试覆盖率高于平均水平，且利用和影响潜在评级高于平均水平。由于新条目可能是一组单一或小的常见弱点枚举 （CWEs）， 以引起关注和提高认识， 希望它们能够成为焦点， 并可以在未来的版本中卷成更大的类别。
描述
每当 Web 应用程序在获取远程资源而未验证用户提供的 URL 时，SSRF 就会出现缺陷。它允许攻击者强制应用程序将精心制作的请求发送到意外目的地，即使受到防火墙、VPN 或其他类型的网络访问控制列表 （ACL） 的保护。
由于现代 Web 应用程序为最终用户提供方便的功能，因此获取 URL 成为常见场景。因此，SSRF的发病率正在增加。此外，由于云服务和架构的复杂性，SSRF 的严重程度越来越高。
如何预防
开发人员可以通过实施以下部分或全部防御进行深度控制来防止 SSRF：
从网络层
-
在单独的网络中细分远程资源访问功能，以减少 SSRF 的影响
-
执行"默认拒绝"防火墙策略或网络访问控制规则，以阻止除基本内联网流量之外的所有流量。
提示：
• 建立基于应用程序的防火墙规则的所有权和生命周期。
• 在防火墙上记录所有已接受和阻止的网络流量（参见A09：2021-安全记录和监控故障）。
从应用层：
-
对所有客户提供的输入数据进行消毒和验证
-
使用正允许列表执行 URL 模式、端口和目的地
-
不要向客户发送原始回复
-
禁用 HTTP 重定向
-
注意 URL 一致性，以避免攻击，如 DNS 重新绑定和"检查时间、使用时间"（TOCTOU）比赛条件
不要通过使用拒绝列表或常规表达来减轻 SSRF。攻击者有有效载荷列表、工具和绕过拒绝列表的技能。
需要考虑的其他措施：
-
不要在前系统（例如 OpenID）上部署其他安全相关服务。控制这些系统上的本地流量（例如本地托管）
-
对于具有专用且可管理用户群的前端，请在独立系统上使用网络加密 （例如 VPN），以考虑非常高的保护需求
示例攻击方案
攻击者可以使用 SSRF 攻击 Web 应用程序防火墙、防火墙或网络 ACL 背后的保护系统，使用以下情景：
方案 #1：端口扫描内部服务器 - 如果网络架构未解密，攻击者可以绘制出内部网络地图，并根据连接结果确定内部服务器上的端口是打开还是关闭，或者超过连接或拒绝 SSRF 有效载荷连接的时间。
方案 #2：敏感数据暴露 - 攻击者可以访问本地文件，如或内部服务，以获得敏感信息，如和 。file:///etc/passwd</span>http://localhost:28017/
方案 #3：访问云服务的元数据存储 - 大多数云提供商都有元数据存储，例如 。攻击者可以读取元数据以获取敏感信息。http://169.254.169.254/
方案 #4：损害内部服务 - 攻击者可能会滥用内部服务进行进一步攻击，如远程代码执行 （RCE） 或拒绝服务 （DoS）。
引用
映射 CES 列表
717
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
