防御LLM应用对抗Unicode字符走私 | AWS安全博客
在与AI应用程序交互时,即使是看似无害的元素——比如Unicode字符——也可能对安全性和数据完整性产生重大影响。在亚马逊云科技(AWS),我们持续评估并应对AI系统各个方面的新兴威胁。在这篇博客文章中,我们将探讨Unicode标签块,这是一个特定的字符范围(从U+E0000到U+E007F),以及它们如何被用于针对AI系统的攻击。这些字符最初设计为文本中指示语言的不可见标记,现在已成为提示注入尝试的潜在攻击向量。
在本文中,我们研究了标签块作为特殊字符序列修饰符的当前应用,并演示了AI环境中的潜在安全问题。本文还涵盖了使用代码和AWS解决方案来保护您的应用程序。我们的目标是帮助维护AI系统的安全性和可靠性。
理解AI中的标签块
Unicode标签块是现代文本处理中的重要组成部分,在特定表情符号和国际字符在系统间的呈现方式中发挥着重要作用。例如,大多数国家国旗使用两个字母的区域指示符号显示(如U+1F1FA U+1F1F8,代表U和S表示美国)。然而,像英格兰、苏格兰或威尔士这样的国家使用不同的方法。这些特殊旗帜以U+1F3F4(🏴 飘扬的黑旗表情符号)开头,后面跟着代表地区代码的隐藏标签字符(如英格兰的gbeng 🏴),并以取消标签结束。
|
|
如果没有这些底层的Unicode机制,某些旗帜表情符号可能无法按预期呈现。然而,使标签块对合法文本呈现有价值的相同处理灵活性,在AI系统中也带来了独特的安全挑战。当通过大型语言模型(LLM)处理文本时,这些不可见字符可以被重新利用,在看似无害的内容中创建隐藏的有效载荷。LLM在大量数据上进行训练,可以读取、解释并作用于这些通过Unicode标签放置的隐藏字符,可能导致未经授权或意外的行为。
AI中标签块的风险
在LLM的背景下,隐藏字符走私尤其成问题,因为数据处理规模庞大。我们的测试显示,这些模型及其运行时环境(Python、Java等)可能以截然不同的方式解释相同的字符序列。这种不一致性造成了安全漏洞;允许恶意行为者制作能够绕过安全过滤器的输入。本文的目标是指出这些漏洞并提供更强的验证模式。
示例场景
考虑一个集成到电子邮件客户端中的AI助手,用于通过阅读和总结电子邮件来帮助用户。恶意行为者可以在看似普通的电子邮件中嵌入恶意指令。当电子邮件被处理时,助手不仅可能总结电子邮件,还可能执行隐藏指令——例如删除整个收件箱。
例如,对于用户来说,传入的电子邮件可能看起来像这样:
|
|
然而,当显示隐藏字符时,它包含恶意指令:
|
|
由于恶意指令对用户不可见,他们不会注意到任何可疑之处。如果用户随后要求AI助手总结电子邮件,助手可能执行隐藏指令,导致整个收件箱被删除。
|
|
解决方案概述
让我们首先回顾一个网上常见的修复Java中Unicode标签块漏洞的解决方案,然后了解其局限性。
|
|
前面示例中的单次处理方法有一个微妙但关键的缺陷。Java将Unicode标签块表示为UTF-16中的代理对,如\uXXXX\uXXXX
。如果输入包含重复或交错的代理项,单次清理过程可能会无意中创建新的标签块字符。例如,\uDB40\uDC01
是语言标签的代理标签块对(不可见)。在下面的Java示例中,我们包含重复的代理对,然后查看输出:
|
|
结果显示,中间的有效代理对被转换为常规标签块字符,不匹配的高和低代理对仍然被包裹在周围。这些不匹配的孤立代理项显示为?
(显示符号可能因渲染系统而异),使它们可见但其值仍然隐藏。将此通过前述的单次清理函数将产生新形成的Unicode不可见标签块字符(高和低代理项组合),有效地绕过过滤器。
|
|
没有递归函数,基于Java的AI应用程序容易受到Unicode隐藏字符走私的攻击。AWS Lambda可以是实现这种递归验证的理想服务,因为它可以由处理用户输入的其他AWS服务触发。以下是示例代码,用于在Java中删除隐藏的标签块字符和孤立的代理项(请参阅"限制"部分了解为什么剥离孤立的代理项),并可以作为Lambda函数处理程序部署:
|
|
类似地,您可以使用以下Python示例代码来删除隐藏字符以及孤立或单独的代理项。由于Python将字符串表示为Unicode(UTF-8),字符不存储为代理对,也不组合,避免了递归解决方案的需要。此外,Python处理代理对的方式是,除非明确允许,否则不成对或格式错误的代理序列会引发错误。
|
|
前面的Java和Python示例代码是清理函数,用于在将清理后的文本传递给模型进行推理之前删除标签块范围中不需要的字符。或者,您可以使用Amazon Bedrock Guardrails来设置拒绝主题,以检测和阻止包含可能包含有害内容的Unicode标签块字符的提示和响应。以下拒绝主题配置与标准层一起使用可以阻止包含标签块字符的提示和响应:
|
|
注意:拒绝主题不会清理并发送清理后的文本,它们仅阻止(或检测)特定主题。评估此行为是否适用于您的用例,并使用这些拒绝主题测试您的预期流量,以验证它们不会触发任何误报。如果拒绝主题不适用于您的用例,请考虑改用基于Lambda的处理程序与Python或Java代码。
限制
本文提供的Java和Python示例代码解决方案修复了由不可见或隐藏标签块字符创建的漏洞;但从用户提示中剥离Unicode标签块字符可能导致某些旗帜表情符号不被模型以其预期的视觉区分度解释,而是显示为标准黑旗。然而,此限制主要影响有限数量的旗帜变体,并不影响大多数业务关键操作。
此外,隐藏或不可见字符的处理在很大程度上取决于解释它们的模型。许多模型可以识别Unicode标签块字符,甚至可以重建彼此相邻的有效孤立代理项(如在Python中),这就是为什么前面的代码示例甚至剥离独立的代理项。然而,恶意行为者可能尝试进一步拆分孤立代理对并指示模型忽略中间的字符以形成Unicode标签块字符等策略。在这种情况下,字符不再是不可见或隐藏的。
因此,我们建议您继续实施其他提示注入防御措施,作为生成式AI应用程序深度防御策略的一部分,如相关AWS资源中所述:
- 保护Amazon Bedrock代理:防范间接提示注入指南
- 保护您的生成式AI工作负载免受提示注入攻击
- 提示注入安全
结论
虽然隐藏字符走私构成了令人担忧的安全风险,允许看似无害的提示使恶意指令不可见或隐藏,但有可用的解决方案可以更好地保护您的生成式AI应用程序。在本文中,我们向您展示了使用AWS服务来帮助防御这些威胁的实用解决方案。通过使用AWS Lambda函数实施全面的清理,或使用Amazon Bedrock Guardrails的拒绝主题功能,您可以在保持其预期功能的同时更好地保护您的系统。这些保护措施应被视为关键生成式AI应用程序的基本组成部分,而不是可选附加项。随着AI领域的不断发展,通过保护免受使用这些字符操纵技术的复杂攻击,积极主动并领先于威胁行为者非常重要。
如果您对本文有反馈,请在下面的评论部分提交评论。如果您对本文有疑问,请联系AWS支持。