OWASP Top 10 2025: Application Design Flaws (应用程序设计缺陷)

Posted on Edited on In , Views: Word count in article: 4.2k Reading time ≈ 4 mins.

OWASP Top 10 2025: Application Design Flaws (应用程序设计缺陷)

简介 (Introduction)

本内容详细解析了 OWASP Top 10 2025 中的 4 个类别。你将了解到与架构和系统设计失败相关的类别。

涵盖的类别包括：

  1. AS02: 安全配置错误 (Security Misconfigurations)
  2. AS03: 软件供应链失败 (Software Supply Chain Failures)
  3. AS04: 密码学失败 (Cryptographic Failures)
  4. AS06: 不安全的设计 (Insecure Design)

AS02: 安全配置错误 (Security Misconfigurations)

什么是安全配置错误？ (What It Is)

安全配置错误 (Security Misconfigurations) 发生在系统、服务器或应用程序在部署时使用了不安全的默认设置、不完整的配置或暴露了不必要的服务。这些不是代码层面的 Bug，而是环境、软件或网络设置方式上的失误。它们为攻击者创造了极易进入的切入点。

为什么它很重要？ (Why It Matters)

即使是微小的配置错误也可能导致敏感数据泄露、提权攻击 (Privilege Escalation)，或让攻击者在系统中获得立足点。现代应用程序依赖复杂的堆栈、云服务和第三方 API。一个暴露的管理面板、一个开放的存储桶或配置错误的权限，都可能导致整个系统的沦陷。

案例示例 (Example)

2017 年，Uber 暴露了一个包含敏感用户数据（包括司机和乘客信息）的备份 AWS S3 存储桶，原因该存储桶设置为公开访问。攻击者无需任何凭据即可直接下载数据。这充分展示了部署过程中的失误如何导致重大数据泄露。

常见模式 (Common Patterns)

  • 未修改默认凭据或使用了弱密码。
  • 向互联网暴露了不必要的服务或端点。
  • 配置错误的云存储或权限（如 S3, Azure Blob, GCP buckets）。
  • 不受限的 API 访问，或缺失认证/授权。
  • 过详细的错误消息暴露了堆栈跟踪 (Stack Traces) 或系统细节。
  • 使用包含已知漏洞的过时软件、框架或容器。
  • 未在 AI/ML 端点上实施适当的访问控制。

如何预防？ (How To Prevent It)

  • 加固默认配置，移除未使用的功能或服务。
  • 在所有系统中强制执行强认证和 最小权限原则 (Least Privilege)。
  • 限制网络暴露并对敏感资源进行细分。
  • 及时更新软件、框架和容器的补丁。
  • 在错误消息中隐藏堆栈跟踪和系统信息。
  • 定期审计云配置和权限。
  • 为 AI 端点和自动化服务提供适当的访问控制及监控。
  • 将配置审查和自动化安全检查集成到部署流水线 (Deployment Pipeline) 中。

AS03: 软件供应链失败 (Software Supply Chain Failures)

什么是软件供应链失败？ (What It Is)

软件供应链失败 (Software Supply Chain Failures) 发生在应用程序依赖的组件、库、服务或模型已被破坏、过时或未经过严格验证。这些弱点并非源自你自己的代码，而是源自你所依赖的软件和工具。攻击者利用这些薄弱环节植入恶意代码、绕过安全机制或窃取敏感数据。

为什么它很重要？ (Why It Matters)

现代应用程序由许多第三方包、API 和 AI 模型构建而成。一个受损的依赖项就可能瓦解你的整个系统，让攻击者在无需触碰你任何代码的情况下获得访问权限。供应链攻击可以自动化且分布式地进行，使其难以检测且极具破坏力。

案例示例 (Example)

2021 年的 SolarWinds Orion 事件展示了供应链攻击的巨大威胁。攻击者在一个受信任的更新中插入了恶意代码，影响了成千上万个自动安装该更新的组织。这本身不是 SolarWinds 核心逻辑的 Bug，而是软件更新构建、验证和分发过程中的缺陷。

在 AI 领域，当我们使用未经验证的第三方模型或经过微调的数据集时，也能观察到类似模式，这些模型可能嵌入了隐藏行为、后门或偏见输出，从而破坏系统或导致数据泄露。

常见模式 (Common Patterns)

  • 使用未经验证或未维护的库和依赖项。
  • 无需验证即自动安装更新。
  • 过度依赖第三方 AI 模型且缺乏监控或审计。
  • 不安全的构建流水线或 CI/CD 流程，导致内容被篡改。
  • 组件的许可证或溯源 (Provenance) 跟踪不力。
  • 部署后缺乏对依赖项漏洞的监控。

如何保护供应链？ (How To Protect The Supply Chain)

  • 在使用前验证所有第三方组件、库和 AI 模型。
  • 定期监控并修补依赖项。
  • 对软件更新和包进行签名、验证和审计。
  • 加固 CI/CD 流水线和构建过程以防止篡改。
  • 跟踪所有依赖项的溯源和许可信息。
  • 为依赖项或 AI 组件的异常行为实施运行时监控。
  • 将供应链威胁建模集成到 软件开发生命周期 (SDLC) 中，包括测试、部署和更新工作流。

AS04: 密码学失败 (Cryptographic Failures)

什么是密码学失败？ (What It Is)

密码学失败 (Cryptographic Failures) 发生在加密技术被错误使用或根本未使用的情况下。这包括使用弱算法、硬编码密钥、糟糕的密钥处理或未加密的敏感数据。这些缺陷让攻击者能够访问原本应当保密的信息。

为什么它很重要？ (Why It Matters)

Web 应用程序处处依赖密码学：保护网络流量、保障存储数据的安全、验证身份以及守护秘密 (Secrets)。当这些控制机制失效时，诸如密码、令牌 (Tokens) 或个人信息等敏感数据可能会暴露，导致账户被接管或发生大规模泄露。

攻击者可以通过 中间人攻击 (Man-in-the-middle)、针对弱密钥的暴力破解，或者仅仅是通过发现从未得到妥善保护的秘密来利用这些缺陷。

常见模式 (Common Patterns)

  • 使用已弃用或弱算法，如 MD5, SHA-1 或 ECB 模式。
  • 在代码或配置中硬编码秘密 (Secrets)。
  • 密钥轮换或管理实践糟糕。
  • 静态存储或传输中的敏感数据缺乏加密。
  • 使用自签名或无效的 TLS 证书。
  • 在使用 AI/ML 系统时，对模型参数或敏感输入的秘密处理不当。

如何预防？ (How To Prevent It)

  • 使用强大的现代算法，如 AES-GCM, ChaCha20-Poly1305，或强制执行带有有效证书的 TLS 1.3。
  • 使用安全的密钥管理服务，如 Azure Key Vault, AWS KMS 或 HashiCorp Vault。
  • 定期轮换秘密和密钥，遵循定义的加密周期。
  • 为密钥生命周期管理记录并强制执行策略和标准操作程序 (SOP)。
  • 维护完整的证书、密钥及其所有者的清单。
  • 确保 AI 模型和自动化代理永远不会暴露未加密的秘密或敏感数据。

AS06: 不安全的设计 (Insecure Design)

什么是不安全的设计？ (What It Is)

不安全的设计 (Insecure Design) 发生在系统从一开始就构建了存在缺陷的逻辑或架构。这些缺陷源于跳过了威胁建模、没有设计要求或审查，或者是偶然的错误。

此外，随着 AI 助手的引入，AI 系统加剧了不安全设计。开发者通常认为模型是安全、正确或可预测的，或者认为它们生成的代码是没有缺陷的。当 AI 系统被允许不受限制地生成查询、编写代码或对用户进行分类时，风险就深深植根于设计之中，导致糟糕的架构模式。

案例示例 (Example)

Clubhouse 是一个典型的例子。其早期设计假设用户只会通过移动应用进行交互，但后端 API 缺乏适当的认证。任何人都可以直接查询用户数据、房间信息甚至私密对话。当研究人员对其进行测试时，整个“私密对话”的前提就彻底瓦解了。

为什么它很重要？ (Why It Matters)

你无法修补一个不安全的设计。它深植于工作流、逻辑和信任边界之中。修复它意味着需要重新思考系统，以及现在的 AI 是如何做出决策的。

2025 年常见的不安全设计 (Common Insecure Designs In 2025)

  • 弱业务逻辑控制，如恢复或审批流程。
  • 对用户或模型行为的错误假设。
  • AI 组件拥有不受检查的权限或访问权。
  • 缺乏对 大语言模型 (LLMs) 和自动化代理的防护栏 (Guardrails)。
  • 生产环境中遗留了测试或调试绕过机制。
  • 缺乏一致的滥用案例审查或 AI 威胁建模。

AI 时代的不安全设计 (Insecure Design In The AI Era)

AI 引入了新型的设计失败。例如，提示词注入 (Prompt Injection) 发生在用户输入与系统提示词混合时，导致攻击者能够劫持上下文或提取隐藏数据。对模型输出的盲目信任会创建脆弱的系统，这些系统在没有核实或监督的情况下根据 AI 决策采取行动，这就是为什么人工审查仍然必不可少。而源自未经验证的渠道或基于不安全数据微调的 中毒模型 (Poisoned Models)，则可能嵌入潜伏行为或后门，从内部瓦解系统。

如何安全地进行设计？ (How To Design Securely)

  • 除非证明其安全，否则将每个模型视为不可信的。
  • 验证并过滤所有模型的输入和输出，以确保准确性和完整性。
  • 将系统提示词与用户内容分离。
  • 除非绝对必要，否则不要将敏感数据放入提示词中，并使用严格控制进行保护。
  • 对高风险的 AI 操作要求人工审查。
  • 记录模型来源，监控其行为，并对敏感数据应用 差分隐私 (Differential Privacy)。
  • 在整个设计过程中加入针对提示词攻击、推理风险、代理滥用和供应链破坏的 AI 专用威胁建模。
  • 将威胁建模融入开发的每一个阶段，而不仅仅是在开始时。
  • 在实现每个功能之前定义明确的安全要求。
  • 对用户、API 和服务应用 最小权限原则。
  • 确保整个系统具有适当的认证、授权和会话管理。
  • 确保依赖项、第三方组件和供应链来源经过验证且保持最新。
  • 随着新功能或 AI 组件的加入，持续监控和测试系统的逻辑缺陷、滥用途径和突发风险。

结论 (Conclusion)

AS02 安全配置错误、AS03 软件供应链失败、AS04 密码学失败和 AS06 不安全的设计中的安全设计失败都有一个共同的根源：基础薄弱。你不能在最后时刻才添加安全并期望它奏效。强大的系统始于明确的安全要求、现实的威胁假设、受控的配置、经过审查的依赖项以及健全的密码学选择。

保持对默认设置的怀疑，将每个依赖项视为潜在风险，并保持设计足够简单以方便推理。尽早完成正确的设计，你就能避免在未来面对无数本可预防的事故。