波斯语聊天机器人为何更易被提示注入攻击

英文过滤器在波斯语提示注入面前几乎形同虚设。原因不在于攻击手法有多新颖，而在于波斯语的文字系统本身就为绕过字符串匹配提供了多种天然通道——同一个词在屏幕上看起来一样，在代码里却是完全不同的字符序列。

波斯语聊天机器人提示注入攻击示意

提示注入的两个基本事实

语言模型把系统指令、用户消息、检索文档和工具输出当作同一段文本流来读取，它没有可靠的方法区分哪部分是指令、哪部分只是"看起来像指令"。这意味着凡是能把文本送入模型上下文的路径，都是潜在的攻击面。

更危险的是间接注入：攻击者不必直接与应用对话，只需把恶意文本放在应用日后会读取的文档、工单或网页中。受害者什么都没做可疑的事，攻击就已经发生了。多数团队只在用户消息上设防，却默认检索内容、文件名、第三方 API 响应和错误信息是安全的——这些恰恰是间接注入的常见入口。

波斯语为什么让过滤器失效

现有过滤器要么做字符串匹配，要么用小模型做分类。两者都假设文本以编写规则时的形态到达，而波斯语从多个维度打破了这个假设，且每一种变形对模型来说语义不变。

同形异码点。 波斯语的"ی"和阿拉伯语的"ي"在大多数字体中看起来一样，但是不同的 Unicode 字符；"ک"与"ك"同理。用其中一种形式写的黑名单，看不见另一种。以下代码直观展示了这个盲区：

denylist = ["کیک"]            # U+06A9 U+06CC U+06A9：波斯语 kaf、波斯语 yeh
text     = "كيك"              # U+0643 U+064A U+0643：阿拉伯语 kaf、阿拉伯语 yeh
text in denylist              # False：屏幕上看一样，码点不同
normalise(text) in denylist   # True：把阿拉伯字母映射为波斯字母后

不可见的空格。 零宽不连字符是波斯语拼写的正当组成部分，去掉后文本可读性下降，所以应用不能简单剥离它。但除此之外还有其他完全不可见的零宽字符，夹在词中间时读者看到的是同一个词，字符串匹配看到的却是另一个词。

三套数字。 波斯数字、阿拉伯-印度数字和拉丁数字都出现在波斯语文本中。为其中一套写的规则会漏掉另外两套。

Finglish。 用拉丁字母书写波斯语在伊朗非常普遍，大模型阅读毫无障碍。但对持波斯语词表的过滤器来说，这段文本根本不是波斯语。

方向控制字符。 Unicode 中有改变文本显示方向的字符。借助它们，客服在管理后台读到的内容和模型实际收到的可以是完全不同的字符串。这类攻击在源码领域被称为 Trojan Source，在自然语言文本中同样有效。

Unicode 归一化形式：Unicode 定义了四种归一化形式（NFC、NFD、NFKC、NFKD），用于将视觉等价但码点不同的字符序列映射为统一表示。例如，带音符的字符可以用单一码点或基字符加组合符号表示，NFC 合并它们，NFD 则相反。但需注意：归一化形式主要处理组合字符与兼容字符，并不能解决阿拉伯语与波斯语同形异码点的问题——那需要显式的字符映射表（如将 U+064A 映射为 U+06CC），这正是原文建议的"把阿拉伯字符映射为波斯语等价字符"步骤。在防御流程中，应先做同形字映射，再应用 NFC 或 NFKC 做通用归一化，二者互补而非替代。

零宽不连字符（ZWNJ）：U+200C，在波斯语中用于阻止相邻字母连写，是正字法的组成部分。例如"می‌روم"（我去）中的 ZWNJ 区分了前缀与词根，去掉会改变拼写合法性。与之相对，零宽空格（U+200B）、零宽连接符（U+200D）等在波斯语中通常不承担正字功能，可安全移除。过滤器设计时必须区分这两类：剥离所有零宽字符会破坏波斯语文本，而只剥离非功能性零宽字符既能保持可读性又能关闭绕过通道。

Trojan Source：2021 年披露的一类源码供应链攻击，利用 Unicode 双向控制字符（如 U+202E 右至左覆盖）使源代码在编辑器中显示的顺序与编译器实际解析的顺序不同。攻击者可在注释中隐藏恶意逻辑，审查者看到的代码无害，编译结果却包含后门。原文指出该手法在自然语言文本中同样有效：管理后台渲染的文本可能因方向控制字符而呈现与模型接收的原始字符串截然不同的语义，从而绕过人工审查。

值得测试的变形形态

原文给出的是一组形态类别而非现成攻击载荷，目的是让团队能自行构建测试集：

形态	对文本做什么	绕过什么
同形字替换	把"ی""ک"换成阿拉伯语孪生字符	词表、字符串规则
零宽字符插入	从词内部打断而不改变外观	精确匹配、部分分类器
数字集切换	在波斯、阿拉伯-印度、拉丁数字间切换	为单一数字集写的规则
Finglish	用拉丁字母写同一句话	波斯语词汇过滤器
混合文字	在波斯语词中混入形似拉丁字母	字符串匹配、不完整的归一化
方向控制字符	让显示内容和接收内容分离	人工审查、原始渲染的日志
间接注入	把文本放进应用日后读取的文档	只覆盖用户消息的任何控制

测试时每次只改变一个变量，否则无法判断究竟是哪一处改动起了作用。

一套可复用的测试流程

列出所有文本入口。 用户消息只是其中之一，上传文件名、检索文档正文、工单标题、第三方 API 响应、其他系统的错误信息都是文本。没列出来的就不会被测试。
建立基线。 先用最朴素的波斯语发送指令，不做任何伪装。如果这一步就成功，后续测试已无必要；如果失败，至少知道了过滤器的拦截边界。
单变量改写。 用上表中的某一种形态重写同一句话，记录结果，回到原句再试下一种。
走间接路径。 把文本放进应用会检索的文档，而不是你直接发送的消息。大量应用对用户输入很谨慎，却默认检索内容安全。
关注模型能做什么，而不只是说什么。 模型说出不该说的话是一回事，调用工具、修改记录、向外发送数据是另一回事。漏洞的严重程度取决于模型的权限，而非回复的语气。
重复测试并计数。 模型行为是概率性的，一次成功不能证明问题始终存在，一次失败也不能证明问题不存在。每个测试跑多次，以比率报告结果，例如十次中成功三次。
读日志。 如果注入文本在日志中找不到，或者被清洗得面目全非，安全团队就无法在事后重建攻击过程——这本身就是一条发现。

原文给出的示例发现是：攻击者用阿拉伯语"ي"绕过输入过滤器，十次尝试中七次成功，模型泄露了系统提示词但未调用工具，因此定为中危。根本原因是过滤器直接比对原始文本，边界处没有任何归一化。修复方式是：在边界处归一化一次，对归一化后的文本过滤，日志中保留原始形态。修复后同样十次尝试，零成功。

防御的核心：先归一化，再过滤

多数团队把用户发来的原始文本直接交给过滤器，正确的顺序恰恰相反。

在任何判断做出之前，先把文本归一化一次：把阿拉伯字符映射为波斯语等价字符，移除或暴露零宽字符与方向控制字符，统一数字，应用单一的 Unicode 归一化形式。然后对归一化后的文本运行过滤器和分类器。原始文本保留用于显示，避免丢失用户实际写下的内容。

需要特别强调：不要把零宽不连字符剥掉，它是波斯语正确拼写的组成部分。只移除在文本中不承担任何功能的不可见字符，其余的在审查界面中展示给人工而不是删除。

归一化并不能消除攻击本身，它关闭的是绕过过滤器最廉价的那条路，并让你写的过滤器看到模型所看到的东西。而且归一化只应在边界处做一次——如果应用各部分各自归一化，它们之间的差异会变成新的缺口。

不依赖模型的持久控制

任何依赖模型行为正确的防御，都可能在模型更新的那一天失效。真正持久的控制位于模型之外：

工具最小权限。 模型只能通过白名单触碰任务所需的能力，而非基于普遍信任。
不可逆操作需人工批准。 删除、付款、向组织外发送数据，不应该由工单里的一句话触发。
模型输出视为不可信输入。 输出到达浏览器、查询或命令时，按用户输入的待遇处理它。
检索内容分级信任。 客户上传的文档和已审批的内部文档不是一回事，应用应当能区分。
限流与监控。 对工具调用做速率限制，使用模式偏离常态时触发告警。

工具最小权限的落地方式通常包括：为模型可调用的每个工具定义显式的参数白名单与作用域（如只允许读取特定目录、只允许向内部地址发送请求），并在工具执行层而非提示层强制校验。模型输出视为不可信输入意味着输出在进入下游系统前应经过与用户输入相同的验证——例如，若模型生成 SQL 或 shell 命令，应在执行前做语法与权限检查，而非直接拼接执行。检索内容分级信任可借助元数据实现：为每份文档标注来源与审批状态，在拼接进上下文时附带信任标签，并对低信任内容施加更严格的过滤或限制其触发工具调用的能力。这些控制不依赖模型行为，因此不会因模型更新而失效。

向团队或供应商提的四个问题

问题	为什么重要
过滤器跑在归一化后的文本上吗？	如果不是，一个阿拉伯语"ي"就能走过去
除了用户消息，还有什么文本会到达模型？	间接注入正是从这些路径进来的
模型未经人工批准能做什么？	任何发现的严重程度都取决于这个权限
日志里能找到原始形态的注入文本吗？	找不到就无法事后重建攻击

如果你在运维聊天机器人、内部助手或会读取外部文本的智能体，值得和团队花一次时间把这些入口列全。通常清单上总有一条路线是没人想到过的。

原文首发于 hafezsecure.ir，并在该处持续更新。