# 3.1 OWASP 大语言模型十大风险解析 开放式 Web 应用安全项目（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 | > 与早期版本相比，部分条目在命名上更强调“应用层可控风险”，读者应关注风险内核，不要只记忆编号。 **与 MITRE ATLAS TTP 的交叉映射（示例）** | OWASP 风险 | ATLAS 技术示例 | 用途 | | ------------- | ------------------------------------------------------------------------------------ | ---------------- | | LLM01 提示注入 | LLM Prompt Injection、Prompt Infiltration via Public-Facing Application | 把应用风险映射到可演练的攻击技术 | | LLM02 敏感信息泄露 | Extract LLM System Prompt、LLM Data Leakage、Exfiltration via AI Agent Tool Invocation | 区分泄露目标、泄露路径和外发通道 | | LLM04 数据与模型投毒 | Poison Training Data、RAG Poisoning、AI Agent Context Poisoning | 覆盖训练、检索和会话上下文污染 | | LLM06 过度自主权 | AI Agent Tool Invocation、AI Agent Tool Poisoning | 聚焦工具调用和智能体权限边界 | | LLM07 系统提示泄露 | Extract LLM System Prompt、Discover LLM System Information | 用于系统提示提取和侦察测试 | ## 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 风险强化和具体控制方案，放到后续章节按主题展开，会比在这一节一次讲完更清晰。 对读者来说，当前更重要的是先建立两个判断： * **它适合做什么**：用来盘点应用层暴露面、设计安全评审清单、建立测试与红队场景。 * **它不直接替代什么**：它不是完整的治理框架，也不是逐项可直接复制的实施手册。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://yeasy.gitbook.io/ai_security_guide/di-yi-bu-fen-ji-chu-pian/03_frameworks/3.1_owasp_top10.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.