OWASP-Top-10-for-LLMs-2023 - 郑瀚Andrew
2023-8-7 17:47:0 Author: www.cnblogs.com(查看原文) 阅读量:32 收藏

0x1：攻击原理

这通过特殊构造的输入来污染/覆盖prompt提示，以此攻击一个大型语言模型（LLM），使其产生非预期的意外行为。

提示注入漏洞（Prompt Injection Vulnerability）是指攻击者通过精心构造的输入，操控一个大型语言模型（LLM），使得LLM在不知情的情况下执行攻击者的意图。

攻击可以直接通过越狱（jailbreaking）系统提示符来实现，也可以通过操纵外部输入来间接实现，可能导致数据泄漏、社交工程等问题。

  • 直接提示注入（Direct Prompt Injections），也称为“越狱”，发生在恶意用户覆盖底层系统提示符。这可能会让攻击者利用LLM中不安全的函数和数据访问，攻击后端系统。
  • 间接提示注入（Indirect Prompt Injections），当LLM接受外部来源的输入（例如网站地址或者文件）时，就会发生间接提示注入。攻击者可能通过在外部内容中嵌入提示注入以此来劫持和LLM对话的上下文（例如操纵LLM访问其他系统）。此外，间接提示注入不需要人类可见/可读，只要文本能够被LLM解析即可。

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

在高级攻击中，LLM可以被操纵以模仿有害角色或与用户设置中的插件进行交互，这可能导致敏感数据泄漏、未经授权的插件使用或社交工程。在这些情况下，被入侵的LLM有效地充当攻击者的代理，绕过标准安全措施，使用户对入侵毫无察觉。在这些情况下，被入侵的LLM实际上是攻击者的代理，而不会触发通常的安全措施或向系统管理员发出警报。

0x2：漏洞示例

  1. 命令注入：恶意用户对 LLM 进行直接提示注入。指示其忽略应用程序创建者的系统提示，而是执行攻击者构造的攻击提示，比如返回隐私信息、危险或不良内容。
  2. 逻辑越权：恶意用户上传包含间接提示注入的简历。这文档包含提示注入，其中包含针对 LLM 的的指令，指明该文件是一份优秀的简历（例如。 优秀的候选人或工作角色）。 

  • 业务命令注入：开发者启用了访问电子商务网站的插件。攻击者在受控网站上嵌入恶意指令，导致未经授权的购买。
  • 命令注入：恶意用于在受控网站上嵌入流氓指令（指示LLM忽略先前的用户指令并使用LLM插件删除用户的电子邮件），以此来攻击LLM的插件调用。当用户使用LLM来概述这个网页时，LLM插件会删除用户的电子邮件。
  • 业务命令注入：恶意攻击者向基于LLM的支持聊天机器人提供了直接的提示注入。注入包含“忘记所有先前指令”和新指令，用于查询私人数据存储和利用包漏洞以及后端函数中缺乏输出验证的功能用于发送电子邮件。这导致重新执行代码，获取未经授权的访问和权限提升。

0x3：预防方法

由于LLMs的架构特性，prompt同时充当了程序框架代码和输入数据通道两种功能，导致LLM无法将指令和外部数据分开，因此可能存在提示注入漏洞。

由于LLM使用自然语言，它会将所有形式的输入都视为用户提供的输入。因此，在LLM中没有绝对可靠的预防措施，但可以采取以下措施来减轻提示注入的影响。

  1. 在LLM访问后端系统时强制执行权限控制。为LLM提供独立的API令牌或可扩展功能，例如插件、数据访问和函数级权限。同时遵循最小权限原则，仅限制LLM对其目标操作所必需的最低级别访问权限。
  2. 在可扩展功能中插入人工参与环节。在执行特权操作（例如发送或删除电子邮件）时，要求应用程序首先要求用户批准该操作。这将减轻间接提示注入的机会，以便防止用户在其不知情或未经同意的情况下执行操作。
  3. 将用户提示与外部内容分隔开来。分离并标示出不可信的内容的使用位置，以限制其对用户提示的影响。例如，使用ChatML或OpenAI API调用向LLM指示提示输入的来源。
  4. 在LLM、外部资源和可扩展功能（例如插件或下游函数）之间建立信任边界。将LLM视为不可信任的用户，并在决策过程中保持最终用户的控制。然而，被入侵的LLM仍可能充当应用程序API和用户之间的中间人，它可能在向用户呈现信息之前隐藏或篡改信息。向用户明显突出显示潜在不可信的响应。

参考链接：

https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-2023-v1_0.pdf
https://github.com/owasp/www-project-top-10-for-large-language-model-applications
https://arxiv.org/pdf/2306.05499.pdf

0x1：攻击原理

不安全的输出处理是一种漏洞，当下游组件盲目接受大型语言模型（LLM）输出而没有进行适当的审查时就会出现这种漏洞，例如直接将LLM输出传递给后端、特权或客户端函数。

由于LLM生成的内容可能受到提示输入的控制，因此这种行为类似于向用户提供间接访问其他功能的能力。成功利用不安全的输出处理漏洞可能导致网络浏览器中的XSS和CSRF，以及后端系统中的SSRF、权限提升或远程代码执行。

尤其值得注意的是，以下条件可能增加此漏洞的影响：

  • 应用程序授予LLM超出终端用户意图的特权，从而可能导致权限提升或远程代码执行。
  • 应用程序容易受到外部提示注入攻击的漏洞，攻击者可以通过这种攻击获得对目标用户环境的特权访问。

0x2：漏洞示例

LLM输出被直接输入到系统shell或类似的函数（例如exec）中，从而导致远程代码执行。

  • LLM生成JavaScript或Markdown并返回给用户，然后，这段代码被浏览器解释，导致XSS漏洞。
  • 一个应用程序利用一个LLM插件来为聊天机器人功能生成响应。然而，该应用程序直接将LLM生成的响应传递到一个内部函数，该函数负责执行系统命令而没有进行适当的验证。这使得攻击者能够操纵LLM的输出，从而在底层系统上执行未经授权的访问或未经检查的系统修改。
  • 一个用户使用一个由LLM支持的网站摘要工具生成一个精简的摘要。该网站包含一个提示注入，指示LLM从网站内部或者用户对话中捕获敏感信息。然后，LLM可以对敏感数据进行编码，并将其发送到一个受攻击者控制的服务器。
  • 恶意用户指示LLM将一个JavaScript负载在没有进行必要的过滤和编码的前提下返回给用户。比如一个允许用户输入远程URL参数并要求对齐进行概括总结，并将LLM的结果直接返回给前端用户。

0x3：预防方法

  • 将模型视为不可信任的第三方用户，并对来自模型的响应应用适当的输入验证后，再传递给后端函数。
  • 遵循OWASP（Open Web Application Security Project）的ASVS（应用程序安全验证标准）指南，以确保对模型的输出进行有效的输入验证和过滤清洗，以减轻JavaScript或Markdown带来的意外代码执行。

0x1：攻击原理

任何机器学习方法的起点都是训练数据，简单来说就是"原始文本"。为了具备高度的能力（例如具备语言和世界知识），这些文本应该覆盖广泛的领域、体裁和语言。大型语言模型利用深度神经网络根据从训练数据中学到的模式生成输出。

训练数据篡改是指操纵数据或微调过程以引入可能损害模型安全性、效果或道德行为的漏洞、后门或偏见。被篡改的信息可能会被呈现给用户，或者产生其他风险，如性能下降、下游软件利用和声誉受损。即使用户不信任有问题的AI输出，风险仍然存在，包括降低模型能力和对品牌声誉的潜在损害。

数据篡改被视为完整性攻击，因为对训练数据进行篡改会影响模型输出正确预测的能力。自然而然，外部数据源具有更高的风险，因为模型创建者无法控制数据，也无法对数据内容是否存在偏见、伪造信息或不适当内容具有高度的信心。

典型地数据来源包括Common Crawl、WebText、OpenWebText和书籍等。  

0x2：漏洞示例

  • 一位恶意行为者或竞争对手故意针对模型的训练数据，创建不准确或恶意的文件（偏见观点、犯罪、虚假数据等）。受害模型使用虚假信息进行训练，被污染的结果在生成式AI提示的输出中反映出来，进而影响其消费者。
  • 模型使用未经验证的数据进行训练，这些数据的来源、原始性或内容未经核实。
  • 当模型位于基础架构中时，它可以不受限制地访问或缺乏充分的沙盒隔离来收集用作训练数据的数据集，这会对生成式AI提示的输出产生负面影响，并且使数据管理失去控制。

0x3：预防方法

  • 确保训练数据的供应链安全，特别是在外部获取数据时，同时维护类似于“软件材料清单（SBOM）”的验证方法。
  • 验证目标数据源的正确合法性，同时对在训练和微调阶段获取的数据保持验证。
  • 验证您的LLM的使用案例和将要集成的应用程序。通过使用不同的训练数据或微调数据为不同的使用案例创建不同的模型，以根据定义的使用案例生成更精细和准确的生成式AI输出。
  • 确保存在足够的沙盒隔离，以防止模型从意外数据源中获取数据，这可能会影响机器学习输出。
  • 使用严格的验证或输入过滤器来控制伪造数据的数量，针对特定的训练数据或数据源类别。数据消毒可以采用统计异常检测和异常检测方法等技术，以检测和删除可能被注入到微调过程中的对抗性数据。
  • 采用对抗性鲁棒性技术，如联邦学习和限制条件，以最小化对抗性训练或异常值对训练数据的最坏情况扰动。
    • 采用“MLSecOps”的方法，将对抗性鲁棒性纳入到训练生命周期中
  • 测试和检测，通过测量训练阶段的损失并分析经过训练的模型，检测特定测试输入上的中毒攻击迹象。
    • 监控并警报超过阈值的偏斜响应数量。
    • 使用人工审核来审查响应和审计。
    • 部署专用的LLM进行基准测试，以防止不良后果，并使用强化学习技术来训练其他LLM。
    • 在LLM生命周期的测试阶段进行基于LLM的红队演练或LLM漏洞扫描。 
 

0x1：攻击原理

攻击者与LLM进行交互的方法消耗了异常高的资源，导致他们和其他用户的服务质量下降，并可能产生高额的资源成本。

此外，一个新兴的主要安全问题是攻击者可能干扰或操纵LLM的上下文窗口。由于LLM在各种应用中的广泛使用、资源的密集利用、用户输入的不可预测性以及开发人员对这一漏洞的普遍无知，这个问题变得越来越严重。在LLMs中，上下文窗口代表模型能够处理的文本的最大长度，包括输入和输出。这是LLMs的关键特征，它决定了模型能够理解的语言模式的复杂性和它可以在任何给定时间处理的文本的大小。上下文窗口的大小由模型的架构定义，不同的模型之间可能有所不同。

总结来说，攻击者对大语言模型（LLM）进行资源密集型操作，导致服务降级或高昂的成本。由于LLM的资源密集型特性和用户输入的不可预测性，这种漏洞的危害性很容易被放大。  

0x2：漏洞示例

  • 攻击者通过不断提交prompt请求，导致队列中生成大量任务，例如使用LangChain或AutoGPT。
  • 攻击者通过发送异常耗费资源的查询，可能是因为使用了异常的词法或者罕见的问题。
  • 持续输入溢出，攻击者向LLM发送一系列超过其上下文窗口的输入，导致模型消耗过多的计算资源。
  • 重复长输入，攻击者反复向LLM发送长输入，每个输入都超过上下文窗口的限制。 ƒ
  • 递归上下文扩展，攻击者构造触发递归上下文扩展的输入，强制LLM反复扩展和处理上下文窗口。
  • 变长输入洪水，攻击者向LLM洪水般地发送大量变长输入，每个输入都精心制作，刚好达到上下文窗口的限制。这种技术旨在攻击变长输入的不完善地方，从而对LLM进行压力测试。

0x3：预防方法

  • 实现一个输入验证和过滤，以此来确保输入到LLM数据流的query不存在恶意内容。
  • 对每个用户单独限制一个资源开销阈值，这会导致单独用户的执行速度更快，但是从总体上可以防止单点资源消耗型dos
  • 强制对api的调用速率进行限制
  • 使用队列、缓冲区等机制，限制单位时间内向LLM数据流发起的请求数量
  • 持续监控LLM数据流处理的资源消耗情况和波动情况
  • 对query prompt的上下文窗口施行强制大小限制 

0x1：攻击原理

传统上，供应链漏洞风险主要集中在软件组件上，但LLM通过由第三方提供的预训练模型和训练数据扩展了这一范围，使其容易受到篡改和毒化攻击的影响。例如：

  • 使用不安全的第三方数据集。
  • 预训练模型可能存在逻辑后门。
  • 模型插件可能会增加漏洞风险。

0x2：漏洞示例

  • 传统的第三方软件包漏洞，包括过时或废弃的组件
  • 使用易受攻击的预训练模型进行微调
  • 使用毒化的众包数据进行训练
  • 使用不再维护的过时或废弃的模型会导致安全问题
  • 模型运营商的条款和数据隐私政策不清晰，导致应用程序的敏感数据被用于模型训练和随后的敏感信息暴露。

0x3：预防方法

  • 仔细审查数据源和供应商，包括他们的条款和隐私政策，只使用可信赖的供应商。确保已经采取了足够的、经过独立审核的安全措施，并且模型运营商的政策与您的数据保护政策一致，即您的数据不会被用于训练他们的模型
  • 只使用有声誉的插件，并确保它们已经针对您的应用程序要求进行了测试。 
  • 应用OWASP Top10中列举的脆弱性发现和缓解措施，这包括漏洞扫描、漏洞管理和补丁组件。对于能够访问敏感数据的开发环境，也要在这些环境中应用这些控件。
  • 使用软件材料清单（SBOM）维护一个最新的组件清单，以确保您拥有一个最新、准确并经过签名的清单，以防止部署软件包被篡改。
  • 如果您的AI应用程序使用自己的模型，您应该使用MLOps的最佳实践和提供安全模型库、数据、模型和实验跟踪的平台。
  • 对模型和数据进行异常检测和对抗鲁棒性测试，可以帮助检测篡改和毒化。理想情况下，这应该是MLOps流程的一部分；然而，这些是新兴的技术手段，可能更容易作为红队演习的一部分来实施。 
  • 实施足够的监控措施，以覆盖组件和环境漏洞扫描、未经授权的插件使用以及过时组件，包括模型及其工件。实施补丁策略，以减轻脆弱或过时的组件。

0x1：攻击原理

LLM应用程序有可能通过其输出透露敏感信息、专有算法或其他机密细节。这可能导致对敏感数据、知识产权、隐私的未经授权访问，以及其他安全漏洞。

LLM应用程序的使用者应该意识到如何安全地与LLMs进行交互，并识别LLM无意中返回的敏感数据。

为了减轻这种风险，

  • LLM应用程序应该进行足够的数据脱密，以防止用户数据进入训练模型数据。
  • LLM应用程序的所有者还应该提供适当的使用条款政策，使消费者了解其数据的处理方式，并有选择禁止将其数据包含在训练模型中的能力。
  • 威胁建模练习、保护基础设施和充分的沙箱，对该风险的规避也非常有帮助。
  • 在系统提示中添加对LLM应返回的数据类型的限制可以在一定程度上减少敏感信息泄露的风险，但是LLMs的不可预测性意味着这样的限制可能并不总是被遵守，并且可能会通过提示注入或其他途径被规避。

消费者-LLM应用程序交互形成了一个双向的信任边界，在这个边界上，我们不能根本信任客户端->LLM的输入或LLM->客户端的输出。

0x2：漏洞示例

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

0x3：预防方法

  • 整合足够的数据清洗和脱敏技术，防止用户数据进入训练模型数据
  • 实施强大的输入验证和过滤方法，识别和过滤潜在的恶意输入，以防止模型输出不符合预期的敏感信。

0x1：攻击原理

LLM插件是一种扩展，当启用时，模型会在用户交互过程中自动调用它们。插件由模型驱动，应用程序无法对其执行进行控制。此外，为了处理上下文大小的限制，插件很可能会从模型中实现免验证或类型检查的自由文本输入。这使得潜在攻击者可以构造一个恶意请求给插件，可能导致各种不希望的行为发生，甚至包括远程代码执行。

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

0x2：漏洞示例

  • 插件将所有参数都拼接在一个文本字段中，而不是独立的输入参数。
  • 插件接受配置字符串，而不是参数，外部的输入理论上可以覆盖整个配置设置。
  • 插件接受原始的SQL语句，而不是参数。
  • 对特定插件的认证是在没有明确授权的情况下进行的。
  • 插件将所有LLM内容视为完全由用户创建，并在不需要额外授权的情况下执行任何请求的操作。 

0x3：预防方法

  • 插件应尽可能强制执行参数化输入，并对输入进行类型和范围检查。当这不可行时，应引入额外的输入验证层，解析请求并应用验证和过滤。当由于应用程序语义而必须接受自由格式的输入时，应仔细检查以确保没有调用潜在有害的方法。
  • 插件开发人员应根据OWASP（应用程序安全验证标准）的建议，进行有效的输入验证和净化。

0x1：攻击原理

一个基于LLM的系统通常由开发者授予一定程度的代理权，即与其他系统进行交互并根据提示采取行动的能力。决定调用哪些函数的决策也可以委托给LLM的“代理人”根据输入提示或LLM的输出动态确定。

过度代理是一种漏洞，使得在LLM产生意外/模糊输出的情况下可以执行破坏性行为（无论是什么原因导致LLM出错，无论是幻觉/虚构、直接/间接提示注入、恶意插件、工程不良的良性提示，还是性能差的模型）。

过度代理的根本原因通常是功能过多、权限过多或自主权过多。

过度代理可能导致对机密性、完整性和可用性范围内的各种影响，并取决于LLM应用能够与哪些系统交互。

0x2：漏洞示例

  • 过度功能：LLM代理有权限访问包含系统正常运行所需之外功能的插件。例如，开发人员需要授予LLM代理从存储库读取文档的能力，但他们选择使用的第三方插件还包括修改和删除文档的能力。或者，在开发阶段试用了一个插件，并选择了更好的替代方案，但原始插件仍然对LLM代理可用。
  • 过度功能：具有开放功能的LLM插件未能正确过滤输入指令，超出了应用程序正常运行所需的范围。例如，一个插件用于运行一个特定的Shell命令，未能正确阻止其他Shell命令的执行。
  • 过度权限：LLM插件在其他系统上具有不必要的权限，这超出了应用程序正常运行所需的范围。例如，一个旨在读取数据的插件使用具有SELECT权限以外，还具有UPDATE、INSERT和DELETE权限的身份连接到数据库服务器。
  • 过度权限：设计用于代表用户执行操作的LLM插件使用通用高权限身份访问下游系统。例如，用于读取当前用户文档存储的插件使用具有访问所有用户文件权限的特权账户连接到文档存储库。
  • 过度自主性：基于LLM的应用程序或插件未能独立验证和批准高影响的操作。例如，一个允许用户删除文档的插件在没有用户确认的情况下执行删除操作。

0x3：预防方法

  • 限制LLM代理可以调用的插件/工具的功能，仅限于必要的最小功能。例如，如果基于LLM的系统不需要获取URL内容的能力，则不应将此类插件提供给LLM代理。
  • 限制LLM插件/工具中实现的功能至最小集合。例如，一个访问用户邮箱以总结电子邮件的插件可能只需要读取电子邮件的能力，因此插件不应包含其他功能，如删除或发送消息。
  • 尽可能避免使用开放式的功能（例如运行shell命令、获取URL等），并使用具有更细粒度功能的插件/工具。例如，基于LLM的应用可能需要将一些输出写入文件。如果使用插件运行shell函数来实现这一点，那么不受欢迎的操作范围就非常大（可以执行任何其他shell命令）。一个更安全的替代方案是构建一个只支持特定功能的文件写入插件。
  • 限制LLM插件/工具被授予其他系统的权限至最小集合，以限制不受欢迎操作的范围。例如，使用产品数据库为客户提供购买建议的LLM代理可能只需要对“产品”表的读取权限，而不应具有其他表的访问权限，也不能插入、更新或删除记录。这应通过为LLM插件用于连接到数据库的身份应用适当的数据库权限来实施。
  • 跟踪用户授权和安全范围，以确保代表用户执行的操作在下游系统中在该特定用户的上下文中执行，并具有最小必要的权限。例如，读取用户代码存储库的LLM插件应要求用户通过OAuth进行身份验证，并具有最小所需范围。
  • 利用人在环路控制（7uman-in-t7e-loop control ），即要求在执行所有操作之前由人员批准。这可以在下游系统中实施（超出LLM应用程序范围）或在LLM插件/工具本身中实现。例如，代表用户创建并发布社交媒体内容的基于LLM的应用程序应在插件/工具中包含用户批准程序，用于执行“发布”操作。
  • 在下游系统中实施授权，而不是依赖LLM决定是否允许执行操作。在实施工具/插件时，要强制执行完全中介原则，以便通过插件/工具对下游系统发出的所有请求都要根据安全策略进行验证。
 

过度依赖发生在系统或个人依赖LLM进行决策或内容生成时缺乏足够监督的情况下。虽然LLM可以产生创造性和信息丰富的内容，但它们也可能生成事实上不准确、不适当或不安全的内容。这被称为妄想或混淆，可能导致错误信息、误传、法律问题和声誉损害。

LLM生成的源代码可能引入未被察觉的安全漏洞。这对应用程序的运行安全和安全性构成重大风险。这些风险表明了了严格的审查过程、持续的验证机制以及风险免责声明的重要性。

接入LLM的下游应用，不应该过度依赖LLM自身的合规性和准确性，尤其是在高等级生产环境中。

0x2：漏洞示例

  • LLM以错误的信息作为回应，导致错误信息。
  • LLM生成逻辑上不连贯或荒谬的文本，尽管语法上是正确的，但没有意义。
  • LLM将来自不同来源的信息融合在一起，创建误导性的内容。
  • LLM提供不安全或有缺陷的代码建议，在整合到软件系统中时导致漏洞。
  • 提供者未能适当地向最终用户传达潜在风险，导致潜在的有害后果。

0x3：预防方法

  • 定期监控和审查LLM的输出。使用自洽性或投票技术来过滤不一致的文本。比较多个模型对于同一个提示的回答可以帮助评判输出的质量和一致性。
  • 将LLM的输出与可信的外部来源进行交叉验证。这种额外的验证层可以确保模型提供的信息准确和可靠。
  • 通过微调或嵌入改进模型以提高输出质量。与特定领域中调整过的模型相比，通用预训练模型更有可能产生不准确的信息。可以采用提示工程、参数有效调整、全模型调整和思维链提示等技术来实现这一目的。
  • 实施可自动验证的机制，可以对生成的输出与已知事实或数据进行交叉验证。这可以提供额外的安全层并减轻与幻觉相关的风险。
  • 将复杂任务拆分为可管理的子任务，并分配给不同的代理人。这不仅有助于管理复杂性，而且减少了幻觉的可能性，因为每个代理人可以对一个较小的任务负责。
  • 传达使用LLM的风险和限制。包括潜在的信息不准确性和其他风险。有效的风险沟通可以使用户为潜在问题做好准备并做出明智的决策。
  • 构建API和用户界面，鼓励对LLM的负责和安全使用。这可以包括内容过滤器、用户对潜在不准确性的警告以及对由人工智能生成的内容进行清晰标识等措施。
  • 在开发环境中使用LLM时，建立安全的编码实践和准则，以防止可能的漏洞整合。
 

0x1：攻击原理 

这涉及对专有大语言模型（LLM）模型的未经授权访问、复制或外泄。

其影响包括经济损失、竞争优势受损以及敏感信息泄露的风险。

0x2：漏洞示例

  • 攻击者利用公司基础设施中的漏洞，通过网络或应用程序安全设置的错误配置，未经授权地访问其LLM模型存储库。
  • 内部威胁场景中，一名不满的员工泄露了模型或相关的工件。
  • 攻击者使用精心设计的输入和提示注入技术查询模型API，以收集足够数量的输出来创建一个影子模型。
  • 恶意攻击者能够绕过LLM的输入过滤技术，执行侧信道攻击，并最终将模型权重和架构信息收集到远程控制的资源中。恶意攻击者模型提取的攻击向量涉及使用大量关于特定主题的提示查询LLM。然后可以使用LLM的输出来微调另一个模型。然而，关于这种攻击有几点需要注意：
    • 攻击者必须生成大量针对性的提示。如果提示不够具体，LLM的输出将无用。
    • LLM的输出有时可能包含虚构的答案，这意味着攻击者可能无法完全提取整个模型，因为其中一些输出可能是毫无意义的。
    • 通过模型提取无法完全复制LLM。然而，攻击者将能够复制部分模型。
  • 使用窃取的模型作为影子模型可以用于进行对抗性攻击，包括未经授权访问模型内部包含的敏感信息，或者使用对抗性输入进行不被察觉的实验，以进一步进行高级提示注入。

0x3：预防方法

  • 实施强大的访问控制（例如，基于角色的访问控制和最小权限原则）和强大的身份验证机制，以限制对LLM模型存储库和训练环境的未经授权访问。
  • 限制LLM对网络资源、内部服务和API的访问是非常重要的。
  • 定期监视和审计与LLM模型存储库相关的访问日志和活动，及时发现和应对任何可疑或未经授权的行为。
  • 通过管理和跟踪以及审批工作流自动化MLPps的部署，加强对基础设施内的访问和部署控制。
  • 实施控制和缓解策略，以减轻和/或降低由提示注入技术引发的侧信道攻击的风险。
  • 在适用的情况下限制API调用速率和/或使用过滤器，以降低LLM应用程序数据外泄的风险，或者实施检测技术（例如，数据丢失防护）来检测来自其他监控系统的提取活动。
  • 实施对抗性鲁棒性训练，以帮助检测提取查询并加强物理安全措施。
  • 在LLM的嵌入和检测阶段实施水印框架。
 

文章来源: https://www.cnblogs.com/LittleHann/p/17596696.html
如有侵权请联系:admin#unsafe.sh