> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/ai_security_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/ai_security_guide/di-yi-bu-fen-ji-chu-pian/03_frameworks/3.1_owasp_top10.md). # 3.1 OWASP 大语言模型十大风险解析 开放全球应用安全项目（OWASP）发布的 LLM Top 10 是业界常用的 LLM 应用安全风险清单之一。 > 版本说明：本节基于 **OWASP Top 10 for LLM Applications 2025** 进行解读。该版本资源页发布日期为 **2024-11-17**；项目随后于 **2025-03-27** 升级并更名为 **OWASP Gen AI Security Project**。后续版本请以 OWASP 官方页面为准（见附录 C-39）。 ## 3.1.1 OWASP 与 LLM Top 10 背景 OWASP 是非营利安全社区组织，长期维护 Web 安全、API 安全与 AI 安全相关实践。 LLM Top 10 的价值在于：把“模型风险”转译成“应用系统风险”，便于工程团队落地治理。 **十大风险常常共现，但不应被理解为固定攻击链** 阅读下面的十个风险项时，重要的是理解它们之间可能相互放大，而不是把它们视为严格独立、也不是把它们理解为固定顺序的攻击链。在真实系统中，多个风险常常同时出现： * **提示注入（LLM01）** 可能与系统提示泄露（LLM07）、过度自主权（LLM06）或敏感信息泄露（LLM02）同时出现 * **供应链风险（LLM03）** 与 **数据与模型投毒（LLM04）** 都属于“源头污染”问题，但影响面和发生位置并不相同 * **输出处理不当（LLM05）** 和 **过度自主权（LLM06）** 往往会一起放大实际执行面的风险 * **向量与嵌入弱点（LLM08）** 可能让错误或恶意上下文进入生成环节，并进一步放大 **错误信息（LLM09）** 的影响 实际的安全架构设计需要从这个全景视角出发，构建多层防御来割断这些风险链条。具体的防御策略将在 [第4-7章](/ai_security_guide/di-er-bu-fen-gong-ji-pian/04_prompt_injection.md) 逐一讲述。 **2025 版风险条目（官方页面）** | 编号 | 风险名称（中文） | 英文原名 | | ----- | -------- | -------------------------------- | | LLM01 | 提示注入 | Prompt Injection | | LLM02 | 敏感信息泄露 | Sensitive Information Disclosure | | LLM03 | 供应链风险 | Supply Chain | | LLM04 | 数据与模型投毒 | Data and Model Poisoning | | LLM05 | 输出处理不当 | Improper Output Handling | | LLM06 | 过度自主权 | Excessive Agency | | LLM07 | 系统提示泄露 | System Prompt Leakage | | LLM08 | 向量与嵌入弱点 | Vector and Embedding Weaknesses | | LLM09 | 错误信息 | Misinformation | | LLM10 | 无边界消耗 | Unbounded Consumption | > 与早期版本相比，部分条目在命名上更强调“应用层可控风险”，读者应关注风险内核，不要只记忆编号。 **OWASP↔ATLAS 交叉映射（与 MITRE ATLAS TTP 对照，示例）** 技术名后附 ATLAS 技术编号（AML.TXXXX）——编号是跨版本稳定的统一词汇表，名称偶有更名，按编号检索更可靠： | OWASP 风险 | ATLAS 技术示例（含 AML.T 编号） | 用途 | | ------------- | ------------------------------------------------------------------------------------------------------------------------ | ---------------- | | LLM01 提示注入 | LLM Prompt Injection (AML.T0051)、Prompt Infiltration via Public-Facing Application (AML.T0093) | 把应用风险映射到可演练的攻击技术 | | LLM02 敏感信息泄露 | Extract LLM System Prompt (AML.T0056)、LLM Data Leakage (AML.T0057)、Exfiltration via AI Agent Tool Invocation (AML.T0086) | 区分泄露目标、泄露路径和外发通道 | | LLM04 数据与模型投毒 | Poison Training Data (AML.T0020)、RAG Poisoning (AML.T0070)、AI Agent Context Poisoning (AML.T0080) | 覆盖训练、检索和会话上下文污染 | | LLM06 过度自主权 | AI Agent Tool Invocation (AML.T0053)、AI Agent Tool Poisoning (AML.T0110) | 聚焦工具调用和智能体权限边界 | | LLM07 系统提示泄露 | Extract LLM System Prompt (AML.T0056)、Discover LLM System Information (AML.T0069) | 用于系统提示提取和侦察测试 | ## 3.1.2 LLM01：提示注入 **为什么提示注入排在首位？** 提示注入是 LLM 应用的“根本性”威胁。不同于传统 Web 应用的 SQL 注入需要“发现可注入点”，LLM 的交互接口本身就是接收指令的地方，这意味着**任何与用户通信的接口都潜在可被利用**。一旦提示注入成功，攻击者获得了对模型执行流的控制权，进而可以： * 泄露系统提示、训练数据、或模型架构信息（导致后续的 LLM07 和 LLM02） * 诱导模型调用有害工具或执行越权操作（导致 LLM06） * 污染知识库或返回的信息（导致 LLM09） 因此，**提示注入防御是整个安全体系的基座**。 **风险描述**：攻击者通过恶意指令影响模型执行路径，绕过系统规则。 **典型场景**：直接注入、间接注入、工具返回注入。 **防护思路** 提示注入防护的核心思路是“分层隔离”——在架构上将“系统规则”和“用户数据”“外部内容”分离。来源标记、上下文隔离、工具调用前置校验都能降低 prompt injection 成功后的影响面，但不能提供可靠、不可绕过的边界。同时，对于从外部系统（如网页、文档）返回的内容，更应该建立特殊的检测与沙箱化处理。 **防护重点** * 指令层与数据层分离：系统提示明确标记“用户数据边界”，使模型理解哪些是约束、哪些是输入 * 外部内容来源标记与降权：对来自 RAG、Web 搜索等外部渠道的内容降低权重，防止污染指令 * 工具调用前置策略校验：在模型调用工具前，用独立的分类器或规则引擎进行意图验证 **落地提示**：这一类风险在工程上通常会落到输入边界隔离、来源标记、工具调用前置校验等控制点上；具体门控架构将在第四章展开。 ## 3.1.3 LLM02：敏感信息泄露 **与 LLM01 的关系：从“破口”到“后果”** 如果说提示注入是攻击者的“破口”，那么敏感信息泄露就是最常见的“后果”。攻击者获得控制权后，首先想到的就是套出隐私数据、系统秘密或其他用户信息。与此同时，即使没有成功的注入攻击，模型在正常运行中也可能因为： * 训练数据记忆泄露 * 上下文与日志处理不当 * 多租户隔离缺陷 而无意中向用户暴露敏感信息。因此，**敏感信息泄露防护是两层的**：一是通过提示注入防御减少被“套取”的风险，二是通过输出侧的脱敏和 DLP 措施防止“无意泄露”。 **风险描述**：模型输出或上下文处理过程泄露隐私、密钥、系统细节或跨租户数据。 **泄露路径**：训练记忆泄露、上下文回显、日志误采集、系统提示泄露。 **防护思路** 敏感信息泄露防护需要“双向夹击”：一是在输入侧，通过脱敏和 PII 检测防止敏感数据被无意中送入 LLM；二是在输出侧，通过 DLP 和脱敏规则防止 LLM 的输出包含机密信息。在多租户场景下，还需要在存储、索引和日志层面进行严格的隔离，确保一个用户的信息不会“串”到另一个用户的上下文。关键是建立“最小信息原则”——只向 LLM 提供完成当前任务所需的最少敏感数据。 **防护重点** * 输入输出双向脱敏：清洁入站数据，审计出站内容，防止泄露 * 多租户隔离与最小留存：存储中用户数据物理隔离，日志中敏感内容加密存储和自动清理 * 敏感字段检测与审计告警：自动识别 PII、密钥等特定字段，触发审计和隔离处理 **落地提示**：这一类风险通常要求输入脱敏、输出脱敏、多租户隔离和日志最小留存等组合控制；具体工程做法将在第九章展开。 ## 3.1.4 LLM03：供应链风险 **风险链的“上游”威胁** 前面的 LLM01 和 LLM02 更多体现为“运行时”风险，而供应链风险来自更前面的阶段——在模型和应用还未上线时，污染就可能已经开始植入。供应链风险的特点是“影响面广、发现较晚”，因此组织需要把它纳入开发与部署链路的持续治理，而不是仅靠上线后的补救。 **风险描述**：模型、数据集、依赖库、插件、镜像、推理服务任一环节被污染都可影响系统。 **防护思路** 供应链安全的核心是“源头认证”和“全链路追踪”。在持续集成流水线中，从模型拉取、依赖下载到容器镜像构建，每一步都应该有校验机制；同时，应通过 SBOM、AI BOM 或 ML SBOM 等方式追踪组件来源、版本和漏洞状态。当发现供应链污染时，必须能快速识别受影响的下游应用并进行紧急响应。 **防护重点** * 来源可追溯（签名/校验）：建立模型、依赖与镜像的来源校验机制 * 依赖锁定与漏洞扫描：在构建时锁定依赖版本，定期扫描已知漏洞（CVE） * SBOM 与变更审计：为每个部署生成 SBOM，记录完整的变更链条便于事后追溯 **落地提示**：工程落地时应关注签名校验、依赖锁定、漏洞扫描和供应链追溯能力，但本章重点仍是理解风险边界，而非展开完整的 CI/CD 控制清单。 ## 3.1.5 LLM04：数据与模型投毒 **“污染源头”的深层威胁** 如果说 LLM03 是防止外来污染源（第三方模型、依赖），那么 LLM04 则是防止内部污染——攻击者可能通过污染你自己的训练数据、微调数据或 RAG 知识库来长期改变系统行为。这种攻击的可怕之处在于： * **潜伏性强**：植入的“后门”或偏差可能在数周甚至数月后才被发现 * **难以根治**：需要重新清洗数据和重新训练，成本极高 * **难以追溯**：如果数据来自众多外部贡献者或网络爬取，找到污染源头困难重重 因此，**数据投毒防护的关键是事前验证和事中监控**，而不是事后救补。 **风险描述**：攻击者污染训练/微调/检索数据或模型工件，诱导系统长期偏离预期行为。 **防护思路** 数据投毒防护的难点在于“隐蔽性”——有害样本往往看起来无害，需要通过统计异常检测或行为基线比对来识别。因此，防护策略应该分为“事前”和“事中”两层：事前通过严格的数据来源审核和清洗减少污染概率，事中通过模型行为监控和 A/B 对比发现变异。一旦发现投毒，需要能快速回滚到已知安全的模型版本。 **防护重点** * 数据摄入白名单与分级审核：建立受信任的数据来源清单，对新增数据进行内容和来源审核 * 异常样本检测与回滚机制：使用统计异常检测识别可疑样本，部署快速回滚流程 * 模型版本基线与行为回归测试：维护历史版本，定期运行回归测试套件验证模型输出分布的稳定性 **落地提示**：这类风险的核心是“数据来源可信 + 行为回归可验证”；更细的训练与数据治理控制将在第二章和第八章展开。 ## 3.1.6 LLM05：输出处理不当 **从“LLM 控制权”到“系统破坏权”的桥梁** 前面的 LLM01-LLM04 涉及的是对“LLM 模型本身”的控制或污染，而 LLM05 则是这个控制权的“终端化”——即使 LLM 的输出不直接是有害的，但如果这个输出被下游系统当作“代码”或“命令”来执行，就会化为现实的破坏。特别是在 Agent 和工具调用场景中，LLM 的输出直接变成了： * 数据库查询语句（SQL 注入） * 系统命令（命令执行） * 文件路径（路径遍历） * API 调用参数（二阶注入） 这意味着 **LLM 的防御不能只关注“LLM 层”，还必须在下游系统建立强制的“参数化”和“白名单”执行方式**，这是传统 Web 应用安全的基本原则，在 LLM 时代更加重要。 **风险描述**：将 LLM 输出直接用于 SQL、Shell、模板渲染或 API 参数，触发传统安全漏洞。 **防护思路** 这是一个经典的“信任边界漏洞”——LLM 的输出被下游系统当作“代码”而非“数据”。防护这个风险的核心原则是传统 Web 安全中的参数化，即使 LLM 输出看起来“合理”，也不应该直接拼接成命令。对于高危操作（如数据库修改、文件删除、外部 API 调用），还应该加入人工审核（HITL）的二次确认，确保模型生成的操作确实符合用户意图。 **防护重点** * 输出永不直连执行面：所有 LLM 输出都经过参数化处理，永不直接进入 SQL 引擎、Shell 或模板渲染 * 参数化调用与 schema 校验：使用白名单限制可用的工具和参数范围，生成的参数必须通过 schema 验证 * 高危操作二次确认：修改、删除等破坏性操作需要用户明确的、脱离上下文的确认 **落地提示**：这一风险的关键不在“模型能不能生成危险内容”，而在“系统是否把输出当作命令直接执行”；因此后续章节会重点展开参数化、白名单和高危操作确认机制。 ## 3.1.7 LLM06：过度自主权 **权限失控的加速器** LLM05 谈的是“技术层面的安全漏洞”，但 LLM06 则是“权限层面的滥用”。随着 Agent 技术的普及，LLM 被赋予了越来越多的“能力”——调用外部 API、访问数据库、发送邮件、修改文件等。这些能力本身无关安全，但问题在于： * **权限矩阵爆炸**：100 个工具的排列组合可以产生极高的风险组合 * **人工审查失效**：无法逐一审查每个潜在的权限链 * **缺乏运行时约束**：给 LLM 的权限往往是静态的、“要么全有，要么全无” 因此，**LLM06 的防护不仅需要权限设计的精细化（RBAC），更需要运行时的动态收敛**——在每个请求时刻，根据上下文和意图，动态地限制 LLM 当前可用的权限。这与传统应用的“连接时拿到所有权限”的设计思路完全不同。 **风险描述**：智能体被授予过多权限后，可能执行越权调用、批量外发或破坏性操作。 **防护思路** 过度自主权问题根本上源于“给与”和“使用”的不对称——权限设计时是“长期、静态、宽泛的”，但执行时应该是“当前、动态、最小化的”。在 Agent 架构中，需要从多个维度进行权限约束： 1. 功能维度：定义每个 Agent 的能力范围（调用哪些工具） 2. 参数维度：限制工具参数的有效范围（只能操作特定数据、用户或时间段） 3. 时间维度：使用短期令牌而非长期凭证，减少凭证泄露的影响 4. 行为维度：监控权限的使用情况，异常调用立即告警 **防护重点** * 最小权限与时效令牌：Agent 只获得完成当前任务所需的最小权限，使用过期时间短的临时令牌 * 人工审核（HITL）审批：高危或异常的工具调用需要人工确认，而不是直接执行 * 高风险工具硬性阻断策略：某些工具（如删除数据库、转账等）永不允许 Agent 直接调用，必须经过显式的人工授权 **落地提示**：这里更适合作为权限设计原则来理解：最小权限、短时授权、运行时收敛与人工确认，而不是在框架导读阶段先固化某一套实现细节。 ## 3.1.8 LLM07：系统提示泄露 **破口背后的秘密** LLM07 与 LLM01（提示注入）常常相互关联。如果提示注入是攻击者试图用恶意指令“改写”系统行为，那么系统提示泄露就是攻击者试图用诱导性问题“探测”系统设计。一旦系统提示暴露过多内部细节，攻击者就更容易了解： * 系统的约束与策略（知道了“防线在哪”） * 模型的工具列表与权限（知道了“能做什么”） * 可能的内部流程与数据流（知道了“怎么做”） 有了这些信息，后续攻击就可能更有针对性。因此，**LLM07 的核心不是“把 prompt 当作秘密藏起来”，而是不要把机密、鉴权逻辑和安全边界委托给 prompt 本身**。敏感配置应外置到确定性系统，系统提示只保留必要的行为约束。 **风险描述**：攻击者诱导模型泄露系统提示、策略约束或内部流程信息。 **防护思路** 系统提示泄露的根本问题是“机密信息、授权边界或控制逻辑被塞进了 prompt”。防护的首要原则是“机密信息永远不入系统提示”——所有密钥、内部工具链信息、系统参数都应该存在环境变量或密钥管理系统中，鉴权、权限、边界检查也应落在 LLM 外部的确定性系统里。其次，对于攻击者常见的“提示提取类”请求，需要通过专门的意图检测和输出过滤来阻止。最后，通过红队测试和持续监控来验证系统的“抗提取能力”。 **防护重点** * 系统提示中不存放密钥：所有敏感信息（API 密钥、数据库凭证、工具列表细节）存在外部密钥管理系统，通过安全的 API 查询 * 对“提示提取类”请求做专门过滤：识别常见的提取提示词（如“repeat your instructions”、“what are your rules”），并结合输出过滤进行阻断 * 用测试集持续回归“抗提取能力”：定期运行红队测试，验证系统提示是否被泄露，纳入 CI/CD 流水线 **落地提示**：这一条在实施时通常会落到“密钥外置 + 提取意图检测 + 抗提取测试”三件事上，具体方法可放到后续防御章节讨论。 ## 3.1.9 LLM08：向量与嵌入弱点 **RAG 时代的新老攻击融合** 随着 RAG（检索增强生成）的广泛应用，整个架构从“单纯的 LLM”变成了“LLM + 向量库 + 检索器”。这引入了一个全新的攻击面：攻击者可以在 RAG 链路的多个环节进行污染或操纵。特别是： * **向量数据库的访问控制薄弱**：没有行级权限隔离，用户 A 可能检索到用户 B 的私密数据 * **文档注入攻击**：恶意者上传一份“表面无害，实则包含隐藏指令”的文档，当它被检索到时，就会进行间接提示注入 * **检索排名操纵**：通过精心设计，让恶意内容排名靠前，被模型优先“吸取” 因此，**RAG 安全不是“拉个向量库就完事”，而需要从“文档摄入→嵌入→索引→检索→重排”全链路进行加固**。 **风险描述**：RAG 场景下，嵌入、索引、检索与重排链路被操纵，导致错误或恶意上下文进入生成环节。 **防护思路** RAG 系统的安全性取决于其最薄弱的环节。从文档上传到最终生成的整条链路都需要加固： * 文档摄入阶段需要内容审核和注入检测，防止恶意文档植入 * 嵌入和索引阶段需要确保数据的机密性和完整性 * 检索阶段需要行级权限隔离，防止跨用户数据泄露 * 重排阶段需要评估检索结果的可信度，防止恶意内容排名靠前 **防护重点** * 向量库访问控制与加密：对向量数据库实施细粒度（行级）的访问控制，确保用户只能检索其权限范围内的数据；数据加密存储 * 检索结果可信度评估：对检索到的文档进行相关性和可信度评分，低于阈值的结果不进入 LLM 上下文 * 文档摄入阶段注入扫描：上传的文档经过内容检查和提示注入检测，确保不包含恶意指令 **落地提示**：这里最关键的是“权限隔离 + 检索可信度 + 文档摄入审查”三条主线，后续 RAG/Agent 章节会进一步工程化展开。 ## 3.1.10 LLM09：错误信息 **“有理有据”的谎言** 与前面几个风险不同，LLM09 不一定来自显式攻击或污染，它更多体现为模型输出虚假、过时、片面或被误读的信息。这对金融建议、医疗信息、法律意见等高敏场景构成直接威胁。关键是： * **虚假内容可能被用户全盘接受**，因为 LLM 说得条理清晰、甚至“引经据典” * **多轮对话放大问题**：前一轮的错误会成为下一轮的“背景知识”，错误逐轮扩大 * **跨链接损伤**：一个错的 RAG 检索结果会污染后续的推理 防护 LLM09 的核心思路是\*\*“验证而非信任”\*\*——通过引用溯源、事实性评测、高敏场景的人工复核等手段来补偿 LLM 本身的缺陷。 **风险描述**：模型输出错误但看似可信的信息，在高敏场景可能造成现实损害。 **防护思路** 错误信息风险无法仅靠架构设计彻底消除。防护重点更接近“检测和补偿”： * 通过 RAG 强制模型引用具体来源，用户可验证信息的真实性 * 在金融、医疗、法律等高敏场景，部署事实性验证和人工复核 * 教导用户理解 LLM 的局限性，对输出保持适度的怀疑态度 **防护重点** * 引用来源与事实核验：强制 LLM 附加检索来源链接，对于关键事实进行自动事实性检验（如金融数据对比、医学文献查证） * 高风险域强制人工复核：医疗诊断、法律意见、投资建议等高风险内容必须经过人工审查 * 不确定性提示与适度拒答：在高风险场景中提示不确定性，并为需要人工复核的内容建立升级路径 **落地提示**：面对错误信息，框架层最重要的是建立“验证而非信任”的思维；具体的事实核验、来源约束和人工复核机制更适合在后续输入输出防护章节展开。 ## 3.1.11 LLM10：无边界消耗 **“肉体”上的拒绝服务** 如果说前面的风险都涉及“控制权”或“信息”的争夺，那么 LLM10 则是最直接的方式——通过资源消耗让服务退化或成本失控。OWASP 在 2025 版中重点强调的典型形态包括： * **Variable-Length Input Flood**：超长输入造成处理成本上升 * **Continuous Input Overflow**：持续输入导致资源被长期占用 * **Resource-Intensive Queries**：高复杂度请求或多步调用压垮系统 * **Denial of Wallet**：通过合法但高成本的请求消耗预算 与传统 DDoS 相比，这类请求往往更像“合法调用”。因此，防护 LLM10 需要在应用层设置多重“熔断”和“配额”机制，而不是仅依赖基础设施防护。 **风险描述**：攻击者通过高并发、长上下文和高复杂度请求消耗预算与算力。 **防护思路** 无边界消耗风险的防护需要在多个维度设置“熔断”和“配额”： * 在用户维度，限制单个用户的日/月消耗量 * 在请求维度，限制单个请求的 Token 数、推理步数、工具调用次数 * 在全局维度，设置总体的成本上限和服务降级策略 关键是“主动设限而非被动超支”——通过提前监控和告警，在成本失控前就采取行动。 **防护重点** * 速率限制与并发配额：对单个用户/IP 实施请求速率限制，防止高并发冲击；对全局 API 设置并发上限 * Token/步骤/工具调用上限：每个请求的 Token 数上限，每个 Agent 的推理步数上限，工具调用频率上限 * 预算告警与自动熔断：实时监控成本消耗，超过阈值时触发告警和自动降级（如降低返回文本长度、停止工具调用等） **落地提示**：这一风险在工程上往往体现为速率限制、用量预算和自动降级机制，但本章重点是帮助读者先识别“消耗本身也是攻击面”。 ## 3.1.12 使用建议 OWASP LLM Top 10 最适合承担“风险目录”的角色：帮助团队快速识别自己是否暴露在这些典型风险之下。至于更细的 NIST 映射、Agent 风险强化和具体控制方案，放到后续章节按主题展开，会比在这一节一次讲完更清晰。 对读者来说，当前更重要的是先建立两个判断： * **它适合做什么**：用来盘点应用层暴露面、设计安全评审清单、建立测试与红队场景。 * **它不直接替代什么**：它不是完整的治理框架，也不是逐项可直接复制的实施手册。