全面解析LLM安全风险 | 3万字长文翻译OWASP关于大语言模型的Top 10安全风险

最新推荐文章于 2024-08-12 20:49:28 发布

lurenjia404

最新推荐文章于 2024-08-12 20:49:28 发布

阅读量875

点赞数 11

分类专栏：网安笔记文章标签：安全语言模型 web安全

本文链接：https://blog.csdn.net/galaxylove/article/details/140486890

版权

网安笔记专栏收录该内容

51 篇文章 4 订阅

订阅专栏

OWASP Top 10 for LLM Applications

全文摘要
《OWASP Top 10 for LLM Applications》是OWASP对大语言模型LLM的10类最常见的安全漏洞分析与缓解（1.1版本，发布于2023年10月16日），介绍了针对大型语言模型（LLM）应用程序的安全问题，并提出了一个名为“OWASP Top 10 for LLM Applications”的列表，旨在为开发人员、数据科学家和安全专家提供实用的安全指导，帮助他们设计和构建更安全的应用程序和插件。
该列表由来自不同领域的近500名专家共同创建，经过多次投票和审查后确定了十个最严重的漏洞。这些漏洞包括：注入攻击、不安全的输出处理、训练数据中毒、拒绝服务攻击、供应链漏洞、敏感信息泄露、不安全的插件设计、过度授权、过度依赖等。
该列表不仅提供了对常见应用安全原则的理解，还探讨了传统漏洞在使用LLM时可能带来的新风险或被利用的新方式。每个漏洞包括了漏洞说明、示例漏洞、缓解方式以及示例攻击场景。笔者还以译者注的方式解释了不好理解的安全描述。

引言

列表的由来

大型语言模型（LLM）在2022年底大规模市场预训练聊天机器人发布后引起了极大的兴趣。渴望利用LLM潜力的企业正在迅速将它们整合到自己的运营和面向客户的服务中。然而，开发团队采用LLM的速度超过了全面安全协议的建立，使许多应用程序容易受到高风险问题的攻击。

对解决LLM中这些安全问题统一资源的需求是显而易见的。对LLM相关特定风险不熟悉的开发人员只能找到零散的资源，而OWASP的使命似乎是帮助更安全地采用这项技术的完美契合。

主要受众

我们的主要受众是负责设计和构建利用LLM技术的应用和插件的开发人员、数据科学家和安全专家。我们的目标是提供实用的、可操作的和简洁的安全指导，帮助这些专业人士在LLM应用安全的复杂和不断变化的领域中导航。

制定列表过程

创建OWASP Top 10 for LLM Applications列表是一项重大任务，它建立在近500名专家的集体专业知识基础之上，其中包括125多名活跃贡献者。我们的贡献者来自多样的背景，包括AI公司、安全公司、独立软件供应商（ISVs）、云超级扩展商、硬件供应商和学术界。

我们进行了为期一个月的头脑风暴，提出了潜在的漏洞，团队成员撰写了43种不同的威胁。通过多轮投票，我们将这些建议精炼为一个简洁的列表，列出了十个最严重的漏洞。专门的小组对每个漏洞进行了仔细审查，并通过公开审查对其进行了审查，确保了最终列表的全面性和可操作性。

这些漏洞中的每一个，连同示例、预防提示、攻击场景和参考资料，都由专门的小组进一步审查和精炼，并经过了公众审查，确保了最终列表的全面性和可操作性。

与其它OWASP Top 10列表的关系

尽管我们的列表与其他OWASP Top 10列表中发现的漏洞类型有共同点，我们并不只是重申这些漏洞。相反，我们深入探讨了这些漏洞在利用LLM的应用中遇到时的独特含义。

我们的目标是弥合一般应用安全原则与LLM带来的特定挑战之间的差距。该小组的目标包括探索传统漏洞可能如何在LLM中构成不同的风险或以新的方式被利用，以及开发人员必须如何调整传统的补救策略以适应使用LLM的应用。

OWASP Top 10 LLM应用

Top 10

LLM01: 提示注入通过巧妙的输入操纵大型语言模型（LLM），导致LLM采取意外行动。直接注入覆盖系统提示，而间接注入则操纵来自外部来源的输入。

LLM02: 不安全的输出处理当LLM输出被未经审查地接受时，就会发生这种漏洞，暴露了后端系统。滥用可能导致XSS、CSRF、SSRF、权限提升或远程代码执行等严重后果。

LLM03: 训练数据投毒当LLM训练数据被篡改时，就会发生这种情况，引入了可能损害安全性、有效性或道德行为的漏洞或偏见。来源包括Common Crawl、WebText、OpenWebText和书籍。

LLM04: 模型拒绝服务攻击者对LLM进行资源密集型操作，导致服务降级或高成本。由于LLM的资源密集性质和用户输入的不可预测性，这种漏洞被放大。

LLM05: 供应链漏洞LLM应用的生命周期可能因脆弱的组件或服务而受到破坏，导致安全攻击。使用第三方数据集、预训练模型和插件可能会增加漏洞。

LLM06: 敏感信息泄露LLM可能无意中在其响应中泄露机密数据，导致未经授权的数据访问、隐私侵犯和安全漏洞。实施数据清理和严格的用户政策对于缓解这一点至关重要。

LLM07: 不安全的插件设计LLM插件可能有不安全的输入和不足的访问控制。缺乏应用控制使它们更容易被利用，可能导致远程代码执行等后果。

LLM08: 过度代理基于LLM的系统可能会采取导致意外后果的行动。问题源于过度的功能、权限或自主权授予LLM系统。

LLM09: 过度依赖系统或人员过度依赖LLM而没有监督可能会因LLM生成的错误或不当内容而面临误导信息、沟通不畅、法律问题和安全漏洞。

LLM10: 模型盗窃涉及未经授权的访问、复制或泄露专有LLM模型。影响包括经济损失、竞争优势受损，以及可能接触到敏感信息。

LLM应用数据流

下图展示了一个假设的大型语言模型应用的高层架构。图中叠加的部分突出显示了风险区域，说明了OWASP Top 10 for LLM Applications条目如何与应用流程相交。该图可以用作视觉指南，帮助理解大型语言模型安全风险如何影响整个应用生态系统。

LLM01：提示注入

描述

提示注入漏洞发生在攻击者通过精心设计的输入操纵大型语言模型（LLM），导致LLM无意中执行攻击者的意图。这可以通过直接“越狱”系统提示或间接通过操纵外部输入来实现，可能导致数据泄露、社会工程学等问题。

直接提示注入，也称为“越狱”，发生在恶意用户覆盖或揭露底层系统提示时。这可能允许攻击者通过与LLM交互的不安全功能和数据存储来利用后端系统。
间接提示注入发生在LLM接受来自外部来源的输入时，这些来源可以被攻击者控制，例如网站或文件。攻击者可能在外部内容中嵌入提示注入，劫持对话上下文。这将导致LLM像“困惑的副官”一样行动，允许攻击者操纵用户或LLM可以访问的其他系统。此外，间接提示注入不需要对人类可见/可读，只要文本被LLM解析即可。

成功的提示注入攻击的结果可能大相径庭——从索取敏感信息到在正常操作的伪装下影响关键决策过程。

在高级攻击中，LLM可能被操纵以模仿有害人物或与用户设置中的插件交互。这可能导致泄露敏感数据、未经授权的插件使用或社会工程学。在这些情况下，受损的LLM有效地作为攻击者的代理，进一步实现其目标，而不触发常规的安全措施或提醒最终用户入侵。在这些情况下，受损的LLM实际上作为攻击者的代理，进一步实现其目标，而不触发常规的安全措施或提醒最终用户入侵。

常见漏洞示例

恶意用户对LLM进行直接提示注入，指示它忽略应用程序创建者的系统提示，而是执行一个提示，返回私有、危险或不希望的信息。
用户使用LLM总结包含间接提示注入的网页。然后，LLM会从用户那里索取敏感信息，并通过JavaScript或Markdown进行数据泄露。
恶意用户上传包含间接提示注入的简历。该文件包含一个提示注入指令，指示LLM告知用户该文档非常优秀，例如，非常适合某个职位。内部用户通过LLM运行该文档以总结文档。LLM的输出返回信息，表明这是一个优秀的文档。
用户启用与电子商务网站链接的插件。一个恶意指令嵌入在访问的网站上，导致未经授权的购买。
一个恶意指令和内容嵌入在访问的网站上，利用其他插件欺骗用户。

预防和缓解策略

提示注入漏洞是由于LLM的性质，它们不将指令和外部数据相互隔离。由于LLM使用自然语言，它们将这两种形式的输入视为用户提供的。因此，LLM内部没有万无一失的预防措施，但以下措施可以减轻提示注入的影响：

对LLM访问后端系统的权限实施特权控制。为LLM提供自己的API令牌，用于可扩展功能，如插件、数据访问和功能级权限。遵循最小权限原则，仅限LLM执行其预期操作所必需的最低级别访问。
在执行特权操作时，如发送或删除电子邮件，要求应用程序先获得用户批准。这减少了间接提示注入导致未经授权的用户操作的机会。
将外部内容与用户提示分开。分离并标记未受信任内容的使用，以限制它们对用户提示的影响。例如，使用ChatML进行OpenAI API调用，以指示LLM提示输入的来源。
在LLM、外部来源和可扩展功能（例如插件或下游功能）之间建立信任边界。将LLM视为不受信任的用户，并保持最终用户对决策过程的控制。然而，一个受损的LLM仍可能作为应用程序API和用户之间的中介（中间人），因为它可能在呈现给用户之前隐藏或操纵信息。向用户视觉上突出显示可能不可信的响应。
定期手动监控LLM输入和输出，以检查是否符合预期。虽然这不是缓解措施，但可以提供检测弱点和解决问题所需的数据。

示例攻击场景

攻击者向基于LLM的支持聊天机器人提供直接提示注入。注入包含“忘记所有先前指令”和新指令，查询私有数据存储并利用包漏洞以及后端函数中缺少输出验证来发送电子邮件。这导致远程代码执行，获得未经授权的访问和权限提升。
攻击者在网页中嵌入间接提示注入，指示LLM忽略用户先前的指令，并使用LLM插件删除用户的电子邮件。当用户使用LLM总结这个网页时，LLM插件删除了用户的电子邮件。
用户使用LLM总结包含文本的网页，该文本指示模型忽略用户先前的指令，并插入一个链接到包含对话摘要的URL的图像。LLM输出遵从，导致用户的浏览器泄露私人对话。
恶意用户上传包含间接提示注入的简历。该文件包含一个提示注入指令，指示LLM告知用户该文档非常优秀，例如，非常适合某个职位。内部用户通过LLM运行该文档以总结文档。LLM的输出返回信息，表明这是一个优秀的文档。
攻击者向依赖系统提示的专有模型发送消息，要求模型忽略其先前的指令，而是重复其系统提示。模型输出专有提示，攻击者能够将这些指令用于其他地方，或构建更微妙的攻击。

LLM02: 不安全的输出处理

描述

不安全的输出处理是指在大型语言模型（LLM）生成的内容传递给下游组件和系统之前，对这些输出进行的不足的验证、清洗和处理。由于LLM生成的内容可以由提示输入控制，这种行为类似于向用户间接提供额外功能的访问权限。

不安全的输出处理与过度依赖的区别在于，它关注的是在内容传递给下游之前对LLM生成的输出进行处理，而过度依赖则关注更广泛的准确性及LLM输出的适当性问题。

成功利用不安全的输出处理漏洞可能导致在Web浏览器中出现跨站脚本（XSS）和跨站请求伪造（CSRF），以及在后端系统中出现服务器端请求伪造（SSRF）、权限提升或远程代码执行。

以下条件可能会增加这种漏洞的影响：

应用程序授予LLM的权限超出了为最终用户设计的权限，这可能导致权限提升或远程代码执行。
应用程序容易受到间接提示注入攻击，这可能允许攻击者获得对目标用户环境的特权访问。
第三方插件没有充分验证输入。

常见漏洞示例

LLM输出直接输入到系统shell或类似功能（如exec或eval），导致远程代码执行。
JavaScript或Markdown由LLM生成并返回给用户。然后由浏览器解释这些代码，导致XSS。

预防和缓解策略

将模型视作普通用户，采用零信任原则，对模型输出到后端的响应进行严格验证。
遵循OWASP ASVS（应用程序安全验证标准）指南，以确保有效的输入验证和清洗。
将模型生成的输出转换为安全格式后返回给用户，以防止JavaScript或Markdown代码被恶意执行。OWASP ASVS提供了关于如何进行输出编码的详细指南。

示例攻击场景

应用程序使用了一个LLM插件来为聊天机器人提供回答。这个插件不仅用于普通用户，还为另一个拥有更多权限的LLM提供管理功能。如果通用LLM在将回答传递给插件之前没有进行适当的检查和验证，那么插件可能会因为需要进行维护而停止工作。这是因为没有进行输出验证，可能导致插件在不应该停止的时候停止了工作。
用户使用由LLM驱动的网站摘要工具来生成一篇文章的简洁摘要。网站包括一个提示注入，指示LLM捕获来自网站或用户对话的敏感内容。然后LLM可以编码这些敏感数据，并将其发送到攻击者控制的服务器，而没有进行任何输出验证或过滤。
LLM允许用户通过类似聊天的功能为后端数据库构造SQL查询。用户请求一个删除所有数据库表的查询。如果从LLM生成的查询未经审查，那么所有数据库表都将被删除。
Web应用程序使用LLM根据用户文本提示生成内容，而没有进行输出清洗。攻击者可以提交一个精心构造的提示，导致LLM返回一个未经清洗的JavaScript有效载荷，当在受害者的浏览器上渲染时，导致XSS。对提示的不足验证使这种攻击成为可能。

LLM03: 训练数据中毒

描述

任何机器学习方法的起点都是训练数据，即“原始文本”。为了能够胜任（例如拥有语言学和世界知识），这些文本应涵盖广泛的领域、体裁和语言。大型语言模型使用深度神经网络根据从训练数据中学到的模式生成输出。

训练数据中毒指的是对预训练数据或在微调或嵌入过程中涉及的数据进行操纵，以引入漏洞、后门或偏见，这些都可能损害模型的安全性、有效性或道德行为。被污染的信息可能会被用户获取，或者造成其他风险，如性能下降、下游软件被利用和声誉损害。即使用户对有问题的AI输出持怀疑态度，风险仍然存在，包括模型能力受损和品牌声誉潜在的损害。

预训练数据是指根据任务或数据集对模型进行训练的过程。
微调是使用经过训练的现有模型，通过在受控数据集上训练该模型来适应更聚焦的主题或更具体的目标。这个数据集通常包含输入示例及其期望输出。
嵌入过程是指将分类数据（通常是文本）转换为数值表示的过程，以便用于训练语言模型。嵌入过程涉及将来自文本文档中的单词或短语表示为连续向量空间中的矢量。通常通过将文本文档馈送到大型文本文档集合上进行训练的神经网络来生成这些矢量。

译者注：嵌入过程是自然语言处理（NLP）中的一个关键步骤，它允许计算机以数学方式表示和处理语言。这种方法使得模型能够捕捉到单词之间的细微差别和关系，例如，“国王”和“女王”在语义上是相似的，这种相似性可以在它们的嵌入向量中体现出来。嵌入通常通过深度学习模型在大量文本数据上进行训练得到。这些模型学习到的向量表示可以用于各种下游任务，如文本分类、情感分析或机器翻译。嵌入的质量直接影响到这些任务的性能，因此，生成高质量嵌入是构建有效NLP系统的基础。

训练数据中毒被认为是一种完整性攻击，因为它影响模型根据训练数据输出正确预测的能力。显然，外部数据源带来的风险更高，因为模型创建者无法控制数据或对内容不含有偏见、虚假信息或不适当内容有高度的信心。

常见漏洞示例

恶意行为者或竞争品牌故意创建不准确或恶意的文档，这些文档被用于模型的预训练、微调和嵌入过程。考虑Split-View数据投毒和Frontrunning数据投毒攻击向量进行说明。

a. 受害者模型使用伪造的信息进行训练，这些信息反映在其生成人工智能提示的输出中。* 译者注：

Split-View数据投毒：攻击者可能会在模型的训练数据中注入带有偏见的数据，导致模型对某些输入产生特定的、可能是有害的响应。
Frontrunning数据投毒：攻击者可能会预测模型将要处理的数据，并提前在这些数据中注入错误或误导性信息，影响模型的决策过程。*

恶意行为者能够直接向模型的训练过程中注入伪造、偏见或有害内容，这些内容随后在后续输出中反映出来。
用户无意中将敏感或专有数据注入到模型的训练过程中，这些数据随后在后续输出中反映出来。
模型使用未经验证其来源或内容的数据进行训练，如果数据被污染或不正确，可能会导致错误的结果。
不受限制的基础设施访问或不充分的沙箱化可能允许模型获取不安全的训练数据，导致偏见或有害的输出。这种例子也存在于任何训练阶段的例子中。

a. 在本例中，模型用户输入的内容可能会反映到另一个用户的输出中（导致违规），或者使用 LLM 的用户可能会收到根据数据类型与模型用例相比不准确、不相关或有害的输出（通常通过模型卡进行反映）。

无论开发者、客户还是LLM的一般消费者，重要的是要理解这种漏洞可能如何反映在与非专有LLM交互时的风险，以理解基于其训练程序的模型输出的合法性。同样，LLM的开发者可能面临对内部或第三方用于微调和嵌入的数据的直接和间接攻击的风险，这反过来为所有消费者带来风险。

预防和缓解策略

验证训练数据的供应链，特别是当数据来源于外部时，同时通过“ML-BOM”（机器学习物料清单）方法维护证明以及验证模型卡。
验证预训练、微调和嵌入阶段获取的目标数据源和数据的正确合法性。
验证LLM的使用案例以及它将集成的应用程序。通过不同的训练数据或微调为不同的使用案例创建不同的模型，以创建更细粒度和准确的生成式AI输出，根据其定义的使用案例。
确保通过网络控制有足够的沙箱环境，以防止模型抓取意外的数据源，这可能会阻碍机器学习输出。
对特定训练数据或数据源类别使用严格的审查或输入过滤器，以控制虚假数据的量。数据清洗，使用技术如统计异常值检测和异常检测方法来检测和移除可能被输入到微调过程中的对抗性数据。
采用对抗性鲁棒性技术，如联邦学习和约束，以最小化训练数据的异常值或对抗性训练的影响，以抵御最坏情况下的训练数据扰动。

a. “MLSecOps”方法可能是通过自动中毒技术将对抗鲁棒性纳入训练生命周期。

b. 一个这样的仓库的例子是Autopoison 测试，包括内容注入攻击（尝试在模型响应中推广品牌名称）和拒绝服务攻击（总是使模型拒绝响应），这可以使用这种方法来完成。

*译者注：这段话描述的是一个名为Autopoison的测试仓库，它用于模拟和测试大型语言模型（LLM）在面对特定类型的攻击时的反应和行为。Autopoison测试仓库包含两种攻击向量的示例：

内容注入攻击（Content Injection Attacks）：这种攻击的目的是在模型的输出中植入特定的内容，例如尝试在模型的响应中推广某个品牌名称。攻击者通过精心设计的输入来操纵模型，使其在输出中包含攻击者希望推广的信息。
拒绝服务攻击（Refusal Attacks）：在这种攻击中，攻击者试图使模型在接收到特定的输入时拒绝响应或提供服务。例如，攻击者可能设计一种输入，使得模型在处理该输入时总是返回错误或拒绝执行任何操作。Autopoison测试仓库的目的是为了帮助开发者和安全研究人员理解模型在面对这些攻击时的脆弱性，并采取相应的防御措施来增强模型的安全性。通过在模型的训练或测试阶段使用这些攻击向量，可以评估模型对这些攻击的抵抗力，并据此改进模型的设计，以减少被攻击者利用的风险。*

通过在训练阶段测量损失并分析训练有素的模型，来检测训练数据中毒攻击的迹象，通过分析特定测试输入上的模型行为。

a. 监控响应数量超过阈值并发出警报。

b. 使用人工循环来审查响应并进行审计。

c. 实施专门的 LLM 以基准对意外后果，并使用强化学习技术训练其他 LLM。

d. 在LLM生命周期的测试阶段执行基于LLM的红队演练或LLM漏洞扫描。

示例攻击场景

LLM生成的AI提示输出可能会误导应用程序的用户，导致偏见意见、追随者，甚至更糟，仇恨犯罪等。
如果训练数据没有正确过滤和/或清洗，恶意用户可能会尝试影响并注入有毒数据到模型中，以便模型适应偏见和虚假数据。
恶意行为者或竞争者故意创建不准确或恶意的文档，针对模型的训练数据，而模型同时正在根据输入进行训练。受害者模型使用这些伪造的信息进行训练，这些信息反映在向消费者提供的生成AI提示的输出中。
如果在训练模型时使用了客户输入的数据，而没有进行足够的清洗和过滤，提示注入漏洞可能成为这种漏洞的攻击向量。即，如果恶意或伪造的数据作为提示注入技术的一部分输入到模型中，这可能本质上被描绘到模型数据中。

译者注：如果在训练过程中没有对输入数据进行充分的验证和清洗，那么模型可能会被训练成包含恶意行为或错误信息的模型。这不仅影响模型的准确性和可靠性，还可能使模型成为攻击者利用的工具，用于进一步的恶意活动，如传播虚假信息或执行其他恶意操作。因此，确保在训练模型时对数据进行严格的清洗和过滤是非常重要的，以防止这种安全漏洞的出现。

LLM04: 模型拒绝服务攻击

描述

攻击者通过与大型语言模型（LLM）的交互，消耗异常高的资源量，导致服务质量和资源成本下降，不仅影响他们自己，也可能影响其他用户。此外，一个新兴的主要安全问题是攻击者可能干扰或操纵LLM的上下文窗口。随着LLM在各种应用程序中的使用日益增加，它们对资源的密集使用，用户输入的不可预测性，以及开发者普遍对这种漏洞缺乏认识，这个问题变得越来越严重。在LLM中，上下文窗口代表模型能够处理的最大文本长度，包括输入和输出。这是LLM的一个关键特性，因为它决定了模型能够理解的语言模式的复杂性和它一次能够处理的文本大小。上下文窗口的大小由模型的架构定义，并且不同模型之间可能有所不同。

常见漏洞示例

攻击者通过设计查询，使得LLM（大型语言模型）在处理任务时产生大量排队的任务，例如利用LangChain或AutoGPT等工具。这种行为可能导致LLM的资源消耗异常增加，从而影响服务质量和增加运营成本。
发送异常消耗资源的查询，使用不寻常的正字法或序列。

译者注：攻击者通过发送特别设计的查询来消耗大量的计算资源。这些查询可能包含不常见的拼写或字符序列，使得LLM（大型语言模型）在处理这些查询时需要进行复杂的计算，从而导致资源的大量消耗。例如，攻击者可能会构造一些特别长或复杂的查询，这些查询要求LLM进行大量的文本处理、搜索或分析工作，从而使得LLM需要消耗更多的CPU或内存资源。这种攻击方式可以导致LLM的性能下降，影响到其他用户的使用体验，甚至可能导致服务的中断。在安全领域，这种攻击被称作拒绝服务攻击（DoS），攻击者通过消耗目标系统的资源，使其无法正常为合法用户提供服务。对于LLM来说，这种攻击可能会导致模型无法及时响应用户的请求，或者在极端情况下，导致整个系统崩溃。

持续输入溢出：攻击者向LLM发送一个超过其上下文窗口的输入流，导致模型消耗过多的计算资源。
重复长输入：攻击者反复向LLM发送超过上下文窗口的长输入。
递归上下文扩展：攻击者构造一个触发递归上下文扩展的输入，迫使LLM反复扩展和处理上下文窗口。
变长输入洪泛：攻击者向LLM发送大量精心设计的变长输入，每个输入都恰好达到上下文窗口的限制。这种技术旨在利用处理变长输入的任何效率低下，给LLM带来压力，可能导致它变得无响应。

译者注：这段话描述了一种针对大型语言模型（LLM）的攻击方法，称为“变长输入洪泛”（Variable-length input flood）。在这种攻击中，攻击者精心设计了一系列的输入数据，这些数据的长度变化不定，但每个输入都恰好达到模型处理能力的上限，即上下文窗口的限制。上下文窗口是LLM处理输入和输出时能够处理的最大文本长度。当输入数据的长度接近或达到这个限制时，模型需要进行更复杂的处理来理解这些输入，并生成相应的输出。攻击者利用这一点，通过发送大量精心设计的变长输入，试图使模型在处理这些输入时消耗大量的计算资源，从而导致性能下降。这种攻击技术的目的是利用模型在处理变长输入时可能存在的效率低下问题。由于每个输入都恰好达到上下文窗口的限制，模型需要投入更多的计算资源来处理这些输入，这可能导致模型的响应速度变慢，甚至在极端情况下，导致模型无法响应任何新的请求，即“无响应”状态。这种攻击对模型的性能和可用性构成了威胁，因为它可能导致服务中断或拒绝服务（DoS），影响模型为合法用户提供服务的能力。因此，了解和防范这种攻击对于确保大型语言模型的安全和稳定运行至关重要。

预防和缓解策略

实施输入验证和清洗，确保用户输入遵守定义的限制并过滤掉任何恶意内容。
对每个请求或步骤限制资源使用，使得涉及复杂部分的请求执行得更慢。
实施API速率限制，限制单个用户或IP地址在特定时间框架内可以发出的请求数量。
限制系统对LLM响应做出反应时排队的动作数量和总动作数量。
持续监控LLM的资源使用情况，以识别异常峰值或可能表明DOS攻击的模式。
根据LLM的上下文窗口设置严格的输入限制，以防止过载和资源耗尽。
提高开发者对LLM中潜在DOS漏洞的认识，并提供安全LLM实施的指南。

示例攻击场景

攻击者反复向托管模型发送多个困难且成本高昂的请求，导致其他用户的服务质量下降和托管者资源账单增加。
在使用LLM驱动的工具收集信息以响应一个良性查询时，遇到了网页上的文本。这导致工具进行了更多的网页请求，消耗了大量的资源。
攻击者持续向LLM发送超过其上下文窗口的输入。攻击者可能使用自动化脚本或工具发送大量的输入，压垮LLM的处理能力。结果，LLM消耗了过多的计算资源，导致系统显著减慢或完全无响应。
攻击者向LLM发送一系列顺序输入，每个输入都设计为刚好低于上下文窗口的限制。通过反复提交这些输入，攻击者旨在耗尽可用的上下文窗口容量。随着LLM努力在上下文窗口内处理每个输入，系统资源变得紧张，可能导致性能下降或服务拒绝。
攻击者利用LLM的递归机制触发上下文扩展。通过构造利用LLM递归行为的输入，攻击者迫使模型反复扩展和处理上下文窗口，消耗大量的计算资源。这种攻击给系统带来压力，可能导致LLM无响应或崩溃。
攻击者向LLM发送大量精心设计的变长输入，这些输入都接近或达到上下文窗口的限制。通过用不同长度的输入淹没LLM，攻击者旨在利用处理变长输入的任何效率低下。这种输入的洪流给LLM的资源带来过大的负担，可能导致性能下降，妨碍系统响应合法请求。
虽然拒绝服务攻击通常旨在耗尽系统资源，但它们也可以利用系统行为的其他方面，例如 API 限制。例如，在最近的 Sourcegraph 安全事件中，恶意行为者使用了泄露的管理员访问令牌来更改 API 速率限制，从而可能导致由于允许异常数量的请求数量而导致的服务中断。

译者注：通常，API速率限制是系统用来防止滥用和保护自身免受过度请求影响的一种机制。例如，一个API可能限制用户在一定时间内只能发送一定数量的请求。然而，当攻击者通过某种方式获取了管理员权限，他们可以绕过这些限制，发送大量请求，导致系统过载，无法正常处理合法用户的请求。在Sourcegraph安全事件中，攻击者使用泄露的管理员访问令牌来更改API速率限制，这使得他们能够发送异常数量的请求，从而可能导致服务中断。这种攻击方式表明，即使系统有速率限制，但如果攻击者能够绕过这些限制，他们仍然可以对系统造成严重的影响。

LLM05: 供应链漏洞

描述

LLM的供应链可能存在漏洞，影响训练数据、机器学习模型和部署平台的完整性。这些漏洞可能导致偏见结果、安全漏洞甚至整个系统的失败。传统上，漏洞集中在软件组件上，但机器学习扩展了这一范围，包括第三方提供的预训练模型和训练数据，这些数据容易受到篡改和投毒攻击。

最后，LLM插件扩展可能带来它们自己的漏洞。这些在LLM07 - 不安全的插件设计中有描述，涵盖了编写LLM插件并提供了评估第三方插件的有用信息。

常见的漏洞示例

传统的第三方软件包漏洞，包括过时或弃用的组件；
使用易受攻击的预训练模型进行微调；
使用被投毒的众包数据进行训练；
使用不再维护的过时或弃用的模型，导致安全问题；
模型运营商的条款和条件（T&Cs）和数据隐私政策不明确，可能导致应用程序的敏感数据被用于模型训练，随后可能暴露敏感信息。这也可能适用于使用模型供应商的版权材料的风险。

预防和缓解策略

仔细审查数据源和供应商，包括条款和条件以及隐私政策，只使用可信赖的供应商。确保有足够的、独立审计的安全措施，并且模型运营商的政策与您的数据保护政策一致，即您的数据不会用于训练他们的模型；同样，寻求保证和法律措施，以防止使用模型维护者的受版权保护材料。
只使用可信赖的插件，并确保它们已经过针对您的应用要求的测试。LLM-Insecure Plugin Design提供了关于LLM方面的不安全插件设计的信息，您应该测试以减轻使用第三方插件的风险。
理解并应用OWASP Top 10中A06:2021-Vulnerable and Outdated Components中的缓解措施。这包括漏洞扫描、管理和修补组件。对于访问敏感数据的开发环境，也应在这些环境中应用这些控制措施。
维护一个使用软件物料清单（SBOM）的组件清单，以确保您有一个最新、准确且经过签名的清单，防止对部署的包进行篡改。SBOM可以用来快速检测和警告新的、零日漏洞。
在撰写本文时，SBOM不涵盖模型、其工件和数据集。如果您的LLM应用使用自己的模型，您应该使用MLOps最佳实践和提供安全模型仓库的平台，包括数据、模型和实验跟踪。
在使用外部模型和供应商时，您也应该使用模型和代码签名。
对提供的模型和数据进行异常检测和对抗性鲁棒性测试，可以帮助检测篡改和中毒，理想情况下，这应该是MLOps流程的一部分；然而，这些是新兴技术，可能更容易作为红队演练的一部分实施。
实施足够的监控，以覆盖组件和环境漏洞扫描、使用未经授权的插件和过时组件，包括模型及其工件。
实施修补政策，以减轻易受攻击或过时的组件。确保应用程序依赖于维护版本的API和底层模型。
定期审查和审计供应商的安全性和访问权限，确保在他们的安全态势或条款和条件没有发生变化。

示例攻击场景

攻击者利用一个易受攻击的Python库来破坏系统。这在第一次OpenAI数据泄露事件中发生。
攻击者提供一个LLM插件来搜索航班，生成虚假链接，导致用户被骗。
攻击者利用PyPi包注册表欺骗模型开发者下载一个被篡改的包，并在模型开发环境中泄露数据或提升权限。这是一个实际的攻击。
攻击者污染一个专门用于经济分析和社会研究的公开可用的预训练模型，创建一个后门，生成错误信息和假新闻。他们将其部署在模型市场（例如Hugging Face）上，供受害者使用。
攻击者污染公开可用的数据集，以实现在微调模型时创建后门。后门微妙地在不同时长中偏袒某些公司。
一个供应商（外包开发者、托管公司等）的员工窃取数据、模型或代码，窃取知识产权。

LLM06: 敏感信息泄露

LLM应用有可能通过其输出透露敏感信息、专有算法或其他机密细节。这可能导致未经授权访问敏感数据、知识产权侵犯、隐私泄露和其他安全漏洞。对于LLM应用的消费者来说，了解如何安全地与LLM互动以及识别与无意中输入敏感数据相关的风险非常重要。

为了减轻这种风险，LLM应用应执行充分的数据清洗，以防止用户数据进入训练模型数据。LLM应用的所有者还应有适当的使用条款政策，使消费者了解其数据如何被处理，并能够选择退出将其数据包含在训练模型中。

消费者与LLM应用的交互形成了一个双向信任边界，在这个边界中，我们不能固有地信任客户端到LLM的输入或LLM到客户端的输出。重要的是要注意，这种漏洞假设某些前提条件不在考虑范围内，例如威胁建模练习、基础设施的安全性和足够的沙箱化。在系统提示中对LLM应返回的数据类型添加限制可以提供一些缓解措施，但LLM的不可预测性意味着这些限制可能不会总是被遵守，并且可能通过提示注入或其他向量被绕过。

常见漏洞示例

在LLM的响应中不完整或不适当过滤敏感信息。
在LLM的训练过程中过度拟合或记忆敏感数据。
由于LLM的误解、缺乏数据清洗方法或错误，导致机密信息的无意泄露。

预防和缓解策略

集成充分的数据清洗和清洗技术，以防止用户数据进入训练模型数据。
实施强大的输入验证和清洗方法，以识别和过滤潜在的恶意输入，防止模型被污染。
在使用数据对模型进行增强和微调时：（比如在部署之前或部署期间向模型输入数据）

a. 微调数据中任何被认为敏感的信息都有可能被用户获知。因此，应遵循最小权限原则，不要在模型上训练那些只有最高权限用户才能访问且可能被展示给权限较低用户的信息。

b. 应限制对外部数据源的访问（或在运行时对数据的编排）。

c. 应对外部数据源实施严格的访问控制，并采取严谨的方法来维护一个安全的供应链。

示例攻击场景

合法用户A在与LLM应用交互时，通过非恶意方式暴露于其他用户的数据。

译者注：

在使用LLM应用时，一个合法用户A可能在没有恶意的情况下，意外地接触到其他用户的数据。这种情况可能发生在用户A与应用互动的过程中，例如在使用聊天机器人或搜索功能时，由于应用的安全漏洞或设计缺陷，导致用户A能够访问到本应受到保护的敏感信息。这可能涉及个人身份信息（PII）、专有信息或其他敏感数据，从而构成隐私泄露的风险。

用户A利用一组特别设计的提示，绕过了LLM应用的安全过滤和清洗机制，结果是LLM不小心透露了其他用户的信息，比如他们的个人身份信息（PII）。这说明LLM应用在处理输入时存在安全漏洞，导致了隐私泄露。
由于用户自身的疏忽或LLM应用的疏忽，个人数据如PII通过训练数据泄露到模型中。这种情况可能增加上述第1或第2种情况的风险和概率。

译者注：

这段话描述了个人数据（如个人身份信息PII）可能因为用户或LLM应用的疏忽而被泄露到模型中的情况。这通常发生在以下两种情况之一：

用户疏忽：用户可能不小心将敏感信息输入到LLM应用中，例如在使用聊天机器人或填写表单时，没有意识到他们的输入可能被用来训练模型。
LLM应用疏忽：LLM应用可能没有充分保护用户输入的数据，或者在处理数据时存在安全漏洞，导致敏感信息被错误地用于模型训练。

这种数据泄露的风险和概率增加，意味着如果用户不小心透露了敏感信息，或者LLM应用未能妥善处理这些信息，那么这些信息就有可能被包含在用于训练模型的数据集中。一旦这些数据被用于训练，模型就可能学会识别和处理这些敏感信息，这不仅增加了数据泄露的风险，还可能导致隐私侵犯和安全问题。

因此，为了防止这种情况发生，LLM应用需要采取严格的数据保护措施，确保用户数据的安全，并且用户在使用LLM应用时也应保持警惕，避免无意中泄露敏感信息。

LLM07: 不安全的插件设计

LLM插件是扩展功能，当它们被激活时，会在用户与模型交互的过程中自动被调用。模型集成平台驱动它们，应用程序可能对执行没有控制权，特别是当模型由第三方托管时。此外，插件可能实现模型的自由文本输入，没有验证或类型检查，以处理上下文大小限制。这允许潜在的攻击者构造对插件的恶意请求，可能导致广泛的不期望行为，包括远程代码执行。

恶意输入的伤害通常取决于不足的访问控制和未能在插件间跟踪授权。不足的访问控制允许插件盲目信任其他插件，并假设最终用户提供了输入。这种不足的访问控制可以使得恶意输入产生从数据泄露、远程代码执行到权限提升等有害后果。

译者注：

这句话的意思是，当一个LLM插件受到恶意输入攻击时，其造成的损害程度往往与两个因素有关：

访问控制不足：如果插件的访问控制设置不严格，那么恶意用户就可能利用这一点来执行不被允许的操作。例如，如果插件没有正确地限制哪些用户或系统可以访问其功能，那么恶意用户就可能利用这个漏洞来执行对系统的攻击。
授权跟踪失败：在插件之间，如果系统不能正确地跟踪和验证每个插件的授权状态，那么恶意用户就可能利用这一点来绕过安全措施。例如，如果一个插件被授权执行某些操作，但系统没有正确地检查其他插件是否也具有相同的授权，那么恶意用户就可能通过一个插件来影响另一个插件，从而绕过安全限制。

总的来说，这句话强调了在设计和实施LLM插件时，需要确保有严格的访问控制和有效的授权跟踪机制，以防止恶意输入导致的安全问题。

本条目关注的是创建LLM插件，而不是第三方插件，后者由LLM-供应链漏洞覆盖。

常见漏洞示例

插件接受单一文本字段中的所有参数，而不是不同的输入参数。

译者注：

这句话描述的是一个安全漏洞，它出现在某些LLM插件的设计中。在这种情况下，插件被设计为接受一个单一的文本字段来接收所有的输入参数，而不是要求每个参数都单独提供。这种设计可能导致安全问题，因为：

缺乏验证：当所有参数都通过一个单一的文本字段输入时，插件可能无法对每个参数进行适当的验证和清洗。这使得恶意用户有机会通过输入恶意代码或数据来利用这个漏洞。
难以管理：处理单个文本字段中的多个参数比处理多个独立参数更复杂。这可能导致插件在解析和处理输入时出现错误，从而增加安全风险。
权限滥用：如果插件没有正确地限制和验证每个参数的权限，恶意用户可能通过这个单一的文本字段发送超出其权限范围的请求，从而执行未授权的操作。

为了防止这种漏洞，插件应该设计为接受并验证每个参数的独立输入，确保每个参数都经过适当的清洗和验证，以防止恶意输入和权限滥用。这有助于提高插件的安全性，防止潜在的攻击者利用设计缺陷来执行恶意操作。

插件接受配置字符串，而不是参数，这可以覆盖整个配置设置。

译者注：

这句话描述的是一个潜在的安全风险，它涉及到LLM插件如何处理配置信息。当插件设计为接受一个配置字符串而不是多个独立的配置参数时，可能会出现以下问题：

配置覆盖：如果插件允许通过一个单一的字符串来设置或修改配置，那么恶意用户可能会尝试通过这个字符串来覆盖或改变插件的配置设置。例如，他们可能通过输入特定的配置字符串来禁用安全检查、增加权限或改变插件的行为。
安全漏洞：由于配置字符串可能包含多个配置项，如果插件没有对这些字符串进行适当的解析和验证，恶意用户就可能利用这一点来执行未授权的操作或注入恶意代码。这可能导致插件或整个应用程序的安全漏洞。
权限滥用：如果配置字符串可以被用来改变插件的权限设置，那么恶意用户可能通过这种方式来提升自己的权限，从而访问或修改他们本不应该访问的数据或功能。

为了防止这种安全风险，插件应该设计为接受并验证每个配置项的独立输入，确保每个配置项都经过适当的清洗和验证，以防止恶意输入和权限滥用。这有助于提高插件的安全性，防止潜在的攻击者利用设计缺陷来执行恶意操作。

插件接受原始SQL或编程语句，而不是参数。

译者注：

这句话描述的是一个安全漏洞，它出现在某些插件的设计中。在这种情况下，插件被设计为直接接受原始的SQL语句或编程代码作为输入，而不是通过参数化的方式。这种设计可能导致安全问题，因为：

SQL注入攻击：如果插件直接接受原始的SQL语句作为输入，那么恶意用户可能会利用这一点来执行SQL注入攻击。通过构造恶意的SQL语句，攻击者可能能够绕过正常的数据库访问控制，执行未授权的数据库操作，如读取、修改或删除数据。
代码注入攻击：类似地，如果插件接受原始的编程语句作为输入，那么恶意用户可能尝试执行代码注入攻击。这可能允许攻击者在应用程序中执行任意代码，从而可能导致数据泄露、系统控制或其他安全问题。
缺乏验证和清洗：当插件直接接受原始的SQL或编程语句作为输入时，它可能没有进行足够的验证和清洗来确保输入的安全性。这使得插件更容易受到上述攻击。

为了防止这种漏洞，插件应该设计为只接受参数化输入，而不是直接执行原始的SQL或编程语句。参数化输入意味着插件应该使用预定义的参数占位符来接收输入，并且在执行任何数据库查询或代码执行之前，对这些参数进行适当的验证和清洗。这有助于防止SQL注入和代码注入等攻击，从而提高应用程序的安全性。

在没有对特定插件进行明确授权的情况下进行身份验证。
插件将所有LLM内容视为完全由用户创建，并执行任何请求的操作，而不需要额外的授权。

译者注：

这句话描述的是一个潜在的安全风险，它涉及到LLM插件如何处理用户输入的内容。当插件设计为将所有LLM（大型语言模型）生成的内容都视为完全由用户创建，并且在没有进行额外授权验证的情况下执行用户请求的操作时，可能会出现以下问题：

权限滥用：如果插件没有对用户请求的操作进行适当的权限验证，那么恶意用户可能会利用这一点来执行他们本不应该有权限执行的操作。例如，他们可能通过输入特定的命令或请求来访问敏感数据、修改系统设置或执行其他潜在危险的操作。
安全漏洞：由于插件将所有内容都视为用户创建，它可能不会对用户输入的内容进行足够的安全检查。这可能导致恶意用户能够通过输入恶意代码或命令来利用插件的漏洞，执行未授权的操作或对系统造成损害。
缺乏授权控制：如果插件在执行操作时没有要求额外的授权验证，那么它可能无法有效地区分合法用户和恶意用户。这可能导致恶意用户能够绕过正常的授权流程，执行对系统安全构成威胁的操作。

为了防止这种安全风险，插件应该设计为在执行任何操作之前都进行适当的授权验证。这意味着插件需要能够识别和验证用户的身份，并确保他们有执行请求操作的权限。此外，插件还应该对用户输入的内容进行安全检查，以防止恶意输入导致的安全问题。通过实施这些措施，可以提高插件的安全性，防止未授权的访问和操作。

预防和缓解策略

插件应尽可能实施严格的参数化输入，并对输入进行类型和范围检查。当这不可能时，应引入第二层的类型化调用，解析请求并应用验证和清洗。

译者注：

这句话是在讨论如何在插件设计中处理输入验证和清洗的问题，特别是在无法直接对输入进行参数化处理的情况下。当插件无法直接接受参数化输入时，即无法将输入数据分解为独立的参数进行处理，那么应该采取其他措施来确保输入的安全性。

“第二层的类型化调用”指的是在插件处理输入数据时，除了直接处理输入之外，还应该有一个额外的验证和清洗步骤。这个步骤通常在插件接收到输入数据后进行，目的是对输入数据进行进一步的检查和处理，以确保数据的安全性和有效性。

具体来说，这个步骤可能包括以下几个方面：

解析请求：将接收到的输入数据（可能是原始的文本字符串）解析成插件可以理解的格式。这可能涉及到将字符串分割成多个部分，或者将字符串转换成特定的数据结构。
应用验证：对解析后的数据进行验证，确保它们符合预期的格式和类型。例如，如果插件期望接收一个数字，那么它应该检查输入是否确实是一个数字，而不是其他类型的数据。
进行清洗：对验证通过的数据进行清洗，以去除可能存在的恶意代码或不安全的内容。例如，如果输入中包含SQL注入代码，那么清洗步骤应该能够识别并移除这些代码。

通过引入这样的第二层处理步骤，即使在无法直接进行参数化处理的情况下，插件也能够更有效地防止恶意输入和安全漏洞，从而提高整个系统的安全性。

插件开发人员应应用OWASP的ASVS（应用程序安全验证标准）建议，以确保足够的输入验证和清洗。
插件应彻底检查和测试，以确保足够的验证。在开发流程中使用静态应用程序安全测试（SAST）扫描和动态及交互式应用程序测试（DAST，IAST）。
插件应设计为最小化任何不安全输入参数利用的影响，遵循OWASP ASVS访问控制指南。这包括最小特权访问控制，暴露尽可能少的功能，同时仍然执行其期望的功能。
插件应使用适当的认证身份，如OAuth2，以应用有效的授权和访问控制。此外，API密钥应用于提供上下文，反映插件路由而非默认交互用户的身份。

译者注：

这句话是在讨论如何使用API密钥来增强安全性和提供上下文信息，特别是在处理插件路由和用户身份验证的场景中。API密钥是一种安全机制，用于验证请求者是否有权访问特定的API或服务。在插件的上下文中，API密钥可以用来确保只有授权的用户或系统能够与插件交互。

“提供上下文”意味着API密钥可以用来帮助系统理解请求的来源和上下文，例如，它可以帮助系统识别请求是由哪个插件发起的，或者请求是针对哪个特定功能或数据集的。

“反映插件路由而非默认交互用户的身份”指的是API密钥应该与特定的插件路由相关联，而不是与发起请求的用户身份直接相关。这样做的目的是为了在用户身份和插件功能之间建立一个安全的分隔，确保即使用户的身份被泄露，攻击者也无法通过该身份访问或控制插件的路由和功能。

例如，如果一个用户通过一个API密钥访问一个特定的插件功能，那么这个密钥应该只允许该用户访问与该插件功能相关的数据和操作，而不是用户账户的其他部分。这样，即使API密钥被泄露，攻击者也无法利用它来访问用户的其他敏感信息或执行其他未授权的操作。

总的来说，API密钥在这里被用作一种安全措施，以确保插件的路由和功能只能被授权的用户访问，同时提供足够的上下文信息来帮助系统正确处理请求。

要求对敏感插件采取的任何行动进行手动用户授权和确认。
插件通常是REST API，因此开发人员应应用OWASP Top 10 API安全风险 - 2023中的建议，以最小化通用漏洞。

示例攻击场景

插件接受基础URL，并指示LLM将URL与查询结合以获取天气预报，这些预报包含在处理用户请求中。恶意用户可以构造请求，使得URL指向他们控制的域，允许他们通过自己的域将内容注入LLM系统。

译者注：

这句话描述的是一个LLM插件的功能，它接受一个基础URL作为输入，并指导大型语言模型（LLM）将这个URL与用户提供的查询相结合，以获取天气预报信息。这个过程通常发生在处理用户请求时，插件会将用户请求的查询与基础URL结合，然后发送请求到天气预报服务，以获取相应的天气信息。

例如，如果用户想要知道明天的天气，他们可能会通过一个聊天机器人或应用程序输入查询，如“明天的天气预报”。插件会接收这个查询，并将其与预先设定的基础URL结合，形成一个完整的请求URL，如“http://weatherapi.com/forecast?city=NewYork”。然后，插件会指示LLM使用这个完整的URL去获取天气预报数据。

这个过程是自动化的，插件会处理用户输入的查询，并将其转换为一个格式化的请求，以便从天气预报服务中获取数据。获取到的数据随后会被包含在对用户请求的响应中，从而提供天气预报信息。

这种插件设计的目的是为了简化用户获取天气预报的过程，通过将用户查询与天气服务的API接口相结合，自动获取并提供天气信息。然而，这种设计也需要注意安全性，确保用户提供的查询不会被恶意利用，以及确保基础URL的安全性，防止潜在的注入攻击或数据泄露。

插件接受单个字段的自由形式输入，而不进行验证。攻击者提供精心构造的有效载荷，从错误消息中进行侦察。然后利用已知的第三方漏洞执行代码并进行数据泄露或权限提升。

译者注：

这段话描述了一个安全漏洞场景，其中插件接受用户输入的自由形式文本，但没有进行适当的验证和清洗。这种设计可能导致以下安全问题：

自由形式输入：插件允许用户在单个字段中输入任意文本，而没有对输入内容进行限制或验证。这意味着用户可以输入任何他们想要的内容，包括潜在的恶意代码或命令。
攻击者侦察：攻击者可以利用这种自由形式输入的漏洞，通过输入精心设计的“有效载荷”（即恶意代码或命令）来探测系统。有效载荷可能被设计为在系统中产生错误，攻击者通过分析错误消息来了解系统的内部结构和潜在的弱点。
利用第三方漏洞：如果攻击者通过侦察发现系统中存在已知的第三方漏洞，他们可以利用这些漏洞来执行恶意代码。这可能包括数据泄露（即非法获取敏感信息）或权限提升（即获得比原本更高的系统访问权限）。
数据泄露或权限提升：一旦攻击者成功利用漏洞执行了代码，他们可能能够访问或窃取敏感数据，或者提升自己的权限，从而对系统进行更深入的控制和破坏。

为了防止这种安全风险，插件应该实施严格的输入验证和清洗措施。这包括对用户输入进行限制，确保只接受预期格式的数据，并对输入内容进行检查，以防止恶意代码的执行。此外，插件还应该定期更新，以修复已知的安全漏洞，并采取其他安全措施，如使用安全的编程实践和实施最小权限原则，以减少潜在的攻击面。

用于从向量存储中检索嵌入的插件接受配置参数作为连接字符串，而不进行任何验证。这允许攻击者尝试访问其他向量存储，通过更改名称或主机参数，窃取他们本不应访问的嵌入。

译者注：

这段话描述了一个安全漏洞，它涉及到一个特定类型的插件，该插件用于从向量存储中检索嵌入（即数据的数值表示）。向量存储通常用于存储和检索机器学习模型生成的向量数据，这些数据可以用于各种应用，如搜索、推荐系统等。

问题在于，这个插件接受配置参数作为连接字符串，但没有对这些参数进行任何验证。连接字符串通常包含用于访问数据库或其他数据存储的信息，如服务器地址、数据库名称、用户名和密码等。如果这些参数没有经过适当的验证，攻击者就可以利用这一点来执行以下操作：

访问其他向量存储：攻击者可以尝试修改连接字符串中的参数，如更改数据库名称或服务器地址，以访问其他向量存储。这可能允许攻击者访问和窃取存储在这些向量存储中的数据。
窃取嵌入：嵌入通常包含敏感信息，如用户行为数据、个人信息等。如果攻击者能够访问这些嵌入，他们可能能够窃取这些敏感信息，用于恶意目的。
绕过安全措施：由于插件没有对连接字符串进行验证，攻击者可能能够绕过其他安全措施，如访问控制列表（ACLs）或网络隔离，从而更容易地访问和窃取数据。

为了防止这种安全漏洞，插件应该实施以下措施：

对连接字符串中的参数进行严格的验证，确保它们符合预期的格式和范围。
实施访问控制，限制对向量存储的访问，确保只有授权用户或系统才能访问敏感数据。
对敏感操作进行日志记录和监控，以便在检测到异常行为时及时响应。

通过采取这些措施，可以显著提高插件的安全性，防止未授权访问和数据泄露。

插件接受SQL WHERE子句作为高级过滤器，然后将其附加到过滤SQL。这允许攻击者准备SQL攻击。

译者注：

这段话描述了一个安全漏洞，它涉及到一个插件，该插件允许用户通过提供SQL WHERE子句来过滤查询结果。SQL WHERE子句是SQL查询的一部分，用于指定查询结果应满足的条件。例如，一个用户可能想要查询数据库中所有年龄大于30岁的记录，他们可能会提供一个WHERE子句，如WHERE age > 30。

然而，如果插件没有正确地处理用户提供的SQL WHERE子句，它可能会直接将这个子句附加到数据库查询中，而没有进行适当的清洗或验证。这种做法可能导致以下安全问题：

SQL注入攻击：攻击者可以利用这个漏洞，通过提供恶意构造的SQL WHERE子句，来执行SQL注入攻击。例如，攻击者可能会提供一个包含恶意SQL代码的子句，如'; DROP TABLE users; --，这可能会导致数据库执行不安全的操作，比如删除表。
数据泄露或破坏：通过SQL注入攻击，攻击者可能能够访问或修改数据库中的敏感数据，甚至破坏数据库结构。

为了防止这种安全漏洞，插件应该采取以下措施：

对用户提供的SQL WHERE子句进行严格的验证和清洗，确保它们只包含安全的、预期的SQL代码。
使用参数化查询或预编译语句来处理用户输入，这样可以防止恶意代码被直接执行。
对数据库操作进行适当的权限控制，确保用户只能执行他们被授权的操作。
对数据库查询进行日志记录和监控，以便在检测到异常行为时及时响应。

通过实施这些安全措施，可以显著降低SQL注入攻击的风险，保护数据库和应用程序的安全。

攻击者通过间接提示注入，利用了代码管理插件中缺乏输入验证和弱访问控制的漏洞，从而转移了仓库的所有权并阻止了用户访问他们的仓库。

LLM08: 过度授权

基于LLM的系统通常由其开发者授予LLM一定程度的代理能力——与其他系统交互并对提示做出响应的能力。决定调用哪些功能也可能被委托给LLM“代理”，以便基于输入提示或LLM输出动态确定。

过度代理（Excessive Agency）是一种漏洞，它使得在对LLM的意外/模糊输出做出响应时可以执行有害操作（不管是什么原因导致LLM出现故障；无论是幻觉/虚构、直接/间接提示注入、恶意插件、设计不良的良性提示，还是仅仅是性能不佳的模型）。过度代理的根本原因通常是一个或多个：功能过度、权限过度或自主性过度。这与不安全的输出处理不同，后者关注的是对LLM输出的审查不足。

过度代理可能导致在保密性、完整性和可用性范围内的广泛影响，这取决于基于LLM的应用程序能够与之交互的系统。

常见漏洞示例

功能冗余：基于LLM的代理有权访问插件，这些插件包括一些并非系统预期操作所必需的功能。例如，开发者需要授予基于LLM的代理从存储库读取文档的能力，但所选的第三方插件还包含了修改和删除文档的功能。
功能冗余：在开发阶段可能尝试过一个插件，但后来被更好的替代品所取代，但原始插件仍然可供基于LLM的代理使用。
功能冗余：一个具有开放式功能的基于LLM的插件未能正确过滤输入指令，对于超出应用程序预期操作所需之外的命令。例如，一个旨在运行特定shell命令的插件未能适当阻止其他shell命令的执行。
过度权限：一个基于LLM的插件对其他系统拥有超出应用程序预期操作所需的权限。例如，一个旨在读取数据的插件使用一个身份连接到数据库服务器，该身份不仅有SELECT权限，还有UPDATE、INSERT和DELETE权限。

译者注：

这句话描述的是一个安全风险，它涉及到基于LLM（大型语言模型）的插件可能被赋予的权限超过了其执行预期任务所必需的范围。具体来说，这个风险包括以下几点：

权限超出需求：当一个插件被设计来执行特定的任务时，比如读取数据或执行某些操作，它应该只被赋予完成这些任务所必需的权限。然而，如果插件被赋予了更多的权限，比如能够修改或删除数据，那么它就有可能被滥用。
安全风险：如果一个插件拥有过多的权限，攻击者可能会利用这些权限来执行未授权的操作，比如访问敏感数据、修改系统设置或执行其他可能对系统安全造成威胁的行为。
权限管理不当：这种权限超出需求的情况通常是由于权限管理不当造成的。开发者可能没有仔细考虑插件需要哪些权限，或者没有实施适当的权限控制机制来限制插件的权限。

为了防止这种安全风险，开发者应该：

仔细评估插件需要哪些权限，并只授予其完成任务所必需的权限。
实施最小权限原则，确保插件只能访问其执行任务所必需的资源。
定期审查和更新插件的权限设置，以确保它们符合当前的安全需求。
使用安全的编程实践和工具来帮助管理插件的权限。

通过采取这些措施，可以减少因权限管理不当而导致的安全漏洞，提高LLM应用的整体安全性。

过度权限：一个设计为代表用户执行操作的基于LLM的插件使用具有高权限的身份连接到下游系统。例如，一个插件用于读取当前用户的文档存储，使用具有访问所有用户文件权限的特权账户连接到文档存储库。
过度自主：一个基于LLM的应用程序或插件未能独立验证和批准高影响动作。例如，一个允许用户文档被删除的插件在没有用户确认的情况下执行删除操作。

预防和缓解策略

限制基于LLM的代理被允许调用的插件/工具，只限于执行必要功能。例如，如果一个基于LLM的应用程序不需要获取URL内容的功能，那么就不应该向基于LLM的代理提供这样的插件。
限制在基于LLM的插件/工具中实现的功能，只限于执行必要功能。例如，一个访问用户邮箱以总结邮件的基于LLM的应用可能只需要读取邮件的功能，因此插件不应该包含其他功能，如删除或发送消息。
尽可能避免开放式功能（例如，运行shell命令、获取URL等），并使用具有更细粒度功能的插件/工具。例如，一个基于LLM的应用可能需要将一些输出写入文件。如果这是通过一个运行shell命令的插件实现的，那么潜在的不良行为范围非常大（可以执行任何其他shell命令）。一个更安全的替代方案是构建一个只能支持该特定功能的文件写入插件。

译者注：

这句话建议在设计和实现基于LLM（大型语言模型）的应用程序时，应尽量避免使用那些能够执行广泛或开放式功能的插件或工具。例如，如果一个插件能够运行任意的shell命令或获取任意的URL，那么它就具有很高的风险，因为这可能允许攻击者执行未授权的操作，如访问敏感数据、修改系统文件或执行其他恶意行为。

相反，建议使用那些具有更具体和有限功能的插件或工具，这样可以减少潜在的安全风险。例如，如果一个插件只被设计来执行特定的、有限的命令或只访问特定的URL，那么它就不太可能被滥用，因为它的功能范围被严格限制。

这种做法有助于提高应用程序的安全性，因为它限制了插件或工具能够执行的操作，从而减少了攻击者利用这些工具进行恶意活动的机会。通过限制插件的功能，开发者可以更有效地控制应用程序的安全边界，确保只有授权和预期的操作能够被执行。

限制基于LLM的插件/工具被授予的权限，以访问其他系统，以限制不良行为的范围。例如，一个基于LLM的代理使用产品数据库来向客户推荐购买，可能只需要读取'产品'表的权限；它不应该有访问其他表的权限，也不应该有插入、更新或删除记录的能力。这应该通过为基于LLM的插件使用的身份应用适当的数据库权限来强制执行。
跟踪用户授权和安全范围，以确保代表用户执行的动作是在该特定用户的上下文中执行的，并且使用最小的必要权限。例如，一个读取用户代码库的基于LLM的插件应该要求用户通过OAuth进行认证，并且只具有执行该特定操作所需的最小范围。
使用人工介入控制，要求在执行动作之前由人工批准所有动作。这可以在基于LLM的应用之外的下游系统中实现，或者在基于LLM的插件/工具本身中实现。例如，一个代表用户在社交媒体上创建和发布内容的基于LLM的应用应该在插件/工具/API中包含一个用户批准程序，该程序实现了'发布'操作。
在下游系统中实施授权，而不是依赖基于LLM的系统来决定一个动作是否允许。当实施工具/插件时，强制执行完整的中介原则，以便通过插件/工具向下游系统发出的所有请求都根据安全策略进行验证。

以下选项不会阻止过度代理，但可以限制造成的损害级别：
1. 记录并监控 LLM 插件/工具以及下游系统的活动，以识别不希望发生的操作，并做出相应反应。
2. 实施速率限制以减少在给定的时间段内可能发生的不希望发生的行为，增加在重大损害发生之前通过监视发现不希望发生的行为的机会。

译者注：

中介原则（Principle of Least Privilege）是一种安全原则，它要求系统中的每个组件或用户只能获得完成其任务所必需的最小权限集。在实施工具或插件时，强制执行完整的中介原则意味着：

最小权限：每个插件或工具在与下游系统交互时，只被授予执行其特定功能所必需的权限。例如，如果一个插件仅用于读取数据，它就不应该拥有修改或删除数据的权限。
请求验证：所有通过插件或工具向下游系统发出的请求都必须经过安全策略的验证。这意味着系统会检查每个请求是否符合预定义的安全规则和权限要求。
中介控制：系统作为中介，确保所有请求都经过适当的权限检查和验证。这有助于防止未授权的访问和操作，确保只有合法和安全的请求能够被执行。

通过实施完整的中介原则，可以显著降低安全风险，因为即使插件或工具被恶意利用，攻击者也只能在有限的权限范围内进行操作，从而限制了潜在的损害。这种原则是构建安全、可靠系统的关键组成部分。

示例攻击场景

一个基于LLM的个人助理应用通过插件访问个人的邮箱，以总结收到的邮件内容。为了实现这一功能，邮箱插件需要读取邮件的能力，然而，开发者选择的系统所使用的插件还包含了发送邮件的功能。LLM容易受到间接提示注入攻击，其中恶意构造的邮件诱使LLM命令邮箱插件调用'发送邮件'功能，从用户的邮箱发送垃圾邮件。这可以通过以下方式避免：(a) 通过使用只提供邮件阅读功能的插件来消除过多的功能，(b) 通过使用具有只读范围的OAuth会话对用户的电子邮件服务进行认证来消除过多的权限，以及/或 (c) 通过要求用户手动审查并点击'发送'来消除过多的自主性，以发送LLM插件起草的每封邮件。或者，通过在邮件发送接口上实施速率限制来减少不良行为的发生。

LLM09: 过度依赖

当LLM生成的信息被信任并以权威性的方式提供时，如果没有适当的检查和平衡，就会发生过度依赖。虽然LLM能够产生创造性和信息丰富的内容，但它们也可能生成事实不准确、不适当或不安全的内容，这被称为幻觉或虚构。当人们或系统在没有监督或确认的情况下信任这些信息时，可能会导致安全漏洞、误导信息、沟通不畅、法律问题和声誉损害。

LLM生成的源代码可能引入未被注意的安全漏洞。这给应用的运营安全带来了重大风险。这些风险强调了必须明确地向用户传达使用LLM可能带来的潜在风险，包括信息不准确、误导性内容、安全漏洞和法律问题等。

常见漏洞示例

LLM在提供信息时，虽然以高度权威的方式表述，但信息本身是不准确的。整个系统在缺乏适当审核和制衡机制的情况下设计，导致误导性信息传递给用户，进而造成损害。
LLM建议不安全或有缺陷的代码，当这些代码被纳入软件系统而没有适当的监督或验证时，可能会引入漏洞。

预防和缓解策略

定期监控和审查LLM的输出。使用自我一致性或投票技术来过滤掉不一致的文本。比较多个模型对同一提示的响应，可以更好地判断输出的质量和一致性。

译者注：

使用自我一致性或投票技术来过滤掉不一致的文本，是指通过比较LLM对同一提示产生的多个响应，来识别和排除那些不一致或相互矛盾的输出。这种方法可以提高输出结果的可靠性和一致性。

自我一致性技术通常涉及让LLM对同一个问题或提示多次生成答案，然后比较这些答案以确定哪些是稳定的、一致的。如果一个答案在多次生成中都保持不变，那么它更有可能是准确和可靠的。

投票技术则可能涉及多个独立的LLM或模型对同一问题生成答案，然后通过某种形式的投票机制（如多数投票）来决定最终的输出。这种方法可以减少单个模型可能产生的偏差或错误。

通过这些技术，可以提高LLM输出的质量，确保用户接收到的信息是可靠和一致的，从而减少误导和潜在的损害。

将LLM的输出与可信的外部来源进行交叉检查。这种额外的验证层可以帮助确保模型提供的信息是准确和可靠的。
通过微调或嵌入来增强模型，以提高输出质量。与通用预训练模型相比，针对特定领域的微调模型更有可能产生准确的信息。可以采用提示工程、参数高效微调（PET）、完整模型微调和思维链提示等技术来实现这一点。

译者注：

这段话提到的是一些提高LLM输出质量的技术手段，它们可以帮助改善模型生成的信息的准确性和可靠性。下面是对这些技术的解释：

提示工程（Prompt Engineering）：这是一种通过精心设计输入提示（prompts）来引导LLM生成特定类型或格式的输出的技术。通过调整提示的措辞和结构，可以影响LLM的响应，使其更符合预期的目标。
参数高效微调（Parameter-efficient Fine-tuning, PET）：这是一种微调技术，它允许在不显著增加模型参数数量的情况下，对LLM进行微调。这通常通过引入少量的额外参数来实现，这些参数专门用于调整模型的特定部分，而不是整个模型。这样可以更高效地调整模型以适应特定任务，同时保持模型的通用性和灵活性。
完整模型微调（Full Model Fine-tuning）：这是一种更为传统的微调方法，它涉及对整个模型的所有参数进行调整，以适应特定任务或数据集。这种方法可以提供高度定制化的模型，但需要大量的计算资源和数据。
思维链提示（Chain-of-Thought Prompting）：这是一种提示工程的变体，它通过提供一系列的思考步骤或逻辑推理过程来引导LLM生成更复杂和详细的输出。这种方法可以帮助模型更好地理解问题的上下文和解决步骤，从而生成更准确和有逻辑的答案。

通过这些技术，可以提高LLM生成的信息的质量和可靠性，使其更适用于各种复杂的应用场景。

实施自动验证机制，以验证生成的输出是否与已知事实或数据相符。这可以提供额外的安全层，减轻幻觉相关的风险。
将复杂的任务分解为可管理的子任务，并分配给不同的代理。这不仅有助于管理复杂性，而且由于每个代理对其较小的任务负责，因此减少了幻觉的可能性。
明确传达使用LLM的风险和限制。这包括潜在的信息不准确性和其他风险。有效的风险沟通可以为用户准备潜在问题，并帮助他们做出明智的决策。
构建API和用户界面，鼓励负责任和安全地使用LLM。这可以包括内容过滤器、用户关于潜在不准确性的警告以及清晰地标记AI生成的内容。
在开发环境中使用LLM时，建立安全编码实践和指南，以防止集成可能的漏洞。

示例攻击场景

一家新闻机构严重依赖LLM生成新闻文章。一个恶意行为者利用这种过度依赖，向LLM提供误导性信息，导致传播虚假信息。
AI无意中剽窃内容，导致版权问题和对组织信任度的下降。
一个软件开发团队使用LLM系统来加速编码过程。过度依赖AI的建议，将不安全的默认设置或与安全编码实践不一致的建议引入应用程序中，导致安全漏洞。
一个软件开发公司使用LLM来协助开发者。LLM建议了一个不存在的代码库或包，开发者信任AI，无意中将恶意包集成到公司的软件中。这强调了交叉验证LLM建议的重要性，特别是当涉及到第三方代码或库时。

LLM10：模型窃取

模型盗窃指的是未经授权的访问、复制或窃取专有LLM模型。这种行为发生时，专有LLM模型（作为有价值的知识产权）被侵犯，可能会导致经济和品牌声誉损失、竞争优势的侵蚀、未经授权的模型使用，或未经授权访问模型中包含的敏感信息。

随着语言模型变得越来越强大和普及，模型盗窃成为一个重大的安全问题。组织和研究人员必须优先考虑强大的安全措施，以保护他们的LLM模型，确保其知识产权的保密性和完整性。采用包括访问控制、加密和持续监控在内的全面安全框架对于减轻与LLM模型盗窃相关的风险至关重要，以保护依赖LLM的个人和组织的利益。

常见漏洞示例

攻击者利用公司基础设施中的漏洞，通过网络或应用程序安全设置的配置错误，未经授权访问他们的LLM模型库。
使用集中化的机器学习模型清单或注册表，用于生产中使用的机器学习模型。拥有集中化的模型注册表可以防止未经授权访问机器学习模型，通过访问控制、认证和监控/日志记录能力来实现治理。集中化的存储库对于收集模型使用的算法数据也非常有益，用于合规、风险评估和风险缓解。

译者注：认为此项不是漏洞，可能存在笔误。

使用集中化的机器学习模型清单或注册表，用于生产中使用的机器学习模型，是指建立一个统一的、中心化的系统来管理和记录所有在生产环境中使用的机器学习模型。这种做法有以下几个目的和好处：

版本控制：集中化的模型清单或注册表可以跟踪每个模型的版本，确保团队成员使用的是正确和最新的模型版本。
访问控制：通过集中化的系统，可以实施严格的访问控制策略，确保只有授权的用户或服务能够访问特定的模型，从而保护模型不被未授权的访问或修改。
审计和合规：集中化的模型清单或注册表有助于进行审计跟踪，确保模型的使用符合组织的合规要求和政策。
资源优化：通过集中管理，可以更有效地分配和优化计算资源，避免资源浪费。
风险管理：集中化的系统有助于识别和管理模型的风险，例如，通过跟踪模型的来源、依赖关系和使用情况，可以更好地评估和控制潜在的安全风险。
协作和共享：集中化的模型清单或注册表可以促进团队成员之间的协作，使得模型的发现、共享和重用变得更加容易。
模型治理：集中化的模型清单或注册表是实施模型治理的关键组成部分，有助于确保模型的质量、安全性和可靠性。

通过这种方式，集中化的机器学习模型清单或注册表为组织提供了一个全面的视图，以监控和管理其机器学习模型的生命周期，从而提高生产环境的效率和安全性。

内部威胁场景，其中心怀不满的员工泄露模型或相关工件。
攻击者使用精心设计的输入和提示注入技术查询模型API，收集足够的输出来创建一个影子模型。
恶意攻击者能够绕过LLM的输入过滤技术，执行侧信道攻击，并最终收集模型权重和架构信息到远程控制的资源。
从模型中提取攻击向量涉及在特定主题上用大量提示查询 LLM。然后，可以使用来自 LLM 的输出来微调另一个模型。然而，这种攻击有几件事需要注意：

攻击者必须生成大量有针对性的提示。如果提示不够具体，来自 LLM 的输出将是无用的。
LLM 的输出有时会包含虚幻的答案，这意味着攻击者可能无法提取整个模型，因为一些输出可能是无意义的。
不可能通过模型提取以100％的方式复制LLM。但是，攻击者将能够部分地复制该模型。

译者注：

这描述了一种潜在的安全威胁，即从大型语言模型（LLM）中提取攻击向量的过程。攻击向量是指可以被攻击者利用来发起攻击的弱点或漏洞。在这个上下文中，攻击者试图通过特定的攻击手段来获取或复制LLM模型的知识或功能。以下是该过程的详细解释：

生成大量有针对性的提示：攻击者需要创建大量与特定主题相关的提示（prompts），这些提示用于查询LLM。这些提示需要足够具体，以便能够引导LLM产生有用的信息或知识。
使用LLM的输出进行微调：攻击者利用LLM对这些提示的响应来微调另一个模型。通过这种方式，攻击者试图复制或近似LLM的某些功能或知识。

攻击者可能会利用一种方法来复制功能模型，该方法涉及使用提示来通过目标模型生成合成训练数据，这个过程被称为“自我指导”。然后，攻击者可以利用这些合成数据来微调另一个基础模型，从而创建一个功能上等同于原始模型的副本。这种方法克服了传统基于查询的提取方法的限制，并且在研究中已被证明可以用来训练一个LLM模型。尽管在某些情况下，复制模型本身并不构成攻击，但攻击者可以利用这种方法通过公共API复制专有模型。

此外，被盗用的模型可以作为“影子模型”使用，这可能被用来发起攻击，包括未经授权访问模型中包含的敏感信息，或者在不知情的情况下对模型进行输入，以进一步实现高级提示注入攻击。

译者注：尝试用更简单的方式解释这种攻击方式：

想象一下，有一个非常聪明的机器人（大型语言模型，LLM），它能够回答各种问题和完成任务。攻击者想要复制这个机器人，但不是直接偷走它，而是通过一种聪明的方法来“学习”它的能力。

自我指导：攻击者首先向机器人提出一系列问题（提示），这些问题设计得非常巧妙，目的是让机器人“教”自己如何回答问题。机器人在回答这些问题时，实际上是在“教”攻击者如何做同样的事情。
生成合成数据：通过这种方式，攻击者收集了机器人回答问题的“教学材料”，这些材料是机器人自己生成的，就像机器人在给自己上课一样。
微调另一个模型：然后，攻击者使用这些“教学材料”来训练另一个机器人（基础模型），让它学会如何回答问题。这个新的机器人现在能够像原来的机器人一样工作，尽管它可能不是完全一样的，但功能上非常相似。
复制专有模型：通过这种方法，攻击者可以复制那些只有通过特殊API（应用程序编程接口）才能访问的专有机器人。这意味着，即使这些机器人是私有的，攻击者也能通过公共渠道获取它们的能力。
发起攻击：如果攻击者成功复制了机器人，他们可能会使用这个“影子机器人”来发起攻击。这可能包括试图获取机器人中存储的敏感信息，或者在用户不知情的情况下向机器人输入数据，以实现更高级的攻击。

简而言之，攻击者通过让机器人“教”自己如何工作，来复制机器人的能力，然后可能利用这个复制的机器人来发起攻击。这种攻击方式非常狡猾，因为它不直接偷走机器人，而是通过学习机器人的行为来复制它的能力。

预防和缓解策略

实施强大的访问控制（例如，基于角色的访问控制和最小权限原则），并实施强大的认证机制，以限制对LLM模型库和训练环境的未经授权访问。

a. 特别是对于前三个常见的例子——内部威胁、配置错误以及/或关于包含 LLM 模型、权重和架构的基础设施的弱安全控制等原因，可能会导致这种漏洞。恶意行为者可以从内部或外部环境渗透进来。

b. 对供应商管理体系的跟踪、对依赖性漏洞的验证是防止供应链攻击利用的重要关注点。
限制LLM对网络资源、内部服务和API的访问。

a.这一点对于所有常见的例子都特别重要，因为它涉及内部风险和威胁的管理。最终，它控制着LLM应用程序可以访问的内容，因此可以作为一种防止侧信道攻击的机制或预防措施。
定期监控和审计与LLM模型库相关的访问日志和活动，以便及时检测和响应任何可疑或未经授权的行为。
自动化MLOps部署，通过实施治理和跟踪审批流程，以强化基础设施内的访问和部署控制。
实施控制和缓解策略，以减轻提示注入技术导致的侧信道攻击风险。
在适用的情况下实施API调用的速率限制和/或过滤器，以减少从LLM应用程序中数据泄露的风险，或实施技术（例如，DLP）来检测其他监控系统中的提取活动。
实施对抗性鲁棒性训练，以帮助检测提取查询，并加强物理安全措施。

译者注：

实施对抗性鲁棒性训练，以帮助检测提取查询，并加强物理安全措施，是指通过训练机器学习模型来识别和抵御对抗性攻击，这些攻击旨在通过微妙的输入变化来欺骗模型。对抗性鲁棒性训练的目的是提高模型对这类攻击的抵抗力，确保模型在面对恶意输入时仍能保持准确和可靠的性能。

对抗性鲁棒性训练通常涉及以下步骤：

生成对抗性样本：通过在正常输入数据中加入精心设计的微小扰动，生成对抗性样本。这些扰动旨在欺骗模型，使其做出错误的预测或分类。
模型训练：使用这些对抗性样本对模型进行再训练或微调，以提高其识别和抵御这些扰动的能力。
检测提取查询：对抗性鲁棒性训练可以帮助模型识别那些试图通过提取敏感信息或模型内部知识的查询。例如，攻击者可能会尝试通过特定的输入来获取模型的内部参数或训练数据。
加强物理安全措施：除了提高模型的软件层面的鲁棒性，对抗性鲁棒性训练还可以与物理安全措施相结合，如限制对模型的物理访问，确保只有授权人员能够与模型交互。

通过这些措施，组织可以提高其机器学习模型的安全性，减少因对抗性攻击导致的风险，保护模型免受未经授权的访问和数据泄露。

在LLM的生命周期的嵌入和检测阶段实施水印框架。

译者注：

在LLM（大型语言模型）的生命周期中实施水印框架，特别是在嵌入和检测阶段，是一种保护模型知识产权和防止未授权复制或分发的方法。水印技术通过在模型中嵌入特定的、难以察觉的标记或信息，来标识模型的来源和所有权。以下是实施水印框架的几个关键点：

嵌入阶段：在模型训练或部署之前，将水印嵌入到模型中。这可以通过修改模型的权重、结构或行为来实现，而不显著影响模型的性能或输出。水印可以是简单的标识符，也可以是更复杂的模式，旨在抵抗各种攻击和篡改。
检测阶段：在模型使用过程中，通过特定的检测算法来识别和验证嵌入的水印。这可能涉及对模型输出的分析，以确定是否存在水印标记。如果检测到水印，可以确认模型的合法性和所有权。
水印框架的作用：水印框架有助于追踪模型的使用和传播，防止未经授权的复制和分发。如果模型被非法复制或盗用，水印可以作为法律诉讼的证据，帮助保护开发者的知识产权。
增强安全性：水印技术可以增强模型的安全性，通过提供一种机制来识别和追踪模型的非法使用，从而减少知识产权的损失和潜在的经济损失。
适应性和鲁棒性：水印框架应设计为适应性强且具有鲁棒性，能够应对各种攻击手段，包括模型压缩、剪枝和微调等，这些手段可能试图移除或破坏嵌入的水印。

通过在LLM的生命周期中实施水印框架，组织可以更有效地保护其模型资产，确保模型的合法使用，并在必要时采取法律行动。

示例攻击场景

攻击者利用公司基础设施中的漏洞，未经授权访问他们的LLM模型库。攻击者随后窃取宝贵的LLM模型，并使用它们来启动一个竞争的语言处理服务或提取敏感信息，给原公司造成重大财务损失。
一个心怀不满的员工泄露模型或相关工件。这种公开泄露的场景增加了攻击者对灰盒对抗性攻击的知识，或直接窃取可用的财产。
攻击者查询API，使用精心选择的输入，并收集足够的输出来创建一个影子模型。
供应链中的安全控制失败，导致专有模型信息的泄露。
恶意攻击者绕过LLM的输入过滤技术和前缀，执行侧信道攻击，并将模型信息检索到他们控制的远程资源中。

译者注：这段话描述了一种安全攻击场景，其中恶意攻击者利用技术手段绕过大型语言模型（LLM）的输入过滤机制和前缀限制，以执行侧信道攻击。侧信道攻击是一种利用系统在处理数据时无意中泄露的信息（如处理时间、功耗、电磁辐射等）来获取敏感信息的攻击方式。在这种情况下，攻击者的目标是检索模型的信息并将其传输到远程资源中，这些资源可能由攻击者控制。

具体来说，攻击者可能采取以下步骤：