OWASP Top 10 2021

2023-03-22
2023-03-22
24 min read
Hits

  博主前年因工作需要,加了一位厂商好友,昨日突然找到博主说需要一篇网络安全方面比较宏观的论文,博主脑子里就蹦出了这个 OWASP Top 10,于是就借此时机,对最新版 OWASP Top 10(即 2021 版)的网络安全威胁,做一个较为宏(jian)观(dan)的学习吧。

OWASP 是什么?

  要讲 OWASP Top 10,那么肯定要先知道 OWASP 是什么?以下是官方描述

The Open Worldwide Application Security Project® (OWASP) is a nonprofit foundation that works to improve the security of software. Through community-led open-source software projects, hundreds of local chapters worldwide, tens of thousands of members, and leading educational and training conferences, the OWASP Foundation is the source for developers and technologists to secure the web.

                     ——摘自 OWASP 官网

  可参考 OWASP 中国的相关描述

OWASP是一个开源的、非盈利的全球性安全组织,致力于应用软件的安全研究。我们的使命是使应用软件更加安全,使企业和组织能够对应用安全风险做出更清晰的决策。目前OWASP全球拥有250个分部近7万名会员,共同推动了安全标准、安全测试工具、安全指导手册等应用安全技术的发展。

OWASP在业界影响力

  • OWASP 被视为 web 应用安全领域的权威参考。2009 年下列发布的美国国家和国际立法、标准、准则、委员会和行业实务守则参考引用了 OWASP。美国联邦贸易委员会(FTC)强烈建议所有企业需遵循 OWASP 十大 WEB 弱点防护守则
  • 国际信用卡数据安全技术 PCI 标准更将其列为必要组件
  • 为美国国防信息系统局(DISA)应用安全和开发清单参考
  • 为欧洲网络与信息安全局(ENISA), 云计算风险评估参考
  • 为美国联邦首席信息官(CIO)理事会,联邦部门和机构使用社会媒体的安全指南
  • 为美国国家安全局/中央安全局, 可管理的网络计划提供参考
  • 为英国 GovCERTUK 提供 SQL 注入参考
  • 为欧洲网络与信息安全局(ENISA), 云计算风险评估提供参考
  • OWASP TOP 10 为 IBM APPSCAN、HP WEBINSPECT 等扫描器漏洞参考的主要标准

OWASP Top 10 又是什么?

  了解了 OWASP 是什么之后,我们进一步了解,什么是 OWASP Top 10

The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.

                     ——摘自 OWASP 官网

  综上所述,OWASP Top 10 就是 OWASP 这个在网络安全业内较为权威的开源基金会所梳理出的十大网站应用安全风险,颇具学习和参考价值。

OWASP Top 10 2021 与 2017 的变化

  1. Broken Access Control - 失效的访问控制:从第五位上升成为 Web 应用程序安全风险最严重的类别;提供的数据表明,平均 3.81% 的测试应用程序具有一个或多个 CWE,且此类风险中 CWE 总发生漏洞应用数超过 31.8 万次。在应用程序中出现的 34 个匹配为“失效的访问控制”的 CWE 次数比任何其他类别都多。
  2. Cryptographic Failures - 加密机制失效:排名上升一位。其以前被称为“A3:2017-敏感信息泄漏(Sensitive Data Exposure)”。敏感信息泄漏是常见的症状,而非根本原因。更新后的名称侧重于与密码学相关的风险,即之前已经隐含的根本原因。此类风险通常会导致敏感数据泄露或系统被攻破。
  3. Injection - 注入:排名下滑两位。94% 的应用程序进行了某种形式的注入风险测试,发生安全事件的最大率为 19%,平均率为 3.37%,匹配到此类别的 33 个 CWE 共发生 27.4 万次,是出现第二多的风险类别。原“A07:2017-跨站脚本(XSS)”在 2021 年版中被纳入此风险类别。
  4. Insecure Design - 不安全设计:2021 年版的一个新类别,其重点关注与设计缺陷相关的风险。如果我们真的想让整个行业“安全左移”,我们需要更多的威胁建模、安全设计模式和原则,以及参考架构。不安全设计是无法通过完美的编码来修复的;因为根据定义,所需的安全控制从来没有被创建出来以抵御特定的安全攻击。
  5. Security Misconfiguration - 安全配置错误:排名上升一位。90% 的应用程序都进行了某种形式的配置错误测试,平均发生率为 4.5%,超过 20.8 万次的 CWE 匹配到此风险类别。随着可高度配置的软件越来越多,这一类别的风险也开始上升。原“A04:2017-XML External Entities(XXE)XML 外部实体”在 2021 年版中被纳入此风险类别。
  6. Vulnerable and Outdated Components - 自带缺陷和过时的组件:排名上升三位。在社区调查中排名第二。同时,通过数据分析也有足够的数据进入前十名,是我们难以测试和评估风险的已知问题。它是唯一一个没有发生 CVE 漏洞的风险类别。因此,默认此类别的利用和影响权重值为 5.0。原类别命名为“A09:2017-Using Components with Known Vulnerabilities 使用含有已知漏洞的组件”。
  7. Identification and Authentication Failures - 身份识别和身份验证错误:排名下滑五位。原标题“A02:2017-Broken Authentication 失效的身份认证”。现在包括了更多与识别错误相关的 CWE。这个类别仍然是 Top 10 的组成部分,但随着标准化框架使用的增加,此类风险有减少的趋势。
  8. Software and Data Integrity Failures - 软件和数据完整性故障:2021 年版的一个新类别,其重点是:在没有验证完整性的情况下做出与软件更新、关键数据和 CI/CD 管道相关的假设。此类别共有十个匹配的 CWE 类别,并且拥有最高的平均加权影响值。原“A08:2017-Insecure Deserialization 不安全的反序列化”现在是本大类的一部分。
  9. Security Logging and Monitoring Failures - 安全日志和监控故障:排名上升一位。来源于社区调查(排名第三)。原名为“A10:2017-Insufficient Logging & Monitoring 不足的日志记录和监控”。此类别现扩大范围,包括了更多类型的、难以测试的故障。此类别在 CVE/CVSS 数据中没有得到很好的体现。但是,此类故障会直接影响 可见性、事件告警和取证。
  10. Server-Side Request Forgery - 服务端请求伪造:2021 年版的一个新类别,来源于社区调查(排名第一)。数据显示发生率相对较低,测试覆盖率高于平均水平,并且利用和影响潜力的评级高于平均水平。加入此类别风险是说明:即使目前通过数据没有体现,但是安全社区成员告诉我们,这也是一个很重要的风险。

Broken Access Control - 失效的访问控制

  从第五位上升到第一位,94% 的应用程序都接受了某种形式的针对“失效的访问控制”的测试,该事件的平均发生率为 3.81%,该漏洞在提供的数据集中出现漏洞的应用数量最多,总发生漏洞应用数量超过 31.8 万多次。 此类值得注意的常见 CWE 包括: CWE-200:Exposure of Sensitive Information to an Unauthorized Actor(将敏感信息泄漏给未经授权的参与者)、CWE-201:Exposure of Sensitive Information Through Sent Data(通过发送的数据泄漏敏感信息)、CWE-352:Cross-Site Request Forgery (跨站请求伪造)。

风险说明

  访问控制强制实施策略,使用户无法在其预期权限之外进行操作。失败的访问控制通常会导致未经授权的信息泄露、修改或销毁所有数据、或在用户权限之外执行业务功能。常见的访问控制脆弱点包括

  1. 违反最小特权原则或默认拒绝原则,即访问权限应该只授予特定能力、角色或用户,但实际上任何人都可以访问。
  2. 通过修改 URL(参数篡改或强制浏览)、内部应用程序状态或 HTML 页面,或使用修改 API 请求的攻击工具来绕过访问控制检查。
  3. 通过提供唯一标识符(不安全的直接对象引用)允许查看或编辑其他人的帐户
  4. API 没有对 POST、PUT 和 DELETE 强制执行访问控制。
  5. 特权提升。 在未登录的情况下假扮用户或以用户身份登录时充当管理员。
  6. 元数据操作,例如通过重放或篡改 JSON Web 令牌(JWT)来访问控制令牌,或操纵 cookie 或隐藏字段以提升权限,或滥用 JWT 失效。
  7. CORS 配置错误以致允许未授权或不可信的 API 访问。
  8. 以未通过身份验证的用户身份强制浏览的通过身份验证时才能看到的页面或作为标准用户身份访问特权页面。

预防措施

  访问控制只在受信服务器端代码或无服务器 API 中有效,这样攻击者才无法修改访问控制检查或元数据。

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

Cryptographic Failures - 加密机制失效

  上升一位到第二名,以前称为“敏感数据泄漏”。“敏感数据泄漏”更像是一种常见的表象问题而不是根本原因,这项风险重点是与加密机制相关的故障(或缺乏加密机制)。 这往往会导致敏感数据泄漏。 值得注意的常见 CWE 包括:CWE-259:Use of Hard-coded Password(使用硬编码密码)、CWE-327:Broken or Risky Crypto Algorithm(损坏或有风险的加密算法)、CWE-331 Insufficient Entropy(熵不足)。

风险说明

  首先要确认:对传输中数据和存储数据都有哪些保护需求。 例如,密码、信用卡号、医疗记录、个人信息和商业秘密需要额外保护,尤其是在这些数据属于隐私保护法(如:欧盟GDPR)或法规条例(如:金融数据保护标准 PCI DSS)适用范围的情况下。 对于这些数据,要确定

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

预防措施

  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. 单独验证每个安全配置项的有效性。

Injection - 注入

  注入降至第三。94% 的统计应用针对某种形式的注入进行了测试,最大发生率为 19%,平均发生率为 3%,共计发生了 27.4 万次。值得注意的常见弱点枚举(CWE)包括 CWE-79: Cross-site Scripting(跨站点脚本)、CWE-89:SQL Injection(SQL注入)和 CWE-73:External Control of File Name or Path(文件名或路径的外部控制)。

风险说明

  在以下情况下,应用程序易受攻击

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

  一些更常见的注入包括:SQL、NoSQL、OS 命令、对象关系映射(ORM)、LDAP 和表达式语言(EL)或对象图导航库(OGNL)注入。这一概念在所有解析器中都是相同的。源代码审查是检测应用程序是否易受注入攻击的最佳方法。强烈鼓励针对所有参数、标题、URL、cookies、JSON、SOAP和XML数据输入的自动测试。组织可以在 CI/CD 管道中引入静态(SAST)、动态(DAST)和交互式(IAST)应用程序安全测试工具,以在产品部署之前识别引入的注入缺陷。

预防措施

  防止注入需要将数据与命令和查询分开

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

Insecure Design - 不安全设计

2021年版的一个新类别,侧重于与设计和体系结构缺陷相关的风险,呼吁更多地使用威胁建模、安全设计模式和参考体系结构。作为一个应用安全技术社区,我们需要超越软件开发过程编码空间中的“左移”,转向对设计安全原则至关重要的预编码活动。值得注意的常见弱点枚举(CWE)包括 CWE-209:Generation of Error Message Containing Sensitive Information(生成包含敏感信息的错误消息)、CWE-256:Unprotected Storage of Credentials(凭证的未保护存储)、CWE-501:Trust Boundary Violation(信任边界冲突)和CWE-522:Insufficiently Protected Credentials(凭证保护不足)。

风险说明

  不安全设计是一个广泛的类别,代表不同的弱点,表示为“缺少或无效的控制设计”。不安全设计不是所有其他前10个风险类别的来源。不安全设计和不安全的实现之间存在差异。我们区分设计缺陷和实现缺陷是有原因的,它们有不同的根本原因和补救措施。安全设计仍然可能存在实现缺陷,从而导致可能被利用的漏洞。一个不安全设计不能通过一个完美的实现来修复,因为根据定义,所需的安全控制从未被创建来抵御特定的攻击。导致不安全设计的因素之一是开发的软件或系统中缺乏固有的业务风险分析,因此无法确定需要何种级别的安全设计。

  1. 需求和资源管理:收集应用程序的业务需求并与业务部门协商,包括所有数据资产和预期业务逻辑的机密性、完整性、可用性和真实性方面的保护需求。考虑应用程序的公开程度,以及是否需要租户隔离(除访问控制外)。编制技术要求,包括功能性和非功能性安全要求。计划和协商所有设计、建造、测试和运营的预算,包括安全活动。
  2. 安全设计:安全设计是一种文化和方法,它不断评估威胁,并确保代码经过稳健的设计和测试,以防止已知的攻击方法。威胁建模应整合到细化会议(或类似活动)中;查看数据流和访问控制或其他安全控制中的更改。在用户故事开发中,确定正确的流程和故障状态,确保责任方和受影响方充分理解并同意这些状态。分析预期和故障流的假设和条件,确保其仍然准确和可取。确定如何验证正确行为所需的假设和实施条件。确保结果记录在用户故事中。从错误中吸取教训,并提供积极的激励以促进改进。安全设计既不是附加组件,也不是可以添加到软件中的工具。
  3. 安全开发生命周期:安全的软件需要安全开发生命周期、某种形式的安全设计模式、AppSec 规划方法、安全的组件库、工具和威胁建模。在整个项目和软件维护过程中,在软件项目开始时联系您的安全专家。考虑利用 OWASP 软件保证成熟度模型(SAMM)来帮助构建您的安全软件开发工作。

预防措施

  1. 与应用安全专业人员建立并使用安全的开发生命周期,以帮助评估和设计与安全和隐私相关的控制。
  2. 建立并使用安全设计模式的库,或使用 AppSec 规划中现有的要素。
  3. 对关键身份验证、访问控制、业务逻辑和密钥流使用威胁建模。
  4. 将安全语言和安全控制集成到用户故事中。
  5. 在应用程序的每一层(从前端到后端)集成合理性检查。
  6. 编写单元和集成测试,以验证所有关键流是否能够抵抗威胁模型。为应用程序的每一层编译正确用例和误用案例。
  7. 根据暴露和保护需要,对系统层和网络层进行分层。
  8. 通过设计在所有层中严格隔离租户。
  9. 限制用户或服务的资源消耗。

Security Misconfiguration - 安全配置错误

  从上一版本的第六名提升,90% 的调查应用都进行了某种形式的配置错误测试,平均发生率为 4%,并且在此风险类别的 CWE 出现了超过 20.8 万次。随着当今软件正转向高度可配置,看到这一类别上升也就不足为奇了。 需要注意的是 CWE 包括: CWE-16 Configuration(配置)和 CWE-611 Improper Restriction of XML External Entity Reference(XML 外部实体引用的不当限制)。

风险说明

  1. 应用程序栈的任何部分缺少适当的安全加固,或者云服务的权限配置错误。
  2. 应用程序启用或安装了不必要的功能(例如:不必要的端口、服务、网页、帐户或权限)。
  3. 默认帐户和密码仍然可用且没有更改。
  4. 错误处理机制向用户纰漏堆栈信息或其他大量错误信息。
  5. 对于升级的系统,最新的安全特性被禁用或未安全配置。
  6. 应用程序服务器、应用程序框架(如:Struts、Spring、ASP.NET)、库文件、数据库等没有进行安全配置。
  7. 服务器不发送安全标头或指令,或未被设定安全参数。
  8. 您的应用软件已过期或易受攻击(参见“A6:2021-脆弱和过时的组件”)。

预防措施

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

Vulnerable and Outdated Components - 自带缺陷和过时的组件

  它在 Top 10 社区调查中排名第二,也有足够的数据让它进入前十。不安全的组件是我们努力测试和评估风险的已知问题,并且它是在 CWE 中唯一没有任何 CVE 对应的类别,因此,使用默认的利用/影响加权值为 5.0。值得注意的是 CWE 包括:CWE-1104 Use of Unmaintained Third-Party Components(使用未维护第三方组件),以及 2013 年和 2017 年 Top 10 中关于此问题的两个 CWE。

风险说明

  1. 如果您不知道所有使用的组件版本信息(包括:服务端和客户端)。这包括了直接使用的组件或间接依赖的组件。
  2. 如果软件易受攻击,不再支持或者过时。这包括:系统、Web 服务器、应用程序服务器、数据库管理系统(DBMS)、应用程序、API 和所有的组件、运行环境和库。
  3. 如果您没有定期做漏洞扫描和订阅使用组件的安全公告。
  4. 如果您不基于风险及时修复或升级底层平台、框架和依赖库。很可能发生这种情况:根据变更控制,每月或每季度进行升级,这使得组织在这段时间内会受到已修复但未修补的漏洞的威胁。
  5. 如果软件工程师没有对更新的、升级的或打过补丁的组件进行兼容性测试。
  6. 如果您没有对组件进行安全配置(参见“A05:2021–安全配置错误”)。

预防措施

  1. 移除不使用的依赖、不需要的功能、组件、文件和文档。
  2. 利用如 versions、OWASP Dependency Check、retire.js 等工具来持续的记录客户端和服务器端以及它们的依赖库的版本信息。持续监控如 CVE 和 NVD 等是否发布已使用组件的漏洞信息,可以使用软件分析工具来自动完成此功能。订阅关于使用组件安全漏洞的警告邮件。
  3. 仅从官方渠道安全的获取组件,并使用签名机制来降低组件被篡改或加入恶意漏洞的风险(参见“A08:2021-软件和数据完整性故障”)。
  4. 监控那些不再维护或者不发布安全补丁的库和组件。如果不能打补丁,可以考虑部署虚拟补丁来监控、检测或保护。

Identification and Authentication Failures - 身份识别和身份验证错误

  之前被称之为“无效的身份认证”,此类别从第二名下滑,现在包含了与身份识别失效相关的 CWE,如知名的“CWE-297:Improper Validation of Certificate with Host Mismatch(与不匹配的服务端进行不适当的凭证确认)”,“CWE-287:Improper Authentication(不适当的认证)”,“CWE-384:Session Fixation(会话固定攻击)”。

风险说明

  1. 允许像是攻击者已经拥有有效用户名称和密码列表的撞库自动化攻击。
  2. 允许暴力或其他自动化攻击。
  3. 允许预设、脆弱、常见的密码,像是“Password1”或“admin/admin”。
  4. 使用脆弱或无效的认证资讯回复或忘记密码的流程,如不安全的“知识相关问答”。
  5. 使用明码、被加密的或使用较脆弱杂凑法的密码(参考 A3:2017-敏感性资料泄漏)。
  6. 不具有或是无效的多因素认证。
  7. 于URL中泄漏会话(session)ID(如 URL 重写)。
  8. 成功登入后没有轮换会话(session)ID。
  9. 没有正确的注销会话(session)ID。用户的会话(session)或认证 tokens(主要是单一登入(SSO)token)没有在登出时或一段时间没活动时被适当的注销。

预防措施

  1. 在可能的情况下,实施多因素认证来防止自动化撞库攻击、暴力破解、以及遭窃认证资讯被重复利用的攻击。
  2. 不要交付或部署任何预设的认证凭证,特别是管理者。
  3. 实施弱密码的检查,如测试新设定或变更的密码是否存在于前 10000 个最差密码清单。
  4. 将密码长度、复杂度和轮换政策与 NIST 800-63b 文件“第 5.1.1 节-被记忆的秘密或其他现代基于证据的密码政策”的内容保持一致。
  5. 对所有结果使用相同的讯息回应,确保注册、认证凭据回复以及 API 路径能够抵御帐号枚举攻击。
  6. 限制或增加登入失败尝试的延迟。记录所有失败并于侦测到撞库、暴力破解或其他攻击时发出告警。
  7. 使用服器端、安全的内建会话管理器,在登入后产生有高熵值的新随机会话 ID。会话 ID 不应出现在URL中,必须被安全的储存,并且在登出后、闲置、超时后被注销。

Software and Data Integrity Failures - 软件和数据完整性故障

2021年版本的一个新类别,聚焦于在未验证完整性的情况下做出与软件更新、关键数据和 CI/CD 管道相关的假设。这是来自漏洞披露/通用漏洞评估系统(CVE/CVSS)数据的最高权重影响之一。值得注意的是,CWE 包括:CWE-829:Inclusion of Functionality from Untrusted Control Sphere(包含来自不受信任控制领域的功能),CWE-494:Download of Code Without Integrity Check(不进行完整性检查的代码下载)和CWE-502:Deserialization of Untrusted Data(不可信数据的反序列化)。

风险说明

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

预防措施

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

Security Logging and Monitoring Failures - 安全日志和监控故障

  安全日志和监控故障来自于 Top 10 的社区调查(排名第三位),比 2017 年 OWASP Top 10 社区调查时的第10位略有上升。日志记录和监控是一项具有挑战性的测试,通常涉及访谈或询问渗透测试期间是否检测到攻击。这个类别的CVE/CVSS数据不多,但检测和应对违规行为是至关重要的。同时,它对问责制、可见性、事件告警和取证仍有很大的影响。这个类别除了 CWE-778 Insufficient Logging(日志记录不足)外,还包括 CWE-117 Improper Output Neutralization for Logs(日志输出不当),CWE-223 Omission of Security-relevant Information(安全事件信息漏报),以及 CWE-532 Insertion of Sensitive Information into Log File(在日志文件中包含敏感信息)。

风险说明

2021 年版 OWASP Top 10 中,该类别是为了帮助检测、升级和应对活跃的违规行为。如果不进行日志记录和监测,就无法发现违规行为。任何时候都会发生日志记录、检测、监视和主动响应不足的情况

  1. 需要审计的事件,例如:登录、失败的登录和高价值交易,但未记录。
  2. 警告和错误未生成日志或日志记录不充分或日志消息不清晰。
  3. 应用程序和 API 的日志未进行安全可疑活动的监控。
  4. 日志只存储在本地。
  5. 适当的警报阈值和响应升级过程不到位或无效。
  6. 渗透测试和动态应用安全测试(DAST)工具(例如:OWASP ZAP)的扫描没有触发警报。
  7. 应用无法实时或接近实时地检测、升级或或对主动攻击发出警报。
  8. 如果让用户或攻击者看到日志和警报事件,您就容易受到信息泄露的攻击(查看“A01:2021-失效的访问控制”)。

预防措施

  1. 确保所有的登录、访问控制和服务器端输入验证失败都可以被记录在足够的用户上下文中,以识别可疑或恶意的帐户,并保留足够的时间以允许延迟的取证分析。
  2. 确保日志是日志管理解决方案以方便使用的格式生成的。
  3. 确保日志数据被正确编码加密,以防止对日志或监控系统的注入或攻击。
  4. 确保高价值交易有完整性控制的审计跟踪,以防止篡改或删除,例如:只附加数据库表或类似的内容。
  5. DevSecOps 团队应该建立有效的监控和警报,以便发现可疑的活动并迅速做出反应。
  6. 建立或采用事故应对和恢复计划,例如:美国国家标准技术研究所(NIST)800-61r2 或更高版本。
  7. 有一些商业和开源的应用程序保护框架,如:OWASP ModSecurity核心规则集,以及开源的日志相关软件,如:Elasticsearch、Logstash、Kibana(ELK),具有自定义仪表盘和告警功能。

Server-Side Request Forgery - 服务端请求伪造

  这个类别是从 Top 10 社区调查(排名第一位)中新添加的。数据显示,该类别安全事件发生率相对较低,测试覆盖率高于平均水平,平均漏洞利用脚本数和影响潜力等级高于平均水平。因为新类别可能是单一或小型集群的 CWE,为了引起关注和认识,希望这个类别能受到关注并且在未来的版本可以推出一个更大的类别。

风险说明

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

  随着现代 Web 应用为终端用户提供便利的功能,获取 URL 成为一种常见的场景。因此,SSRF 安全攻击事件也在不断增加。此外,由于云服务和架构的复杂性,SSRF 的严重性也越来越高。

预防措施

  1. 网络层防御建议
    1. 在隔离的网络中设置多个远程资源访问功能的网段,以减少 SSRF 的影响。
    2. 执行“默认拒绝”防火墙策略或网络访问控制规则,以阻止除必要的内部网通信外的所有通信。
      1. 建立基于应用的防火墙规则的所有权和生命周期。
      2. 在防火墙上记录所有接受和阻止的网络流(参见“A09:2021-安全日志和监控故障”)。
  2. 应用层防御建议
    1. 检查和验证所有客户端提供的输入数据。
    2. 使用白名单允许列表允许列表执行 URL 统一资源标志符、端口和目标。
    3. 不要给客户端发送原始的回复。
    4. 禁用 HTTP 重定向。
    5. 注意 URL 的一致性,以避免 DNS 重新绑定和“检查时间,使用时间”(TOCTOU)竞争条件等攻击。
    6. 不要通过使用黑名单拒绝列表或正则表达式来缓解 SSRF。攻击者拥有有效载荷列表、工具和绕过拒绝列表的技能。
  3. 需额外考虑的措施
    1. 不要在前端系统上部署其他与安全相关的服务(如:OpenID)。控制这些系统上的本地流量(如:localhost)。
    2. 对于专用和可管理的前端用户,可以在独立系统上使用网络加密(如:vpn)来满足非常高的安全保护需求。
Avatar

Hui.Ke

❤ Cyber Security | Safety is a priority.