LLM安全入门：为初学者破解大语言模型

基本建议：

• 不要相信 LLM 的输出，在使用之前尽量检查输出。这对于与输出交互的人以及依赖输出的系统或组件都适用。
• 从安全角度来看，应将 LLM 本身视为复杂应用程序和系统的一部分。
• 看看威胁，考虑操纵、提取和注入。
• 在测试 LLM 和 LLM 应用程序时，应用人类视角并使用自动化工具以及其他 AI 系统。
• 仔细考虑安全性和实用性之间的权衡。更安全的 LLM（例如，考虑其产生错误或有害输出的可能性）可能不太有用。在其他情况下，可能需要不那么“强大”但更“谨慎”的 LLM。
• 特别是在查看 LLM 申请时，不要忘记“常规”安全性，并确保像任何其他申请一样强化 LLM 申请。

LLM 安全框架
在进一步讨论之前，我想指出的是，OWASP 基金会和 MITRE 都发布了与 AI 和 LLM 相关的框架。OWASP LLM 应用程序 Top 10以及MITRE ATLAS™都是很好的起点。

虽然这些框架确实需要进一步开发，但它们对于理解需要考虑的事项确实非常有用。虽然 OWASP 专注于 LLM 应用程序，但 ATLAS™ 还包括与 LLM 狭窄范围之外的 AI 相关的“对手战术和技术”。

这两个框架也成功地构建了 LLM 安全领域的广阔领域。鉴于视角众多，找到好的类别非常困难，这两个框架都可以作为起点。

大语言模型
LLM大语言模型，例如 OpenAI 的 GPT-4，是一种经过训练的模型，可根据给定的单词（标记）序列预测以下可能的单词（标记）。本质上，LLM 只知道序列“天空是……”最有可能由“蓝色”完成。

为此，这些模型在庞大的语料库上进行训练，本质上表示给定先前序列的单词（标记）的概率。虽然这似乎是一个相当简单的目标，但以这种方式训练的模型在创建和“理解”语言时可能非常强大。使用微调和各种巧妙的训练方法，LLM 可以塑造成强大的工具，能够以惊人的能力执行许多与语言（或模式）相关的任务。

由于它们是以这种方式训练的，因此它们是概率性的，而不是确定性的。因此，我们不能“相信”模型的输出。即使一个模型在给定一个特定的提示模板的情况下，10 次中有 9 次产生了所需的输出，但它在剩余的时间里可能会做出完全不同的事情。

此外，我们必须记住，这些模型首先是语言模型，而不是知识模型。虽然它们能够根据训练数据产生事实输出，但它们也可以编造新的信息（幻觉）。

为了与这些模型交互，我们使用自然语言提示。无论是人类与模型还是机器交互，都是如此——输入始终是自然语言。

它们也是无状态的：每个提示都会导致一次独特的互动。为了进行持续的对话，我们需要将之前的对话或其部分内容附加到新的提示中。

提示和提示
提示是模型的输入，是与 LLM 交互的核心。它们也是我们攻击模型的主要方式。通常，我们不希望用户完全控制提示，因为这会让他们控制 LLM。自然，作为攻击者，我们希望控制输入到模型中的提示。

简而言之，提示是模型尝试完成的字符串。因此，LLM 的输出通常称为“完成”。模型有一个（最大）上下文窗口：模型可以处理的最大标记数。更大的上下文窗口意味着模型可以处理更长的提示以及产生更长的输出。

提示本身（长字符串）通常由多个部分组成。其中最有趣的两个常见部分是所谓的系统提示（通常由运行模型的人设置）和自定义指令（通常由用户设置）。

提示的这些部分通常被添加到用户提示的前面，以设置某些模型行为。例如，它们用于设置模型回复的样式或所需的输出。

虽然用户（通常）只能看到提示中的自己那部分，但发送给 LLM 的实际提示通常如下所示：

[SYSTEM PROMPT]
[CUSTOM INSTRUCTIONS]

User Prompt (i.e., "the prompt")

恶意/对抗性提示和中毒训练数据
攻击者的目标通常是让模型产生一些不想要的输出。例如，这可能是有害内容、有效载荷、系统后续步骤的一些错误输入，或者只是一些正在泄露的敏感信息。

为了实现这一目标，攻击者通常采用两种可能的手段：

1. 他们可以尝试向LLM发送恶意/对抗性提示，或者
2. 他们可以尝试毒害训练数据。

常见安全问题
有一系列与 LLM 相关的常见安全问题。在详细介绍这些问题之前，我想指出一个由Adversa提供的简单但有用的模型。
他们认为，基本上有三个类别：

1. 操纵（绕过预期的 AI 行为）
2. 窃取人工智能系统中的数据
3. 感染（破坏人工智能决策的质量；秘密控制人工智能系统）

与 LLM 有关的某些常见安全问题是：

• 模型错位→ 模型并非（总是）按照预期发挥作用。例如，错位的模型会产生不想要的、有害的输出。
• 直接和间接提示注入→ 攻击者使用精心设计的提示使 LLM 以非预期的方式运行。在间接提示注入期间，恶意/对抗性提示存储在模型或系统正在访问的某些内容中（例如网站）。
• 越狱→ 越狱通常是直接提示注入，试图绕过模型的限制。例如，攻击者可以利用越狱让模型产生有害输出，尽管已经采取了安全措施。
• 毒害训练数据和操纵内容→ 攻击者试图毒害训练数据以改变模型行为。同样，攻击者试图修改内容，例如添加虚假信息或偏见。
• 数据提取和信息泄露→攻击者试图从模型或模型本身中提取数据。关于信息泄露，我们还需要考虑，例如，训练数据、系统提示、知识库中的数据、有关其他用户及其会话的信息以及系统本身。
• 过度依赖→LLM的成果没有得到严格评估，人们过于依赖LLM。这可能会导致决策失误或法律问题。
• 隐私→用户的隐私受到威胁，例如，模型已经根据他们的数据进行了训练。

LLM 应用类型
由于 LLM 应用类型众多，很难选择一系列问题。因此，以下列表作为 LLM 本身的列表，绝对不是全面的。

• 恶意工具或插件/扩展→ LLM 使用恶意组件。
  * 插件与其敏感数据之间的交互​​→ 使用插件（或其他工具）时，这些插件与其可以访问的数据之间可能会存在不安全的交互。
• 不安全的输入和输出处理→模型的输入和输出未得到正确处理（例如，未经过净化）。例如，这可能导致恶意输出被用作输入的情况。
• 数据泄露→尤其是在 RAG 应用程序中，攻击者可能会尝试从知识库中提取数据。当然，攻击者也可能尝试从模型中提取训练数据以发现敏感信息。
• 持久性→攻击者试图在系统内放置恶意/对抗性提示（例如，系统提示或自定义指令）以获得对提示的持久控制。
• 提升访问权限→ LLM 可能拥有对系统其他部分的提升访问权限。通过获得对 LLM 的控制权，攻击者可以提升其权限。
• 传播感染→一个“受感染的”（提示）LLM 感染其他 LLM 或系统内的数据。
• 代码执行→ 许多 LLM 可以在其运行的系统上执行代码。控制 LLM 可能使攻击者获得 RCE。

LLM红队
在 LLM 安全领域，“红队”一词的含义与 IT/网络安全领域中的含义略有不同。在 LLM 安全领域中，该术语的使用范围非常广泛，通常指从安全角度测试的所有类型的 LLM。有时它甚至专门用于评估 LLM 及其一致性。

话虽如此，我认为红队从定义上来说就是从对抗的角度测试 LLM 和/或 LLM 应用程序。尤其是从 LLM 应用程序来看，红队可以理解为端到端的对抗模拟，可能包括蓝队的响应。根据范围，红队对 LLM 应用程序的攻击包括对训练数据、底层基础设施等的攻击。

方法范围从“简单”实验（例如基本的直接瞬时注入）到系统瞬时工程以及 LLM 与 LLM 的对决。当然，根据测试模型或考虑整个 LLM 应用，所采用的方法将有很大不同。

纵观红队LLM，一般来说，有三种基本方法：

1. 红队正在设计提示和人类可理解的对抗样本。本质上，红队正在对 LLM 进行实验。
2. 红队正在使用（自动化）提示工程、提示和示例数据库等。提示和示例不再一定是人类可以理解的。
3. 红队正在让专门的 LLM（或其他 AI 模型）与相关 LLM 进行对决。整个过程可能会实现自动化。

无论如何，红队训练的目的都是提高模型的安全性（和一致性）。在此过程中，我们通常还会尝试提高模型和/或应用程序的稳健性。特别是对于 LLM，这通常涉及协商安全性和实用性，如上所述。

当然，还有一系列工具（包括进攻性和防御性工具）正在开发中。例如，这些工具包括用于提示注入的模糊器（例如 LLMFuzzer）以及用于测试的对抗性提示数据库（例如Anthropic 的 Red Teaming Attempts或 Allen AI 的 RealToxicityPrompts）。

基本防御策略
可能的防御策略列表很长，并且很大程度上取决于模型和/或应用程序的特定架构。但是，有一些策略和措施应该始终考虑在内。

1、模型
考虑到模型（LLM），请确保进行仔细、透明的训练，并反映模型正在训练的数据。

这会产生各种影响，包括可能存在的偏见以及信息泄露的风险。如果您自己不训练（或微调）模型，请务必尽可能了解模型的训练方式。简而言之，确保模型的训练依据是什么，并尽可能了解潜在的偏见。

理想情况下，如果您自己训练模型，请进行对抗性训练并尝试通过训练使模型更能抵御攻击。

一旦你有了训练好的模型，一定要进行彻底的测试。这包括，首先，使用一系列对抗性提示来测试模型是否能抵御注入。最终，你要确保模型的行为符合预期，即使遇到极端情况也是如此。这包括创建（专门的）测试套件，你可以定期使用，尤其是在部署模型的修改版本时。也就是说，鉴于这些模型的非确定性，测试永远不会是 100% 的解决方案。

2、系统和应用
考虑整个系统或应用程序，确保在数据管道的每个步骤中执行数据验证和过滤。永远不要相信 LLM 的输入或输出。例如，如果 LLM 要生成 JSON，则第一道防线可能是在进入下一步之前验证是否已生成有效的 JSON。当然，这可以并且应该扩展到例如事实核查或过滤不需要的内容。

一般来说，对用户尽可能透明也是最佳做法。例如，告知用户已知的偏见，或者如果可能的话，告知用户对输出的置信度。

除了验证和过滤之外，您还可以并且应该应用防御性提示工程。例如，告诉模型应该以何种格式输出数据，并提供恶意示例以及处理它们的规则。在您自己的提示模板中嵌入用户提示也是一种很好的做法，使用自然语言限制提示中有多少内容由用户（或其他 LLM）控制。

最后，确保总体安全态势良好。考虑应用程序的所有元素，确保不会忘记其他更传统的安全方面。当然，这包括仔细考虑连接的服务和数据源。

作为进攻（和防御）工具
本文将 LLM 和 LLM 应用程序视为可能存在漏洞的事物，需要从安全角度进行考虑。

然而，LLM 也可以被威胁行为者和安全专家用作有价值的工具。一些用例可能包括：

• 使用 LLM（可以作为软件开发中的强大工具）进行工具和恶意软件开发。
• 使用 LLM 快速理解、分析和创建脚本、配置文件等。这在遇到不熟悉的系统时可能特别有用。
• 使用 LLM 分析样本和日志文件。
• 使用 LLM 自动化社会工程攻击（例如，创建网络钓鱼邮件）。
• 使用 LLM 来自动化部分测试过程（例如，使用代理系统）。
• 使用 LLM 协助（或自动化）撰写报告。