揭示 AI 过滤器中的安全漏洞：使用字符代码绕过限制的深入研究

介绍

和许多其他人一样，在过去几天里，我的新闻推送充斥着关于中国制造的 DeepSeek-R1 大语言模型的新闻、赞扬、抱怨和猜测，该模型于上周发布。该模型本身正被拿来与 OpenAI、Meta 等公司的一些最佳推理模型进行比较。据报道，它在 各种基准测试 中具有竞争力，这引起了 AI 社区的关注，尤其是因为据称 DeepSeek-R1 的训练使用了 明显更少的资源 与其竞争对手相比。这引发了关于更具成本效益的 AI 开发潜力的讨论。虽然我们可以就其影响和研究进行更广泛的讨论，但这并不是本文的重点。

开源模型，专有聊天应用程序

重要的是要注意，虽然该模型本身是在宽松的 MIT 许可证下发布的，但 DeepSeek 运行他们自己的 AI chat application，以及随附的应用程序——这需要一个帐户。对于大多数人来说，这是他们使用 DeepSeek 的入口点，因此它是我们本文中提示注入工作的重点。毕竟——我们不是每天都能看到新的、高度商业化但又受限制的 AI 聊天产品……

提示和响应审查

鉴于 DeepSeek 是中国制造的，它自然对其将生成答案的内容有相当严格的限制。有报道称，DeepSeek-R1 正在审查与中国敏感话题相关的提示，这引发了对其可靠性和透明度的质疑——并激起了我的好奇心。例如，考虑以下内容：

DeepSeek-R1 模型由于内置的审查机制，避免讨论敏感问题。这是因为该模型是在中国开发的，在中国，对讨论某些敏感话题有严格的规定。当用户询问这些话题时，该模型通常会回复类似“抱歉，这超出了我目前的范围。我们来谈谈别的事情吧”这样的信息。

提示注入

我一直在尝试对这个新服务进行提示注入。从威胁建模的角度来看，这里的交互模式究竟是怎样的？我推测，他们不太可能直接在 LLM 模型内部训练出审查规则。这意味着，与许多商业 AI 产品类似，他们可能在对话的输入或输出阶段进行了过滤处理：

展示 DeepSeek 可能的组件交互的威胁模型

这是一种你在各种过滤器中经常看到的模式，无论是防火墙、内容过滤器还是审查器。这些系统旨在阻止或清理某些类型的内容，但它们通常依赖于预定义的规则和模式。将此几乎视为 Web 应用程序防火墙 (WAF)，你知道必须有某种方法来操纵输入和输出以绕过清理器。在 DeepSeek 的案例中，我假设审查机制不是内置在模型本身中，而是作为输入或输出的清理层应用的。这类似于 WAF 如何检查和过滤输入字段上的 Web 流量。然后，挑战就变成了找到一种与模型通信的方式，使其能够绕过这些过滤器。

字符代码

经过一些实验，我发现实现这一目标的最佳方法是使用字符代码的特定子集。字符代码，或 character codes，是字符集中字符的数字表示。例如，在 ASCII (American Standard Code for Information Interchange) 字符集中，字母 'A' 的字符代码是 65。通过使用这些数字代码，你可以以一种过滤器可能无法立即识别的方式来表示文本，这种过滤器旨在阻止特定的单词或短语。在本例中，我使用了 base16 (十六进制) 字符代码，它们是用空格分隔的。这意味着每个字符都用一个两位十六进制数字表示，并用空格分隔。

示例注入攻击

通过提示 DeepSeek 仅使用这些字符代码与我对话，我可以有效地绕过过滤器。

在我这边，我会将字符代码翻译回可读文本，反之亦然。这种方法使我能够与模型进行无限制的对话，绕过强加的限制。

进行这种来回映射的简单方法是使用 CyberChef 公式进行字符代码编码，你可以在其中选择适当的 base 和 delimiter。

经验教训

我已经暗示了与 WAF 过滤器和防火墙的相似之处。我们不应该仅仅检查显式类型的流量/内容，尤其是在有可能对过滤器任一侧的内容使用转换时——强制执行特定内容并禁止在您能够的情况下进行转换。通过采用更全面的内容过滤方法，我们可以更好地防范更广泛的威胁，并确保我们的安全措施即使在攻击者开发绕过它们的新方法时仍然有效。

这项实验突出了 AI 和机器学习模型的一个关键方面：强大的安全措施的重要性。随着 AI 继续发展并融入各个领域，理解和减轻潜在的漏洞变得至关重要。使用字符代码绕过过滤器的能力提醒我们，必须不断更新安全措施，并针对新的利用方法进行测试。

未来研究

展望未来，看看 AI 开发人员如何应对这类挑战将很有趣。他们会开发更复杂的过滤机制，还是会找到将审查机制直接嵌入到模型中的新方法？只有时间会证明。就目前而言，这为确保 AI 技术安全的持续努力提供了一个宝贵的教训。