OWASP Top 10:2025
看了实习要求都有对owasp top10有一定理解，为了防止到时候面试磕磕绊绊说不出个所以然来，所以简单总结一下
1 | OWASP Top 10 是一份面向开发人员与 Web 应用安全的标准意识文档，代表了业界对最关键 Web 应用安全风险的广泛共识。它由开放 Web 应用程序安全项目（OWASP）发布，旨在帮助组织优先关注最严重的安全风险，但它本身不是一份合规检查清单。 |
2025 版最终确定的 10 大风险条目如下：
- A01:2025 - Broken Access Control（访问控制失效）
- A02:2025 - Security Misconfiguration（安全配置错误）
- A03:2025 - Software Supply Chain Failures（软件供应链失效）
- A04:2025 - Cryptographic Failures（加密机制失效）
- A05:2025 - Injection（注入）
- A06:2025 - Insecure Design（不安全的设计）
- A07:2025 - Authentication Failures（身份认证失败）
- A08:2025 - Software or Data Integrity Failures（软件或数据完整性失效）
- A09:2025 - Security Logging and Alerting Failures（安全日志记录和告警失效）
- A10:2025 - Mishandling of Exceptional Conditions（异常情况处理不当）
详解
A01 访问控制失效
在十大漏洞中，其排名仍居第一。经测试的100%应用程序均存在某种形式的访问控制缺陷。主要的常见漏洞包括：CWE-200：敏感信息暴露给未经授权的实体、CWE-201：通过发送数据泄露敏感信息、CWE-918：服务器端请求伪造（SSRF）以及CWE-352：跨站请求伪造（CSRF）。该类别在提交的数据中出现次数最多，相关CVE的数量位居第二
常见的访问控制漏洞包括：
- 违反最小权限原则，也就是通常所说的默认拒绝。访问权限应只授予特定能力、角色或用户，却对任何人可用。
- 通过修改 URL（参数篡改或强制浏览）、内部应用状态或 HTML 页面，或使用修改 API 请求的攻击工具绕过访问控制检查。
- 通过提供某账户的唯一标识符，允许查看或编辑他人账户（不安全的直接对象引用）。
- 可访问的 API 对 POST、PUT 和 DELETE 缺少访问控制。
- 权限提升。未登录时以用户身份操作，或获得超出已登录用户预期的权限（例如管理员访问权限）。
- 元数据操纵，例如重放或篡改 JSON Web Token（JWT）访问控制令牌，篡改 cookie 或隐藏字段以提升权限，或滥用 JWT 失效机制。
- CORS 配置错误允许来自未经授权或不受信任来源的 API 访问。
- 作为未认证用户强制浏览（猜测 URL）已认证页面，或作为普通用户访问特权页面。
从技术层面，根本原因可以归结为：
第一，访问控制的实现位置错了。 OWASP反复强调一个原则：访问控制只在可信的服务端代码或无服务器API中实施时才有效，因为攻击者可以完全控制客户端的所有内容——HTML、JavaScript、Cookie、请求参数。很多团队仍然依赖前端隐藏按钮来做“权限控制”，这在安全上等于没有控制。
第二，授权逻辑“信任了不该信任的东西”。 OWASP指出，常见的失败模式包括：授权逻辑信任客户端提供的参数（如 X-User-Role 头）、默认权限过宽、以及IDOR中信任客户端提供的对象标识符。本质问题是：系统把“请求中带了什么”当作了“请求者有权做什么”的证明。
第三，架构演进放大了校验点的数量。 从单体应用到微服务，从Web端到移动端到API，每个新的入口都是一次“忘记加检查”的新机会。OWASP在API安全领域专门将BOLA（Broken Object Level Authorization）列为首要风险，就是因为REST和GraphQL端点直接在请求中传递对象标识符，一个授权失误就能导致大规模数据暴露。
防御体系
OWASP给出的防御建议形成了一个完整的体系：
架构层面，访问控制机制应当在服务端统一实现并复用，而不是每个开发者各自为政。推荐使用成熟的工具包或模式来提供声明式的访问控制。
实现层面，有几个核心实践：记录所有权强制（访问控制模型应强制“记录所有权”，只有记录的拥有者才能操作）；默认拒绝（除公共资源外一律拒绝）；JWT等无状态令牌应设置合理的过期时间，服务端应在登出后使会话标识符失效。
运维层面，需要记录访问控制失败并在适当情况下告警；对API实施限流以减少自动化攻击的危害；禁用Web服务器的目录列表功能；确保 .git 等元数据和备份文件不在Web根目录中。
测试层面，OWASP特别强调：开发人员和QA人员应在单元测试和集成测试中包含功能级访问控制测试。这意味着访问控制不应是“上线前检查一下”的事情，而应成为开发流程的标配环节。
在ai环境下
一、核心变化：从“用户越权”到“Agent越权”
传统访问控制模型假设“主体”是人类用户，权限边界相对静态。而在AI时代，AI Agent成为新的“主体” ——它自主感知、规划、决策、调用工具。NIST在2026年发布的Agent身份与访问管理概念文件中提出了一个关键问题：当Agent开始读取文件、调用工具、访问数据库甚至代表用户执行真实操作时，它究竟是谁？它代表谁？又被允许做什么？
OWASP在2025版《Top 10 for LLM Applications》中将Excessive Agency（过度代理） 列为独立风险，并在2026版中将其从第6位提升至第3位。Imperva的分析指出：Excessive Agency“关于应用在模型驱动下被允许做什么：它可以调用哪些工具、可以到达哪些系统、一个决策在人类看到之前能走多远”。这本质上就是访问控制问题——只不过主体从人类用户变成了AI Agent。
二、AI架构带来的新攻击面：MCP与工具调用层
在传统Web应用中，访问控制失效主要发生在HTTP端点。而在AI Agent架构中，MCP（Model Context Protocol）服务器和工具调用层成为新的授权盲区。
CVE-2026-101084（Obot） 是一个典型案例。Obot在v0.21.1之前在 /mcp-connect 端点上未能强制执行访问控制规则，任何已认证用户只要拥有服务器ID就能连接到受限的MCP服务器。系统依赖“拥有服务器ID”作为授权的充分证明，而非严格校验用户的角色和权限映射。攻击者可以利用已存储的OAuth凭证，通过MCP工具调用访问和操纵敏感后端系统。
三、防御体系
agent从传统模型向agent原生IAM演技
第一，Agent需要独立身份。 NIST明确提出，Agent应被视为一等身份主体，拥有自己的唯一标识、凭证和权限，并与授权它的用户建立明确绑定关系。身份关系不再是“用户身份→Agent直接复用→服务”，而应该是“用户身份→授权/委托→Agent身份→服务”。OWASP Agentic AI Top 10强调“给Agent它们自己的身份，而不是用户借来的身份”。
第二，最小权限原则需要重新定义。 在Agent时代，最小权限原则首先防范的并不是攻击者，而是Agent自身的不确定性。OWASP建议采用任务作用域、时间受限的权限：每个任务发放短期、窄范围的token，使用每Agent身份和短期凭证（如mTLS证书），在任务完成时自动过期。AWS Bedrock要求Agent执行角色绑定权限边界；Microsoft Entra Agent ID采用短时令牌和JIT（即时）权限。
第三，工具调用层需要独立的授权校验。 MCP服务器必须在工具执行层而非仅工具发现层做授权检查。OWASP Agentic AI Top 10建议“对Agent尝试使用的每一个工具进行即时验证”，并在模型与任何下游之间设置策略执行点。
第四，审计需要覆盖Agent的决策链路。 NIST指出，当前日志通常记录的是聊天回复，而非底层的工具动作、权限范围和下游授权决策。需要将Agent的具体动作与Agent身份和非人类实体绑定，实现有效的可见性。
第五，人类审批作为最终防线。 OWASP建议对“任何高权限或不可逆操作”要求人类批准，作为基于记忆的提权和困惑代表攻击的最终防线。
A02 安全配置错误
安全配置错误的核心定义是：系统、应用或云服务从安全角度被错误设置，从而产生漏洞。它与访问控制失效有一个本质区别：访问控制失效是“代码逻辑里少了一个检查”，安全配置错误是“代码本身没问题，但部署时设置错了”。
常见类型
安全配置错误的覆盖面极广，OWASP列出了八种典型脆弱场景：
第一，应用栈缺少安全加固，或云服务权限配置不当。 这是最宽泛的一类，涵盖从操作系统到应用框架到云服务的所有配置层面。
第二，不必要的功能被启用或安装。 未使用的端口、服务、页面、账户、测试框架、权限——每一个都是攻击面。OWASP特别强调了“测试框架”和“示例应用”：很多应用服务器自带示例应用，这些示例往往有已知的安全缺陷，且默认账户密码未修改，攻击者可以直接登录接管服务器。
第三，默认账户和密码仍然启用且未修改。 这是最“低级”但也最常见的配置错误。攻击者甚至不需要“黑客技术”，只需要知道默认密码。
第四，缺少集中配置来拦截过多错误消息。 错误处理向用户暴露堆栈跟踪或其他过于详细的错误信息。这直接为攻击者提供了系统架构、组件版本、文件路径等情报。
第五，对已升级系统，最新安全功能被禁用或未安全配置。 这通常发生在“升级了版本但没更新配置”的场景中。
第六，过度优先考虑向后兼容，导致不安全配置。 为了兼容旧客户端而保留不安全的旧协议或旧加密套件。
第七，应用服务器、框架、库、数据库的安全设置未设为安全值。 包括Struts、Spring、ASP.NET等框架的默认配置往往不是最安全的。
第八，服务器未发送安全头或指令，或未设为安全值。 包括Content-Security-Policy、Strict-Transport-Security等安全响应头的缺失。
防御体系
部署阶段，建立可重复的加固流程。这个流程应当自动化，能够快速、轻松地部署一个经过适当锁定的新环境。开发、QA、生产环境配置应当一致，但凭据必须不同。
平台层面，使用最小化平台。移除或不要安装未使用的功能和框架。每一行配置、每一个启用的服务，都需要有存在的理由。
运维阶段，将配置审查纳入补丁管理流程。每次安全公告、更新或补丁发布时，同步审查配置是否需要调整。特别强调云存储权限（如S3 bucket权限）的定期审查。
架构层面，采用分段应用架构。通过分段、容器化或云安全组在组件或租户之间实现有效隔离，限制配置错误的影响范围。
验证层面，建立自动化流程验证配置有效性。如果无法自动化，至少每年手动验证一次。OWASP还建议“主动增加集中配置作为拦截过多错误消息的备用措施”。
凭据管理，使用身份联合、短期凭据或基于角色的访问机制，而不是在代码、配置文件或流水线中嵌入静态密钥或secret。这一点在2025版中被特别强调，因为静态密钥的泄露往往是配置错误中最致命的后果。