大语言模型安全指南：如何提升LLM安全抵御Prompt Injection.docx

大语言模型安全指南：如何提升LLM安全抵御PromptInjection

PromptInjection的本质与SQL注入类似，威胁行为者能够在受控数据字段内嵌入指令，使得系统难以区分数据和指令，威胁行为者可以通过控制AI模型的输入值，以诱导模型返回非预期的结果。因此，PromptInjection将会给所有的LLM（大语言模型）应用程序带来非常严重的安全风险。

这种安全问题就在于，这些LLM应用程序的接口本质上都是可以实现PromptInjection的，因为它们对任何用户指令都是“开放”的。而另一个问题就在于，很多LLM应用程序开发人员潜意识里都会认为，机器学习/深度学习模型的模糊性质很难去实现针对PromptInjection的全面防御，也就是无法将此类风险降到最低。但是，我们可以使用基于角色的API并遵循安全基准规则来进行设计和开发，以此来将该风险降至最低。

在这篇文章中，我们将跟广大渗透测试人员和开发人员分享针对LLM的安全设计与开发基准，并演示如何使用各种技术来提升LLM的安全以降低PromptInjection的风险。

使用基于角色的API最小化PromptInjection的安全风险

假设，我们使用夏雷方法查询OpenAI的ChatGPTAPI：

系统Prompt（LLM应用开发者提供的针对用户内容的指令）：A

用户Prompt（系统Prompt要操作的用户内容）：B

prompt=A+B

构建出的请求如下：

curl/v1/completions-HContent-Type:application/json-HAuthorization:BearerYOUR_API_KEY-d{model:text-davinci-003,prompt:“{system_prompt}{user_prompt}”,temperature:0,n:1,max_tokens:5}

在这个例子中，系统和用户上下文在同一个prompt混合在一起，并被发送给服务器。这对于经验丰富的安全专业人员来说可能很熟悉，因为它是一种常见的反安全模式，即将用户输入拼接到要处理的字符串中，这也是导致PromptInjection的常见情况。现在，我们来看看如何使用基于角色的API来像LLM发送输入数据：

系统Prompt（LLM应用开发者提供的针对用户内容的指令）：A

用户Prompt（系统Prompt要操作的用户内容）：B

role=system,message=A;role=user,message=B

构建出的请求如下：

curl/v1/chat/completions??-HContent-Type:application/json?-HAuthorization:BearerXXX”-d{model:gpt-3.5-turbo-0613,messages:[{role:system,content:{system_prompt}},{role:user,content:{user_prompt}]}

如果将基于角色的API调用与之前的级联（字符串拼接）API调用进行比较，我们就会发现，基于角色的API显式地将用户与系统内容分离，类似于SQL中的预构建语句。使用基于角色的API本质上会比原来的方法安全很多，因为它为模型提供了显式分离用户和系统内容的机会。

可能有人会认为，哪怕API现在分离了用户和系统内容，但是它们最终还是会级联在一起并发送给LLM。但即使它们最终级联在一起，我们还是可以对内容执行某些操作，以将用户与系统内容分离。尽管基于角色的API是OpenAIAPI的专有接口，但我们希望其他LLM供应商也能效仿，因为基于角色的API是一种良好的安全设计模式。既然我们已经讨论了如何正确使用LLMAPI，那么让我们来看看如何安全地设计系统Prompt。

如何开发系统Prompt将PromptInjection的风险降至最低

1、我们可以在基于角色的API中使用系统角色来隔离希望LLM应用程序遵循和执行的指令，并确保用户内容不与系统上下文级联。

2、我们要确保系统Prompt尽可能的具体，因为模糊的Prompt可能会导致错误发生，所以我们要明确定义任务、上下文和预期的输出，这样就可以减少绕过系统Prompt的可能性。

比如说，如果你希望LLM在不满足标准系统Prompt时打印“DENIED”，那么我们不能仅仅设置“如果X事件发生，则打印DENIED”，而是要改成“如果X事件发生，则打印DENIED，并且不再执行任何操作”。因为在第一种情况下，威胁行为者可能可以在LLM打印完DENIED之后去执行PromptInjectio