owasp-security

OWASP Security

编写或审查代码时，请遵循这些标准。进行审查时，请按以下工作流执行。

参考文件（阅读任务所需的文件，并且只读所需的章节）：

• reference/review-checklist.md：涵盖所有 Top 10 类别以及 LLM 和 Agent 检查项的检查清单。审查的第 3 步中阅读。
• reference/languages.md：20 多种语言中容易出现的问题及安全/不安全示例。阅读被审查代码所用语言的章节。
• reference/config-and-supply-chain.md：Dockerfile、Kubernetes、Terraform、框架配置、安全标头、锁文件和 CI/CD 中的 A02 和 A03。变更涉及配置、IaC、依赖项或流水线时阅读。
• reference/owasp-report.md：每项 Top 10:2025、ASVS 5.0、LLM Top 10 和 Agentic 项目的攻击向量、缓解措施及示例。约 1100 行：跳转到所需章节。

安全审查工作流

将此检查清单复制到回复中，并在进行时逐项勾选：

Security Review Progress:
- [ ] Step 1: Map entry points and trust boundaries
- [ ] Step 2: Load the references this code needs
- [ ] Step 3: Sweep for candidate issues
- [ ] Step 4: Triage every candidate
- [ ] Step 5: Report findings

步骤 1：梳理入口点和信任边界。 列出攻击者可控数据的输入位置： 路由和处理程序、标头和 Cookie、上传、Webhook、队列消费者、命令行参数、 第三方 API 响应，以及 LLM 读取或返回的任何内容。记录身份验证和授权的实施位置； 这些措施通常集中在中间件中，而不是按路由分别实施。

步骤 2：加载代码所需的参考资料。 languages.md 中对应的语言章节； 如果配置、IaC、依赖项或 CI 发生变化，则阅读 config-and-supply-chain.md；如果代码会调用模型或运行 Agent，则阅读 owasp-report.md 中的 LLM 和 Agentic 章节。

步骤 3：检查可能存在的问题。 按照 review-checklist.md 检查代码涉及的类别。对于每个可能的问题，追踪从步骤 1 中的入口点到目标点的路径。

步骤 4：根据下方“报告发现项之前”中的评估标准，对每个可能的问题进行分类评估。 排除不符合标准的问题，或将其降级为纵深防御建议。如果无法确定某个问题是否可达，则针对该输入返回步骤 1，再做判断。

步骤 5：报告发现项，按严重程度从高到低排列。

报告发现前

匹配到某种模式并不代表存在漏洞。自动化安全审查中最常见的失败情况，是报告无法触达或已采取缓解措施的代码，从而掩盖真正的发现。报告前，请确认以下四点：

1. 输入确实由攻击者控制吗？ 将其追溯到真实入口：请求参数、标头、Cookie、上传文件、Webhook、队列消息或第三方 API 响应。若某个值始终只来自常量、枚举或可信的内部配置，就不是注入源。
2. 该输入能到达对应的接收点吗？ 检查验证、允许列表、ORM 或框架级控制是否已介于两者之间。在认定某个路由缺少授权前，先查找身份验证中间件（middleware.ts、proxy.ts、Express/Django/Rails 中间件、基础控制器、装饰器）。执行控制通常集中处理，而非按路由分别配置。
3. 影响范围有多大？ 谁能触发问题、能获取什么，以及是否跨越信任边界？SSRF 能访问云元数据，与只能访问 localhost 的 SSRF 不同。
4. 攻击者能完成每一步吗？ 利用链中的每一步都必须能从攻击者的立场实现。符号链接竞态需要攻击者能在服务器上创建符号链接；标头攻击需要客户端能设置该标头。如果某一步需要攻击者并未被代码证明拥有的能力，该发现应标为“需要验证”，而非“高危”。

严重性应根据可利用性判断，而不是根据模式判断。说明具体路径（该输入到达该接收点）；若某项发现只是理论上的，或属于纵深防御问题而非可直接利用的问题，也要明确说明。如果无法根据现有代码确定可达性，应如实说明，不要断言任何一方。

报告格式

每项发现单独成块，并按严重性从高到低排列：

[SEVERITY] Title (CWE-###, OWASP A##:2025, LLM## Risk Name, ASI## Risk Name)
Location:   path/to/file.ext:LINE
Path:       <entry point> -> <intermediate hops> -> <sink>
Impact:     who can trigger it, what they get, which trust boundary it crosses
Fix:        the concrete change, with a code snippet when it isn't obvious
Confidence: Confirmed | Likely | Needs verification (say what you couldn't see)

列出每个 LLM 和 ASI ID 时，必须同时写出其风险名称，例如“LLM03 过度代理”。只写 LLM ID 会产生歧义：2025 和 2026 版本对不同风险使用了相同编号。

严重性	含义
严重	未经身份验证的远程代码执行、身份验证绕过或大规模数据泄露
高	经身份验证的利用会跨越信任边界（访问其他租户数据的 IDOR、登录后可利用的 SQLi）
中	需要不常见的前提条件，或影响仅限于攻击者自己的数据
低	纵深防御存在缺口，但没有已证明的利用路径
信息	加固建议；应明确说明这不是漏洞

如果审查未发现任何可利用的问题，请直接说明。不要为了显得全面而凑入信息级条目；报告过长会让真正的发现被忽视。

OWASP Top 10：2025

有三个类别相较于 2021 版更名，另有两个是新增类别（A03、A10）。请使用以下名称和编号；网上许多 OWASP 资料仍引用 2021 版列表。

#	类别	主要预防措施
A01	访问控制失效（现包括 SSRF）	默认拒绝、在服务器端强制执行、验证所有权
A02	安全配置错误	加固配置、禁用默认设置、精简功能
A03	软件供应链故障	锁定版本、验证完整性、审计依赖项
A04	加密失效	TLS 1.2+、AES-256-GCM、密码使用 Argon2/bcrypt
A05	注入	参数化查询、输入验证、安全 API
A06	不安全设计	威胁建模、速率限制、设计安全控制
A07	身份验证失效	MFA、检查密码是否已泄露、保护会话安全
A08	软件或数据完整性失效	对软件包签名、为 CDN 使用 SRI、安全序列化
A09	安全日志记录和告警失效	记录安全事件、采用结构化格式、设置告警
A10	异常情况处理不当	失败时默认关闭、隐藏内部信息、记录带上下文的日志

OWASP Top 10 for LLM Applications（2026）

适用于调用大模型的应用（聊天机器人、RAG、副驾驶、Agent）。2026 版对列表重新编号；请使用 owasp-report.md 中的表格转换 2025 年的 ID，并且只引用 2026 年的 ID。

#	风险	主要缓解措施
LLM01	提示注入	没有彻底的解决方案。隔离不可信内容（包括图像、音频和工具输出），不让模型接触权限，过滤输出
LLM02	敏感信息泄露	清理训练/RAG 数据，从上下文中移除 PII，限制模型针对每位用户可检索的内容
LLM03	过度授权	尽量减少工具和权限，对破坏性操作要求人工审批，为每项任务限定凭据的权限范围
LLM04	供应链	验证模型来源和签名，审查第三方模型库，锁定模型和适配器版本
LLM05	数据和模型投毒	验证训练/微调数据来源，在数据摄取时检测异常，进行留出数据完整性测试
LLM06	无限制消耗	按用户/密钥限制速率，限制每个请求的令牌数和工具调用次数，监控成本，设置硬性超时
LLM07	错误信息	引用来源，展示置信度，要求高风险答案基于可靠依据，并披露 AI 来源
LLM08	隐藏上下文泄露	假设系统提示词、工具架构和其他隐藏上下文都可能被提取：其中不得包含机密信息，也不得依赖其保持隐藏来实现授权或执行策略
LLM09	向量和嵌入弱点	对向量存储进行租户隔离，在检索时实施访问控制，为分块签名或计算哈希，以防间接提示注入
LLM10	输出处理不当	将所有大模型输出（包括生成的代码）视为不可信输入：在将其传递给任何接收端（SQL、shell、HTML、代码、工具调用）之前进行验证、转义或沙箱处理

OWASP Top 10 for Agentic Applications（2026）

适用于能够规划、调用工具或保留记忆的 AI Agent 系统：

风险	描述	缓解措施
ASI01：Agent 目标劫持	提示注入篡改 Agent 目标	将工具内容和检索内容视为数据，设定目标边界，监控行为
ASI02：工具滥用与利用	以非预期方式使用工具	最小权限、细粒度权限、验证输入/输出
ASI03：身份与权限滥用	利用委托信任、继承的凭据和角色链漏洞	使用短期限定范围令牌，验证身份
ASI04：Agent 供应链漏洞	插件/MCP 服务遭到入侵	验证签名、使用沙箱、将插件列入允许列表
ASI05：意外代码执行	不安全的代码生成/执行	使用沙箱执行、进行静态分析、要求人工审批
ASI06：记忆与上下文投毒	RAG/上下文数据遭到篡改	验证存储的内容，按信任级别分区
ASI07：Agent 间通信不安全	欺骗/拦截 Agent 之间的消息	验证身份、加密、验证消息完整性
ASI08：级联故障	错误在系统间传播	使用熔断器、优雅降级、隔离
ASI09：利用人对 Agent 的信任	利用用户对 Agent 的过度信任操纵用户	标记 AI 内容、开展用户教育、设置验证步骤
ASI10：恶意 Agent	被入侵的 Agent 实施恶意行为	行为监控、紧急停止开关、异常检测

ASVS 5.0 关键要求

ASVS 5.0（2025 年 5 月）对所有章节重新编号并进行了重组。4.0 的要求 ID 无法映射到 5.0——在 4.0 中，V2.1.1 表示“密码长度”，现在则表示其他内容。请仅引用 5.0 的 ID。级别根据要求所占比例定义，而非根据应用类别定义：

级别	占比	目标
L1	~20%	最低门槛；刻意设得较低，以降低入门障碍
L2	~50%（累计约 70%）	大多数应用应达到的目标
L3	剩余约 30%	最高保障级别

Level 1 — 最低要求

• 密码至少 8 个字符；强烈建议使用 15 个或更多字符（6.2.1）
• 不设字符组成规则——允许使用任意字符、粘贴密码和密码管理器（6.2.5, 6.2.7）
• 至少阻止最常见的 3000 个密码（6.2.4）
• 防范针对凭据填充和暴力破解的自动化攻击（6.3.1）
• 不设置 root/admin/sa 等默认帐户（6.3.2）
• 会话令牌应来源于熵至少为 128 位的 CSPRNG（7.2.3）
• 身份验证和重新身份验证时签发新的会话令牌（7.2.4）
• 注销或会话过期后，会话必须完全不可用（7.4.1）
• 仅根据明确的权限限制功能级和数据级访问（8.2.1, 8.2.2）
• 在客户端无法操控的可信服务层执行授权（8.3.1）
• 所有数据访问均使用参数化查询 / ORM（1.2.4）；OS 调用使用参数化方式（1.2.5）
• 根据上下文对 HTML、URL 和 JavaScript/JSON 的输出进行编码（1.2.1–1.2.3）
• 避免使用 eval() 和动态代码执行（1.3.2）
• 在可信服务层验证输入；尽可能采用正向验证 / 允许列表（2.2.1, 2.2.2）
• 所有外部流量均使用 TLS 1.2+ 和公开信任的证书（12.1.1, 12.2.1, 12.2.2）
• 仅使用获批的密码套件和模式——不得使用 ECB 或 PKCS#1 v1.5 填充（11.3.1, 11.3.2）
• 不得在 URL 或查询字符串中包含敏感数据（14.2.1）

Level 2 — 大多数应用程序应达到的要求

• 使用 MFA，或采用有文档记录的单因素组合（6.3.3）
• 检查密码是否出现在已泄露密码集合中（6.2.12）
• 不强制定期轮换密码——仅在密码泄露时轮换（6.2.10）
• 所有安全日志要求从此级别开始。 ASVS 5.0 没有任何 L1 日志记录要求；V16 的全部要求均为 L2+。记录身份验证尝试、授权失败、安全事件和意外错误（16.3.1–16.3.4）
• 日志条目包含时间 / 地点 / 人员 / 事项元数据，并使用同步时钟（16.2.1, 16.2.2）
• 对日志条目进行编码以防止日志注入，保护日志免遭篡改，并将日志发送到设备外部（16.4.1–16.4.3）
• 向用户显示通用错误消息；详细信息留在日志中（16.5.1）

Level 3 — 最高保障级别

ASVS 5.0 有 92 项 L3 要求；此处不一一列举。以下两项值得了解，因为它们收紧了 L2 要求，而非新增要求：

• 必须有一个因素基于硬件且可抵御网络钓鱼，例如 FIDO 密钥（6.3.3, L3 条款）
• 记录所有授权决策，而不仅是失败情况（16.3.2, L3 条款）

如需进行实际的 L3 评估，请以标准本身为准——章节索引见 reference/owasp-report.md。