AI注入攻击

当前信息安全领域的一个热门话题是：“我们如何防止AI代理被滥用？” 尽管AI引入了强大的新能力，但它也带来了一系列巨大的风险，从显而易见、平淡无奇的到深奥、精巧的，不一而足。

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

太阳底下无新事

注入攻击在网络安全领域随处可见。最明显的例子见于内存安全漏洞，攻击者通过溢出内容数据缓冲区，使得这些数据被错误地当作代码执行。该漏洞植根于常见计算架构的一个基本设计选择：“冯·诺依曼架构”，该架构将代码和数据混合存储在系统的内存中。尽管出于多种原因这很方便，但它催生了整个类别的攻击，而如果采用“哈佛架构”（数据和指令完全分离），这些攻击本可以避免。二十年前的一项重大发展——数据执行保护/不执行 (DEP/NX) 就是一种处理器特性，旨在更清晰地区分数据和代码，以防止此类错误。多年来，各种“字母汤”般的缓解措施清单只增不减。

注入攻击远不止于底层的CPU架构，而是无处不在，包括在Web平台中。Web平台采用了类似冯·诺依曼的设计，将网页的静态文本与内联脚本代码混合在一起，从而产生了无处不在的跨站脚本威胁。在这里，我们同样最终引入了保护功能，如XSS过滤器(IE)、XSS审计器(Chrome)，以及通过防止内容和脚本以危险方式混合来尝试将精灵放回瓶中的选择性加入功能（例如内容安全策略）。

我承认，对于大型语言模型AI的运作方式，我的了解还远不足以理解“哈佛架构”对于LLM是否可能实现，但从我收到的问题来看，这显然不是当前的常见架构。

我们能做什么？

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

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

最后，另一种限制风险的设计可能是限制代理的能力，要么需要监督人员的持续批准，要么采用重度沙箱，让代理在隔离的虚拟机中运行，该虚拟机无法访问任何用户信息或环境权限。如此被“阉割”后，一个被催眠的代理也无法造成太大破坏。

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

旁白：博弈论

尽管智能体AI带来了许多安全风险，产品团队仍在竞相将功能越来越强大的代理功能集成到他们的产品中（包括完成购买交易）。 AI公司竞相开发功能更强大的代理，因为每个人都担心其他AI公司中的某一家会推出一款不那么谨慎的产品，而这款功能更强大、限制更少的产品将赢得市场。因此，我们最终陷入了类似美国在20世纪50年代末的局面，当时俄罗斯拥有4枚可用的洲际弹道导弹，但美国却说服自己认为俄罗斯拥有1000枚。出于这种恐惧，美国自己也建造了1000枚洲际弹道导弹，于是俄罗斯也建造了1000枚，如此循环，直到在接下来的几十年里，我们双方基本上把世界拖入了破产的边缘。