AI注入攻击

如今信息安全领域的一个热门话题是“如何防止AI代理被滥用？”虽然AI带来了令人惊叹的新能力，但也伴随着从明显平凡到深奥复杂的巨大风险。

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

太阳底下无新事

注入攻击在网络安全领域随处可见。最明显的例子是内存安全漏洞，攻击者通过溢出内容数据缓冲区，使数据被错误地当作代码处理。该漏洞根源于常见计算架构的基本设计选择：“冯·诺依曼架构”，其中代码和数据在系统内存中混合存放。虽然这在许多方面很方便，但却催生了一整类攻击，而“哈佛架构”（其中数据和指令完全分离）本可以防止这些攻击。二十年前的主要发展之一——数据执行保护/不执行（DEP/NX）是一种处理器功能，旨在更清晰地区分数据和代码，以防止这种错误。多年来，“字母汤”式的缓解措施列表只增不减。

注入攻击远不止于低级CPU架构，在Web平台中也随处可见。Web平台采用了冯·诺依曼式设计，网页的静态文本与内联脚本代码混合在一起，从而产生了无处不在的跨站脚本威胁。同样，我们最终推出了XSS过滤器（IE）、XSS审计器（Chrome）等保护功能，以及通过内容安全策略等可选功能，防止内容和脚本以危险方式混合。

我承认自己对LLM AI的运作方式了解不够，无法理解“哈佛架构”对LLM是否可行，但从我收到的问题来看，它显然不是常见的架构。

可以采取什么措施？

在AI容易受到注入攻击的世界里，我们能做些什么？

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

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

最后，另一种风险限制设计可能是限制代理的能力，要么需要监督人员不断批准，要么采用重度沙盒，使代理在隔离的虚拟机中运行，无法访问任何用户信息或环境权限。如此受限后，被催眠的代理也无法造成太大损害。

不幸的是，任何在沙盒中运行的代理都无法访问对实现引人注目的场景（“在一家不错的餐厅预订两人桌，订购鲜花，并向我妻子发送日历提醒邮件”）至关重要的资源（例如用户数据或凭据），因此沙盒化的代理对日常人类的吸引力可能大打折扣。

旁白：博弈论

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

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