AI注入攻击

近来信息安全领域的一个热门话题是：“我们如何防止AI代理被滥用？” 虽然AI带来了令人惊叹的新能力，但它也带来了巨大的风险，从显而易见且普通的，到深奥且复杂的都有。

作为一名浏览器安全从业者，我最常被问及的是间接提示注入攻击。在这种攻击中，客户端的AI（例如浏览器内或设备上的AI）被分配与互联网内容交互的任务。这里的威胁在于，AI代理可能会错误地将它交互的网页内容视为其用户的指令，从而被“催眠”，落入该网页内容作者的控制之下。恶意网页内容随后可以指示这个AI代理（现在是一个“困惑的代理人”）执行不安全的操作，例如分享用户的隐私数据、使用该用户的电子钱包进行交易等。

万物皆非新事

注入攻击在整个网络安全领域随处可见。 最明显的例子是内存安全漏洞，攻击者通过溢出内容数据缓冲区，使得数据被错误地当作代码执行。这种漏洞根源于通用计算架构的一个基本设计选择：“冯·诺依曼架构”，即代码和数据在系统内存中混合在一起。尽管这在很多方面很方便，但它催生了一整个类别的攻击，而“哈佛架构”（数据与指令完全分离）本可以阻止这类攻击。大约20年前的一项重大进展——数据执行保护/不可执行（DEP/NX），是一个处理器功能，旨在更清晰地划分数据和代码，试图防止这种错误。多年以来，各种“字母汤”般的缓解措施清单还在不断增加。

注入攻击远远超出了低级CPU架构的范畴，无处不在，包括在Web平台中。Web平台采用了类似冯·诺依曼的设计，网页的静态文本与内联脚本代码混合在一起，由此产生了始终存在的跨站脚本（XSS）威胁。同样，我们最终也开发出了诸如XSS过滤器（IE）、XSS审计器（Chrome）等保护功能，以及像内容安全策略（CSP）这样的选择性功能，通过防止内容和脚本以危险方式混合，试图将精灵重新放回瓶子里。

我承认，我对于LLM AI的工作原理了解不够深入，无法理解“哈佛架构”对于LLM是否可行，但从我收到的问题来看，它显然不是目前常见的架构。

我们能做些什么？

在一个AI易受注入攻击的世界里，我们能做什么？ 一种方法是确保代理无法加载“不安全”的网络内容。由于我在SmartScreen（一项用于阻止访问已知不安全站点的信誉服务）工作，我经常被问到，我们是否能够像阻止普通人类浏览器用户一样，阻止代理访问不良站点。是的，我们应该并且正在这样做，但这远远不够：SmartScreen会阻止被发现进行网络钓鱼、分发恶意软件或进行技术诈骗的站点，但不良站点的数量每时每刻都在增长，而且目前一个正在进行提示注入攻击的站点甚至不太可能被识别出来。

如果阻止不良站点不起作用，也许我们可以只允许“已知良好”的站点？这也有问题。本质上不存在“可信站点列表”这样的概念。SmartScreen最接近的是一个“高流量站点”列表，但这仅反映了被认为是SmartScreen所针对的特定类型恶意威胁（如网络钓鱼、恶意软件、技术诈骗）不太可能来源的高流量站点列表。更糟糕的是——许多“已知良好”的站点包含不受信任的内容，例如用户生成的评论/帖子、广告、来自其他网站的文本片段等。允许不受信任的第三方内容的“已知良好”站点，可能成为提示注入攻击的潜在来源。

最后，另一种限制风险的设计可能是限制代理的能力，要么要求监督人员不断批准，要么采用严格沙箱化，使代理在隔离的虚拟机中运行，无法访问任何用户信息或环境权限。这样被“阉割”后，一个被催眠的代理也无法造成太大损害。

不幸的是，任何在沙箱中运行的代理都无法访问对实现引人注目的场景至关重要的资源（例如用户的数据或凭证）（例如“在一家不错的餐厅订一张两人桌，订花，并发送日历提醒邮件给我的妻子”），这使得沙箱化的代理对普通人来说可能吸引力大减。

题外话：博弈论

尽管智能AI带来了许多安全风险，但产品团队仍在竞相将能力越来越强的代理功能集成到他们的产品中（包括完成购买交易）。

AI公司正在竞相推出能力越来越强的代理，因为每个人都害怕其他AI公司中的一家会推出不那么谨慎的产品，而那个功能更强大、限制更少的产品将赢得市场。因此，我们最终陷入了类似20世纪50年代末美国的情况，当时俄罗斯拥有4枚可用的洲际弹道导弹，但美国却说服自己他们拥有1000枚。由于这种恐惧，美国自己也建造了1000枚洲际弹道导弹，于是俄罗斯也建造了1000枚，如此循环，在接下来的几十年里，我们基本上让世界破产了。