Is Prompt Injection a Vulnerability? | Daniel Miessler

我的观点是：提示注入是一种安全漏洞，并且这很重要。

我想回应我的朋友约瑟夫·萨克的博客文章，其中讨论了提示注入是否是一种安全漏洞。

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

我站在“是”这一方，并想给出我的理由。

漏洞

信息系统、系统安全程序、内部控制或实施中可能被威胁源利用或触发的弱点。

NIST SP 800-53

反对论点

但首先，我想完善一下相反的立场，即提示注入不是一种漏洞。

在这种观点下，提示注入实际上只是一种传递机制。传递的不是漏洞本身，而是针对某个漏洞的攻击。

这就好比一根水管将有毒的水送入花园。

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

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

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

我最喜欢的类比是教皇。

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

但是，如果我们从风险管理的角度来看，他在特定日子会靠近成千上万的人，这绝对是一种漏洞。

我们不应该接受我们或许能创造性地解决的那部分重大风险。

即使我们不得不默认为这是业务过程的一部分，也并不会降低它作为漏洞的性质。

提示注入也是如此。如果我们打算在应用程序中使用AI智能体，我们必须通过语音或文本使用人类语言——这最终会变成可能被注入有害命令的文本。

当我们在考虑应用程序的整体风险时，这绝对是一种需要考虑的漏洞。

SQL注入的先例

这是另一种看待问题的方式。

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

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

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

其模式是相同的：

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

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

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

“这只是操作暴露”的反对论点

有些人对教皇的类比提出反驳： 接近性不是漏洞——这只是操作暴露。漏洞应该是筛查不充分或缺乏防弹玻璃。

但这忽略了关键点。

如果我们把接近性看作一种漏洞，我们就保持了批判性思维的开放性。我有选择重新评估目标，或许可以：

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

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

如果我们把接近性当作：

• 事情本来就是这样运作的。 或者：
• 角色固有的。 我们就关闭了这些创造性的思路。

这同样适用于LLM（大语言模型）。如果我们说：

• LLM必须接受文本输入，这本来就是固有的。 我们就停止寻找替代方案。但如果我们说：
• 无法区分指令和数据是一种漏洞。 我们可能会发现新的架构——指令签名、硬件级隔离、全新的方法。

类别错误

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

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

但这是一个类别错误。

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

正确的平行对比：

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

底线

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

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

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

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

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

注释

这篇文章是对约瑟夫·萨克的《提示注入不是一种漏洞（大多数时候）》的回应。

今年早些时候，我问萨姆·奥特曼，他认为提示注入是否会在短期内得到解决，他说他认为需要计算机科学本身的根本性进步才能解决这个问题，我同意。

从根本上说，问题在于我们使用人类语言来传输数据和指令，而它们密不可分地交织在一起。实际上，这比SQL注入的情况要糟糕得多，因为至少在SQL注入中可以选择参数化查询，而在正常的人类语言中我们则没有这种选择。

这里还有一个细微差别，约瑟夫在他的文章中很好地强调了这一点，特别是对于漏洞赏金社区。许多赏金猎人提交提示注入本身作为一种漏洞，即没有描述如何利用它，这给接收报告的公司内部的分类团队带来了很多问题。我认为这是一个例子，说明需要证明具体的攻击和影响才能被考虑。但这是因为赏金计划有不同的目标（解决具体的、尖锐的问题），这与公司内整体的安全工程团队或更广泛的行业不同。

还有另一个版本的论点/分类法，是我多年前和我的朋友杰森·哈迪克斯一起构建OWASP游戏安全框架时建立的。在那里我们有：攻击面、漏洞、攻击者目标和负面结果。

AIL Level 3：我撰写了核心论点，并与我的AI朋友Kai进行了反复的红队测试。他帮助构建了文章结构，并对类比进行了压力测试。了解更多关于AIL的信息。