提示注入：是漏洞还是攻击载体？深度剖析AI安全的核心争议

提示注入是一种漏洞吗？

我想回应我朋友约瑟夫·撒克关于提示注入以及它是否属于漏洞的博客文章。

提示注入并非漏洞（大多数情况下）
提示注入几乎从来不是AI漏洞的根本原因——真正的问题在于模型被允许做什么

所以，我是和约瑟夫辩论提示注入是否是漏洞的朋友之一。

我属于“是”的阵营，并且我想给出我的理由。

漏洞

信息系统、系统安全程序、内部控制或实施中的一个弱点，可能被威胁源利用或触发。 —— NIST SP 800-53

反方论点

但首先，我想为相反的立场——即提示注入不是漏洞——构建一个有力的辩驳。

在这种观点看来，提示注入实际上只是一种投送机制。并非针对漏洞，而是针对攻击目标的漏洞。

所以，这就像一根水管将毒水送入花园。

• 水管不是漏洞（它是投送机制）
• 毒药不是漏洞（它是攻击）
• 对毒药的易感性是漏洞
• 花园里的植物是目标

这相当有说服力，现在让我告诉你为什么我不同意。

我们需要考虑系统的整体风险

我最喜欢的类比是教皇。

教皇必须走进人群，并与成千上万的人极其接近。这种物理上的接近是一个漏洞。可能被用来对付他的实际攻击——毒药、吹箭、枪击、拳击——那是攻击。他的身体脆弱可能是另一个漏洞。

但如果我们从风险管理的角度来看，他在特定日期将接近成千上万的人这件事，绝对是一个漏洞。

我们不应该接受我们可能能够创造性解决的重大风险部分。

如果我们不得不默认为业务的一部分而接受它，并不会使它减少漏洞的性质。

提示注入也是如此。如果我们打算在我们的应用程序中使用AI智能体，我们必须通过语音或文本使用人类语言——这最终会变成可能被注入有害命令的文本。当我们在考虑应用程序的整体风险时，这绝对是需要被考虑的一个漏洞。

SQL注入的先例

这是另一种看待它的方式。

SQL注入被普遍归类为一种漏洞（CWE-89）。没有人认为SQLi仅仅是：

• 一种攻击向量。
• 或：仅仅是一条传输线。

我们称之为漏洞，因为数据库无法区分查询结构和用户提供的数据。

模式是相同的：

• SQL注入：用户输入被解释为SQL命令
• 提示注入：用户输入被解释为系统指令

两者都源于相同的架构缺陷——将控制平面与数据平面混合。安全行业花了几十年的时间才认识到，输入通道本身并不是漏洞；漏洞在于解析层对代码和数据的根本性混淆。

如果我们接受CWE-89是一个漏洞，那么智力上的一致性要求我们对提示注入应用相同的分类逻辑。

“这只是操作暴露”的反驳

有些人对教皇的类比提出异议：

接近性不是漏洞——这只是操作暴露。漏洞将是筛查不足或缺乏防弹玻璃。

但这就是这种观点所忽略的。

如果我们将接近性视为漏洞，我们就保持我们的批判性思维开放。我有选择去重新评估目标，也许：

• 全息投影教皇
• 使用替身
• 等等。

换句话说，我们可能会找到实现目标的新方法，从而降低风险。

如果我们否认接近性是漏洞，认为它“只是事情运作的方式”或“角色固有的”，我们就关闭了这些创造性的思路。

这同样适用于大语言模型。如果我们说“LLM必须接受文本输入，这是固有的”，我们就会停止寻找替代方案。但如果我们说“无法区分指令和数据是一种漏洞”，我们可能会发现新的架构——指令签名、硬件级别的分离、全新的方法。

范畴错误

我的AI朋友Kai对此论点进行了红队测试。是的，真的——我实际上为此建立了一个红队技能。他最初犯了一个值得强调的错误，这个错误实际上教了我很多：

教皇的类比失败，是因为教皇理论上可以与人群隔离，而LLM无法与语言输入隔离。

但这是一个范畴错误。

LLM没有目标——应用程序才有目标。LLM只是一个组件，就像教皇的物理身体是一个组件一样。你不会问“教皇身体的目标是什么”——你会问“教皇的目标是什么”。

正确的平行关系是：

具有目标的实体	组件	组件中的漏洞
教皇	物理身体/存在	必须靠近人群
应用程序	LLM	无法区分指令与数据

教皇和应用程序都有目标（服务信徒 / 服务用户）。两者都使用了具有固有局限性的组件，从而产生了风险。两者都可能被重新架构——教皇通过全息投影，应用程序通过不同的架构来实现相同的目标，而无需LLM的漏洞特征。

底线

所以，在我看来，提示注入是一种漏洞，因为：

1. 它是一个可能被攻击的技术问题，并且增加了系统的整体风险水平
2. 它与SQL注入非常相似，即无法区分指令和数据
3. 将这样一个系统视为只是无法解决的背景风险，会扼杀围绕如何降低该风险的创造性思考
4. 我们可能不得不接受此漏洞作为业务成本（至少在2025年）这一事实，并不会使其减少漏洞的性质。

教皇接受接近性的风险，因为他的使命需要它。组织接受提示注入风险，因为他们的应用程序需要人类与其AI驱动的界面交互。这很公平。

但接受当前现实，不应等同于将其视为背景噪音而一笔勾销。

作为防御者和研究人员，我们需要将其视为一个活跃的漏洞，以便我们能够缓解并可能随着时间的推移解决它所构成的风险。

注释

• 这篇文章是对约瑟夫·撒克的《提示注入并非漏洞（大多数情况下）》的回应。
• 今年早些时候，我问Sam Altman他是否认为提示注入会很快得到解决，他说他认为解决这个问题需要计算机科学本身取得根本性的进展，我同意。
• 从根本上说，问题在于我们使用人类语言来传输数据和指令，而它们不可分割地交织在一起。实际上这比SQL注入的情况要糟糕得多，因为至少参数化查询是一个选项，而我们在正常的人类语言中没有这个选项。
• 这里还有一个细微差别，约瑟夫在他的文章中很好地强调了这一点，特别是对于漏洞赏金社区。许多猎人单独提交提示注入作为漏洞，即没有描述如何利用它，这给接收报告的公司内部的分类团队带来了很多问题。我认为这是一个需要展示具体攻击和影响才能被考虑的案例。但这只是因为赏金计划有不同的目标（解决特定的、尖锐的问题），而不同于公司的整体安全工程团队或更广泛的行业。
• 这个论点/分类法还有另一个版本，是我多年前和我的朋友Jason Haddix一起构建OWASP游戏安全框架时建立的。在那里我们有：攻击面、漏洞、攻击者目标和负面结果。
• AIL 第3级：我撰写了核心论点，并与我的AI朋友Kai进行了反复的红队测试。他帮助构建了文章结构并压力测试了这些类比。了解更多关于AIL的信息。
  更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）
  对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）

公众号二维码

公众号二维码