OWASP TOP 10 2025
OWASP TOP 10 2025
2025年的十大安全应用风险已新鲜出炉，相较2023的风险，大部分没有过多的变动，仍旧是老面孔，但也有新风险的加入，从大体上来看，传统安全挑战的新风险防范仍然是重中之重。
PS：本文大部分信息来源于OWASP基金会官网
TOP 1 访问控制失效
访问控制即为强制执行策略，确保用户不得超出其预定权限的行为。失败通常会导致未经授权的信息泄露、数据的修改或销毁，或执行超出用户权限的业务功能。常见的访问控制漏洞包括：
- 未严格执行最小权限，通常称为默认拒绝，即访问应仅授予特定能力、角色或用户，但对任何人开放。
- 通过修改URL、内部应用状态或HTML页面，或使用修改API请求的攻击工具来绕过访问控制检查。
- 允许通过提供他人的唯一标识符（如URL后缀）来查看或编辑其账户
- 一个可访问的API，缺少合理的的访问方法控制。
- 权限提升。作为用户但未登录，或未获得超出登录用户预期权限。
- 重放或篡改 JSON Web 令牌访问控制令牌、通过 cookie 或隐藏字段来提升权限。
- 强制浏览到未认证用户的认证页面，或标准用户访问特权页面。
常见实例
TOP 2 安全配置错误
安全配置错误是指从安全角度看，系统、应用或云服务设置错误，如果应用存在以下问题，可能会导致漏洞：
- 缺少应用栈任何部分的适当安全加固，或云服务权限配置不当。
- 启用或安装了不必要的功能。
- 默认账户及其密码依然启用且未更改。
- 缺乏集中配置来拦截过多错误消息。错误处理会向用户揭示堆栈追踪或其他过于信息化的错误信息。
- 对于升级系统，最新的安全功能被禁用或未被安全配置。
- 过度优先考虑向后兼容性导致配置不安全。
- 应用服务器、应用框架如 Struts、Spring、ASP.NET等、库、数据库等的安全设置并未设置为安全值。
- 服务器不发送安全头部或指令，或者它们未设置为安全值。
常见实例
TOP 3 软件供应链故障
软件供应链故障是指在构建、分发或更新软件过程中发生的故障或其他妥协。它们通常是由于第三方代码、工具或其他依赖关系中的漏洞或恶意更改引起的，例如：
- 未仔细跟踪所有组件的版本，包括客户端和服务器端。包括你直接使用的组件以及嵌套依赖。
- 该软件存在漏洞、未支持或已过时。包括作系统、网页/应用服务器、数据库管理系统、应用程序、API及所有组件、运行环境和库。
- 未定期扫描漏洞、订阅与你所用组件相关的安全公告。
- 没有变更管理流程，也没有供应链内的变化跟踪，包括跟踪IDE、IDE扩展和更新、组织代码仓库、沙盒、镜像和库仓库的变化、工件的创建和存储方式等。供应链的每一个环节都应有记录，尤其是变更。
- 没有加强供应链的每个环节，特别关注最低权限的应用。
- 供应链系统没有职责分离。没有一个人应该能在没有他人监督的情况下编写代码并推广到生产环境。
- 来自不可信来源的组件、跨越技术栈的任何部分，都被用于生产环境中或可能影响生产环境。
- 没有以风险为基础、及时的方式修复或升级底层平台、框架和依赖。这种情况通常发生在修补是每月或季度一次、受变更控制的环境中，组织在修复漏洞之前可能面临数天甚至数月不必要的暴露风险。
- 软件开发者未进行测试更新、升级或补丁库的兼容性。
- 未能保护系统每个部分的配置。
- CI/CD流水线安全性比它构建和部署的系统弱，尤其是复杂的系统。
常见实例
TOP 4 密码学故障
一般来说，所有传输中的数据都应在传输层进行加密。过去的 CPU 性能和私钥/证书管理等障碍，现在由设计加速加密指令的 CPU 来解决，私钥和证书管理通过 Lets Encrypt等服务简化，主要云厂商为其特定平台提供更紧密集成的证书管理服务。
此外，保障传输层安全外，还要确定哪些数据在静止时需要加密，哪些数据在传输过程中需要在应用层中额外加密。例如，密码、信用卡号、健康记录、个人信息和商业机密需要额外保护，尤其是当这些数据属于隐私法律范畴，例如欧盟的《通用数据保护条例》或PCI数据安全标准等法规时。对于所有此类数据，若出现以下问题则可能会导致安全隐患：
- 有一些老旧或较弱的密码算法或协议被默认使用，或者在较旧的代码中。
- 使用默认加密密钥，弱密钥被生成，密钥被重复使用，或缺少适当的密钥管理和轮换。
- 加密密钥会被检查到源代码仓库吗？
- 加密未被强制执行，有任何HTTP头的安全指令或头部缺失。
- 收到的服务器证书和信任链未经过正确验证。
- 初始化向量被忽视、重复使用，或者生成的安全性不足，或是使用了像ECB这样不安全的模式，当认证加密更合适时，未使用加密。
- 在没有基于密码的密钥派生功能的情况下，密码没有用作密码学密钥。
- 使用了未满足密码学要求的随机性，或开发者使用一个缺乏足够熵或不可预测性的种子覆盖了内置的强做种功能。
- 使用已弃用的哈希函数，如MD5或SHA1，或是在需要密码学哈希函数时使用非密码哈希函数
- 密码学错误消息或侧信道信息被利用，例如以填充预言机攻击的形式。
- 密码算法被降级或绕过。
常见实例
TOP 5 注入漏洞
注入漏洞是一种应用程序缺陷，允许不受信任的用户输入发送到解释器（例如浏览器、数据库、命令行），并导致解释器将该输入的部分内容作为命令执行。当应用出现以下情况下容易受到攻击：
- 用户提供的数据未被应用程序验证、过滤或净化。
- 动态查询或无上下文转义的非参数化调用直接用于解释器中。
- 未净化数据用于对象关系映射搜索参数中提取额外的敏感记录。
- 潜在的敌意数据被直接使用或串接。SQL 或命令包含动态查询、命令或存储过程中的结构和恶意数据。
一些较常用的注入包括 SQL、NoSQL、作系统命令、对象关系映射、LDAP 以及表达式语言或对象图导航库（OGNL）注入。所有解释器中该概念是相同的。检测最佳方式是结合源代码审查和自动测试（包括模糊检测）对所有参数、头部、URL、Cookie、JSON、SOAP和XML数据输入进行测试。在CI/CD流水线中加入静态、动态和交互式应用安全测试工具，也有助于在生产部署前识别注入缺陷。随着AI大模型的发展，目前这一类相关的注入漏洞在大型语言模型中变得尤为常见，用于AI底层法规的绕过和突破。
常见实例
TOP 6 不安全设计
不安全设计是一个广义类别，代表不同的弱点，意为“缺失或无效的控制设计”。不安全设计并非所有其他十大风险类别的根源。
不安全设计和不安全的实现是有区别的。我们区分设计缺陷和实现缺陷是有原因的，它们有不同的根本原因，发生在开发过程中的不同阶段，也有不同的补救措施。修正后的安全设计仍可能存在实现缺陷，导致可能被利用的漏洞。不安全的设计无法通过完美的实现来修复，因为必要的安全控制从未被创建来防御特定攻击。
常见实例
TOP 7 认证失败
当攻击者能够欺骗系统识别出无效或错误用户为合法用户时，这种漏洞就存在。如果应用程序：
- 允许自动攻击，如凭证填充，攻击者拥有有效用户名和密码的泄露列表。近年来，这种攻击方式已扩展到包括混合密码攻击、凭证填充，攻击者利用泄露的凭证变体或增量来获取访问权限，例如尝试Password1！、Password2！、Password3！诸如此类。
- 允许暴力破解或其他自动化、脚本化攻击，且这些攻击无法迅速被阻挡。
- 允许使用默认、弱密码或知名密码，例如“Password1”或“admin”用户名与“admin”密码。
- 允许用户创建已被泄露的已知凭证的新账户。
- 允许使用薄弱或无效的凭证恢复和忘记密码的流程，如“基于知识的答案”，这些方法无法实现安全。
- 使用纯文本、加密或弱哈希密码数据存储（即TOP 4 中密码安全问题）。
- 缺少或无效的多因素认证。
- 如果无法使用多因素认证，允许使用弱或无效的备用方法。
- 它会在 URL 中暴露会话标识符、隐藏字段或其他客户端可访问的不安全位置。
- 登录成功后重复使用相同的会话标识符。
- 在注销或非活动期间，无法正确使用户会话或认证令牌令牌失效。
- 未能正确陈述所提供资质的范围和目标受众。
常见实例
TOP 8 软件或数据完整性故障
软件和数据完整性失效涉及代码和基础设施，无法防止无效或不可信的代码或数据被当作可信且有效。例如，应用程序依赖来自不可信来源、仓库和内容分发网络的插件、库或模块。如果不使用并提供软件完整性检查，CI/CD流水线不安全，可能会带来未经授权访问、不安全或恶意代码，或系统被入侵的风险。
此外，CI/CD从不可信的地方拉取代码或伪影，或者在使用前不进行验证。许多应用程序现在包含自动更新功能，即在未经过足够完整性验证的情况下下载更新，并应用到之前受信任的应用程序上。攻击者可能会上传自己的更新，分发并在所有安装上运行。另一个例子是，当对象或数据被编码或序列化成攻击者能看到并修改的结构，但该结构易受到不安全的反序列化攻击。
常见实例
TOP 9 安全日志与警报失效
没有日志和监控，攻击和漏洞无法被检测到;没有警报，在安全事件发生时，快速有效响应非常困难。日志不足、持续监控、检测和警报不足以启动主动响应：
- 可审计的事件，如登录、登录失败和高价值交易，不会被记录或记录不一致。
- 警告和错误会生成无、不充分或不清晰的日志消息。
- 原木的完整性未受到妥善保护以防止篡改。
- 应用程序和API的日志不会被监控是否有可疑活动。
- 日志只存储在本地，没有正确备份。
- 适当的警报阈值和响应升级流程尚未建立或有效。警报未在合理时间内收到或审核。
- 通过动态应用安全测试工具进行渗透测试和扫描，则不会触发警报。
- 该应用无法实时或近实时地检测、升级或警示主动攻击。
- 通过让日志和警报事件对用户或攻击者可见，或记录不应被记录的敏感信息来暴露敏感信息，容易受到敏感信息泄露的风险。
- 日志数据编码不正确，容易受到日志或监控系统的注入或攻击。
- 应用程序缺少或错误处理错误及其他特殊情况，导致系统未察觉错误存在，因此无法记录存在问题。
- 发布警报的“用例”缺失或已过时，无法识别特殊情况。
- 过多的误报导致无法区分重要和不重要的警报，导致它们被识别得太晚甚至根本无法识别。
- 检测到的警报无法正确处理，因为该用例的作手册不完整、过时或缺失。
常见实例
TOP 10 特殊条件处理不当
软件中对异常情况的误处理是指程序未能预防、检测和响应异常和不可预测的情况，导致崩溃、意外行为，有时甚至存在漏洞。这可能涉及以下三种失败中的一种或多种;应用程序未能阻止异常情况发生，无法在发生时识别情况，和/或事后对情况反应不佳甚至完全不响应。
异常状况可能由缺失、错误或不完整输入验证，或在发生的函数处处理较晚、高级别错误处理，或是内存、权限或网络问题等意外环境状态、异常处理不一致，或异常完全未被处理，导致系统陷入未知且不可预测的状态。每当应用程序不确定下一条指令时，说明异常条件被误处理。难以发现的错误和异常可能长期威胁整个应用的安全。
常见实例
今日日鞠
浙公网安备 33010602011771号