当前位置：首页 > java >正文

OWASP TOP 10 2025

java 2025/5/3 12:25:20

LLM01:2025 提示注入

描述

提示注入漏洞发生在用户的提示信息意外地改变了大语言模型（LLM）的行为或输出。这种输入可能影响模型，即使它们对人类不可见或不可读，只要内容能被模型解释。这些漏洞源于模型处理提示的方式，可能导致数据处理错误，违反指导方针，生成有害内容，未经授权的访问或影响关键决策。虽然技术如检索增强生成（RAG）和模型微调可以提高准确性和相关性，但它们并不能完全解决提示注入漏洞。

提示注入和“破解”是LLM安全中相关但不同的概念。两者都通过特定输入影响模型响应。“破解”是一种提示注入，允许攻击者通过提供忽略安全协议的输入来绕过这些协议。开发人员可以防范提示注入，但防止破解需要对模型的训练和安全措施进行持续更新。

提示注入漏洞的类型

直接提示注入
- 当用户的提示直接以意想不到的方式改变模型的行为时发生。这可以是故意的（例如，用户设计一个提示来利用模型）或无意的（例如，用户提供的输入触发了意外行为）。
间接提示注入
- 当LLM处理来自外部来源（如网站或文件）的输入时发生。外部内容在被模型解释时可能产生影响。

预防和缓解策略

约束模型行为：
- 提供明确说明关于模型的角色和限制。
- 严格遵循上下文并将响应限制在特定任务内。
定义和验证预期输出格式：
- 指定输出格式并提供输出推理。
- 使用确定性代码确保格式的遵循。
实现输入和输出过滤：
- 定义敏感类别和内容处理规则。
- 应用语义过滤器和字符串检查以扫描不允许的内容。
- 使用RAG三元组（上下文相关性、扎根性和问答相关性）评估响应。
执行权限控制和最小权限访问：
- 应用程序应使用自己的API令牌进行功能，限制访问仅限于预期操作所需的最低限度。
要求对高风险操作进行人工批准：
- 实施人机交互控制以防止未经授权的操作。
隔离和识别外部内容：
- 清楚地分隔和标记不受信任的内容，以限制其对用户提示的影响。
进行对抗性测试和攻击模拟：
- 定期进行渗透测试和漏洞模拟，将模型视为不受信任的用户以测试信任边界和访问控制的有效性。

攻击场景示例

场景#1：直接注入：攻击者将提示注入客户支持聊天机器人，指示其忽略指导方针，查询私人数据存储并发送电子邮件，导致未经授权的访问和权限升级。
场景#2：间接注入：用户使用LLM总结网页，该网页包含隐藏指令，导致LLM插入链接到URL的图像，从而泄露私人对话。
场景#3：无意注入：公司在职位描述中包含识别AI生成应用程序的指令。申请人无意识地使用LLM优化简历，无意中触发AI检测。
场景#4：有意图的模型影响：攻击者修改RAG应用程序使用的文档。当用户的查询返回修改后的内容时，恶意指令改变LLM的输出，生成误导性结果。
场景#5：代码注入：攻击者利用LLM驱动的电子邮件助手中的漏洞（CVE-2024-5184）注入恶意提示，允许访问敏感信息和操纵电子邮件内容。
场景#6：负载拆分：攻击者上传带有拆分恶意提示的简历。当LLM用于评估候选人时，组合提示操纵模型的响应，导致正面推荐，尽管实际简历内容不当。
场景#7：多模态注入：攻击者在伴随良性文本的图像中嵌入恶意提示。

LLM02: 2025 敏感信息泄露

描述

敏感信息可能影响大语言模型（LLM）及其应用环境。这包括个人身份信息（PII）、财务细节、健康记录、机密商业数据、安全凭证和法律文件。专有模型可能还包含独特的训练方法和源代码，尤其是在封闭或基础模型中。

LLM在应用时，可能会通过输出暴露敏感数据、专有算法或机密细节。这可能导致未经授权的数据访问、隐私侵犯和知识产权泄露。消费者必须意识到无意间提供的敏感数据可能会在模型的输出中出现。

为了减少这种风险，LLM应用应确保足够的数据清理以防止用户数据进入训练模型。应用程序所有者还应提供明确的使用条款政策，允许用户选择不将其数据包括在训练模型中。通过在系统提示中实施关于LLM应返回的数据类型的限制可以帮助防止敏感信息泄露。然而，这些限制可能不会总是被遵守，并可能通过提示注入或其他技术被绕过。

常见漏洞示例

PII泄露：个人身份信息可能在与LLM的交互中泄露。
专有算法暴露：配置不当的模型输出可能揭示专有算法或数据。揭示训练数据可能暴露模型于反转攻击，攻击者可以提取敏感信息或重建输入。
敏感商业数据泄露：生成的响应可能无意中包含机密商业信息。

预防和缓解策略

数据清理技术整合：
- 实施方法以防止用户数据进入训练模型，通过清理或屏蔽敏感内容在训练前进行处理。
- 使用严格的验证方法检测和过滤潜在有害或敏感的数据输入，确保它们不会影响模型。
严格访问控制：
- 根据最低权限原则限制对敏感数据的访问，仅在必要时授予特定用户或流程。
- 限制模型访问外部数据源，确保安全的运行时数据编排以避免意外的数据泄露。
使用联邦学习和隐私技术：
- 使用分散数据存储在多个服务器或设备上训练模型，减少集中数据收集的需求并降低暴露风险。
- 应用技术添加噪声到数据或输出，使攻击者难以逆向工程单个数据点。
用户教育和透明度：
- 提供指导以安全使用LLM，避免输入敏感信息，并提供与大型语言模型（LLM）安全交互的最佳实践培训。
- 保持数据保留、使用和删除的透明政策，并允许用户选择不将其数据包括在训练过程中。
安全的系统配置：
- 确保系统前言被隐藏以防止未经授权的访问或信息暴露。

示例攻击场景

场景#1：无意的数据暴露：由于不充分的数据清理，用户收到包含他人个人数据的响应。
场景#2：有针对性的提示注入：攻击者绕过输入过滤器以提取敏感信息。
场景#3：通过训练数据泄露数据：由于数据疏忽，训练中包括了敏感信息导致其泄露。

LLM03: 2025 供应链

描述

供应链中的漏洞可能影响大语言模型（LLM）的训练数据、模型和部署平台的完整性，可能导致输出偏见、安全漏洞或系统故障。这些风险不仅限于传统软件漏洞，如代码缺陷和依赖关系，还扩展到第三方预训练模型和数据。这些外部元素易受篡改或中毒攻击。

LLM的创建通常涉及第三方模型，随着开放访问LLM的使用增加以及新的微调方法如LoRA（低秩适应）和PEFT（参数高效微调）的出现，尤其是在Hugging Face等平台上，引入了新的供应链风险。设备上的LLM的出现进一步增加了LLM应用的攻击面和供应链风险。

常见风险示例

传统第三方包漏洞：使用过时或废弃的组件，攻击者可以利用这些组件来破坏LLM应用。这类似于“A06:2021 - 易受攻击和过时的组件”，在模型开发或微调期间使用时风险增加。
许可风险：AI开发涉及多样的软件和数据集许可，如果管理不当会产生风险。不同的开源和专有许可施加不同的法律要求，可能限制使用、分发或商业化。
过时或废弃的模型：使用不再维护的过时或废弃模型可能导致安全问题。
易受攻击的预训练模型：这些模型通常是黑盒的，缺乏开源透明度，使得静态检查不足以确保安全性。模型可能存在隐藏的偏见、后门或恶意特征。
弱模型来源：发布的模型缺乏强大的来源保证，尽管模型卡和文档提供信息，但它们不保证模型的来源。
易受攻击的LoRA适配器：LoRA是一种增强模块化的微调技术，允许在现有LLM中集成预训练层。这种方法在协作模型环境中可能引入风险。
利用协作开发过程：协作模型合并和处理服务可能引入漏洞，尤其是在共享环境中。
设备上的LLM供应链漏洞：设备上的LLM扩展了供应攻击面，存在来自制造过程或设备操作系统漏洞的风险。
不明确的条款和数据隐私政策：模型运营商的不明确条款和隐私政策可能导致敏感数据暴露。

预防和缓解策略

审查数据来源和供应商：仔细审查数据来源和供应商，确保条款和条件以及隐私政策是明确的。仅使用受信任的供应商，并定期审查他们的安全状况。
应用OWASP Top Ten缓解措施：理解并应用OWASP Top Ten的“A06:2021 - 易受攻击和过时的组件”的缓解措施，以确保全面的安全措施。
漏洞和过时组件管理：强调在敏感数据环境中进行漏洞扫描、管理和补丁。
AI红队评估：在选择第三方模型时使用AI红队评估。
库存管理与SBOM：保持组件的准确库存。
AI许可风险：创建许可证使用的库存，进行定期审计。
模型验证和完整性：从可验证的来源获取模型，并应用第三方检查。
监控和审计：实施严格的监控和审计。
异常检测和鲁棒性测试：识别篡改和中毒。
补丁政策：实施补丁政策以防止漏洞。
模型加密和验证：在AI边缘加密模型。

示例攻击场景

场景#1：易受攻击的Python库：
- 描述了攻击者如何利用一个易受攻击的Python库来破坏LLM应用。这可能导致通过一个已知的PyTorch依赖进行数据泄露。
场景#2：直接篡改：
- 攻击者直接篡改模型以传播错误信息，绕过Hugging Face的安全功能，通过使用PoisonGPT改变模型参数。
场景#3：微调流行模型：
- 攻击者微调一个开放访问的模型以移除安全功能并专注于特定领域，例如保险。然后在Hugging Face上利用对基准保证的信任来进行攻击。
场景#4：预训练模型：
- 一个LLM系统使用未经适当验证的预训练模型，导致恶意代码引入和偏见输出，可能伤害或操纵结果。
场景#5：被破坏的第三方供应商：
- 一个第三方供应商提供了一个易受攻击的LoRA适配器，该适配器在Hugging Face上通过模型合并被集成到一个LLM中。
场景#6：供应商渗透：
- 一个渗透者破坏了供应商并改变了LLM的LoRA适配器生产。这一适配器一旦被集成，就为攻击者提供了一个隐蔽的入口点来操纵LLM的输出。
场景#7：云攻击：
- 这些攻击利用云基础设施中的漏洞。CloudBorne攻击针对固件漏洞，而CloudJacking涉及对云实例的未经授权的控制，威胁关键的LLM部署平台。
场景#8：LeftOvers (CVE-2023-4969)：
- 利用泄露的GPU内存从生产服务器和工作站中窃取敏感数据。
场景#9：WizardLIM：
- 在移除WizardLM后，攻击者使用一个包含恶意软件和后门的假版本进行攻击。

LLM04: 数据和模型中毒

描述：

数据中毒是一种操纵行为，发生在数据用于预训练、微调或嵌入阶段时，通过引入漏洞、后门或偏见来影响模型的安全性、性能或伦理行为。这种操纵可能导致有害输出或损害模型能力。常见风险包括模型性能下降、偏见或有害内容生成，以及下游系统被利用。

数据中毒可能影响大型语言模型（LLM）生命周期的各个阶段，包括预训练（从一般数据中学习）、微调（使模型适应特定任务）和嵌入（将文本转换为数值向量）。识别这些阶段有助于发现潜在的漏洞。这被视为完整性攻击，因为它涉及篡改训练数据，影响模型的预测能力。特别是当使用外部数据源时风险较高，因为这些可能包含未验证或恶意内容。

此外，通过存储库或开源平台共享的模型可能带来除数据中毒之外的风险。例如，这些模型可能包含通过恶意封装技术嵌入的恶意代码，当模型加载时执行。此外，中毒可能允许插入后门，在触发之前保持模型行为不变。这样的后门使得检测变化变得困难，从而为模型成为潜伏代理创造机会。

常见漏洞例子：

恶意行为者在训练阶段引入有害数据，导致偏见输出。技术如“分视图数据中毒”或“抢先中毒”利用模型训练动态实现这一目标。
- 参考链接：分视图数据中毒
- 参考链接：抢先中毒
攻击者可以在训练过程中直接注入有害内容，损害模型的输出质量。
用户在交互时无意中注入敏感或专有信息，这可能在后续输出中被泄露。

预防和缓解策略：

跟踪数据来源： 使用工具如OWASP CycloneDX或ML-BOM，在开发的各个阶段验证数据的合法性。
审查数据供应商： 严格检查供应商，验证模型输出是否来自可信来源，以检测数据中毒迹象。
实施沙盒技术： 限制模型暴露于未验证的数据源，并使用异常检测过滤对抗性数据。
为用例定制模型： 使用特定数据集进行微调，以确保输出准确符合目标。
基础设施控制： 确保控制到位，以防止意外的数据源访问。
使用数据版本控制（DVC）： 跟踪数据集中的变化，检测操纵，对于保持数据完整性至关重要。
向量数据库存储： 将用户提供的信息存储在向量数据库中，以便在不重新训练模型的情况下进行调整。
测试模型的鲁棒性： 使用红队运动和对抗技术，如联邦学习，减少数据扰动。
监控训练损失： 分析模型行为以发现中毒迹象，并使用阈值检测异常输出。
推理技术： 集成检索增强生成（RAG）和基础技术以减少幻觉风险。

攻击场景示例：

场景#1： 攻击者操纵训练数据或使用提示注入技术影响模型输出，传播错误信息。
场景#2： 缺乏适当的数据过滤可能导致有害或偏见输出，传播危险信息。
场景#3： 恶意行为者或竞争者创建用于训练的伪造文档，导致模型输出不准确。
场景#4： 不充分的过滤允许攻击者通过提示注入插入误导性数据，导致输出被破坏。

LLM05:2025 不当输出处理

描述：

不当输出处理是指在将大型语言模型（LLM）的输出传递给其他系统和组件之前，缺乏适当的验证、清理和管理。LLM生成的内容可以通过提示输入进行控制，类似于间接授予用户额外功能访问权限。这种漏洞与过度依赖不同，重点关注输出传递给下游之前出现的问题，并强调对LLM准确性和适当性的过度依赖。

不当输出处理的利用可能导致跨站脚本攻击（XSS）、跨站请求伪造（CSRF）、权限提升或在Web浏览器和后端系统中进行远程代码执行。

增加漏洞影响的因素：

应用程序授予LLM超出预期终端用户能力的权限，可能导致权限提升或远程代码执行。
易受间接提示注入攻击，允许攻击者获得用户环境的特权访问。
第三方扩展缺乏输入的适当验证。
缺乏对不同上下文（例如HTML、JavaScript、SQL）输出的正确编码。
对LLM输出的监控和日志记录不足。
缺乏对LLM使用的速率限制或异常检测。

常见漏洞例子：

LLM输出直接在系统shell或类似功能中执行，导致远程代码执行。
LLM生成的JavaScript或Markdown返回给用户，并由浏览器解释，导致XSS。
LLM生成的SQL查询未经参数化执行，导致SQL注入。
LLM输出在文件路径中使用而未适当清理，可能导致路径遍历漏洞。
LLM生成的电子邮件模板中的内容缺乏适当的转义，可能导致潜在漏洞。

预防和缓解策略：

采用零信任原则，将模型视为任何其他用户，应用对模型响应进行适当的输入验证。
遵循OWASP ASVS指南确保有效的输入验证和清理。
对返回给用户的模型输出进行编码，以减少JavaScript或Markdown引发的代码执行风险，OWASP ASVS提供了关于输出编码的详细指导。
根据LLM输出使用场景实施上下文感知的输出编码，例如对Web内容进行HTML编码，对数据库查询进行SQL转义。
对所有涉及LLM输出的数据库操作使用参数化查询或预准备语句。
实施严格的内容安全策略（CSP），以减少LLM生成内容的XSS攻击风险。
建立强大的日志记录和监控系统，以检测LLM输出中的异常模式，指示潜在的利用尝试。

攻击场景示例：

场景#1： 应用程序使用LLM扩展进行聊天机器人响应，同时提供其他特权LLM可访问的管理功能。由于缺乏适当的输出验证，通用LLM可能通过其响应导致扩展关闭进行维护。
场景#2： 用户使用由LLM驱动的网站摘要工具生成文章摘要。网站包含提示注入，指示LLM捕获网站或用户会话中的敏感内容并在未验证情况下编码，将其发送到攻击者控制的服务器。
场景#3： LLM允许用户通过聊天功能为后端数据库创建SQL查询。用户请求删除所有数据库表的查询，如果LLM生成的查询未经审查，所有数据库表可能会被删除。
场景#4： Web应用程序使用LLM从用户文本提示生成内容而未进行输出清理。攻击者可能提交一个精心构造的提示导致LLM返回未清理的JavaScript负载，当在受害者浏览器中呈现时导致XSS。提示缺乏充分验证使得此攻击成为可能。

LLM06:2025 过度代理

描述：

基于大型语言模型（LLM）的系统通常被开发者赋予一定程度的代理能力，使其能够通过扩展调用功能或与其他系统接口。这些扩展可能被称为工具、技能或插件，由不同供应商提供，允许系统根据提示采取行动。选择使用哪个扩展可能会被委派给LLM“代理”，该代理根据输入提示或LLM输出进行决策。基于代理的系统通常会重复调用LLM，使用先前调用的输出来指导和指引后续行动。

过度代理是一种漏洞，允许在响应意外、模糊或被操纵的LLM输出时进行有害行为。这种情况的发生与导致LLM故障的原因无关。

常见触发因素：

因工程不佳的良性提示或性能不佳的模型导致的幻觉或虚构。
来自恶意用户的直接或间接提示注入、先前调用的恶意或被损坏的扩展，或在多代理/协作系统中，恶意或被损坏的对等代理。

过度代理的根本原因通常涉及以下一个或多个因素：

过度的功能
过度的权限
过度的自主性

过度代理可能会对机密性、完整性和可用性产生广泛影响，具体取决于LLM应用程序可以与哪些系统交互。

注意：
过度代理与不安全输出处理不同，后者涉及对LLM输出缺乏足够的审查。

常见风险例子：

过度功能：扩展可能保留不再需要的功能，导致潜在的误用。例如，为特定shell命令设计的扩展可能无法限制其他命令。
过度权限：扩展可能拥有超过要求的权限，例如数据库扩展能够执行超出读取的操作，如UPDATE、INSERT和DELETE。
过度自主性：扩展可能在未经用户确认的情况下独立执行高影响的操作，例如删除用户文件。

预防和缓解策略：

限制扩展数量：限制LLM代理可以访问的扩展，仅限于必要功能。如果不需要获取URL内容的能力，则不应提供该扩展。
限制扩展功能：限制LLM扩展中的功能至最低必要。例如，如果扩展旨在读取邮件，则不应包括删除或发送邮件的功能。
避免开放式扩展：避免使用具有广泛和未定义功能的扩展。
在用户上下文中执行扩展：必须跟踪用户授权和安全范围，以确保动作在必要权限下执行。LLM扩展访问用户代码库时应通过OAuth进行用户认证。
需要用户批准：对高影响的操作实施人工审核控制，要求用户批准。这可以在LLM扩展或下游系统中进行。
完整的中介：在下游系统中实施授权以验证动作是否符合安全政策。
清理LLM输入和输出：遵循安全编码最佳实践，如OWASP推荐，尤其是输入清理。使用静态和动态应用安全测试（SAST和DAST）在开发管道中进行。
记录和监控LLM扩展活动：以识别和响应不良行为。
实施速率限制：减少在给定时间内的不良行为数量，允许早期检测和预防。

攻击场景示例：

场景#1： LLM个人助理应用通过扩展访问用户邮箱以总结电子邮件内容。该扩展不仅需要读取功能，还包括发送消息的功能，使其易受间接提示注入攻击。恶意邮件指示应用搜索敏感信息并将其发送到攻击者的邮箱。
- 缓解措施： 通过使用仅限于邮件读取功能的扩展消除过度功能，通过OAuth进行读取会话认证减少过度权限，并要求手动审查和批准每封扩展草拟的邮件。

LLM07:2025 系统提示泄露

描述：

系统提示泄露是指大型语言模型（LLM）中的系统提示或指令可能包含不应泄露的敏感信息。系统提示用于根据应用需求调整模型的行为，但可能无意中包含需要保密的细节。如果这些细节被发现，可能会为进一步的攻击提供便利。系统提示不应被视为秘密或用作安全控制措施，敏感数据如凭证或连接字符串不应嵌入系统提示中。

泄露系统提示本身并不是最大的风险，风险在于信息泄露、绕过防护措施和不当的权限分离。即便具体措辞没有被揭示，攻击者也可能推断出系统提示语言中嵌入的限制或防护措施，从而导致系统漏洞。

常见风险例子：

敏感功能暴露：系统提示可能泄露系统架构细节、API密钥、数据库凭证或用户令牌等敏感信息，攻击者可能利用这些信息进行未经授权的访问。
内部规则暴露：系统提示泄露决策过程可能帮助攻击者发现应用弱点或绕过控制。
过滤标准泄露：系统提示可能透露用于过滤或拒绝敏感内容的标准。
权限和用户角色披露：系统提示可能泄露内部角色结构或权限级别。

预防和缓解策略：

从系统提示中分离敏感数据：避免在系统提示中直接嵌入敏感信息，使用外部系统来存储这些信息，确保模型无法直接访问。
避免依赖系统提示进行严格行为控制：由于LLM可能易受提示注入攻击，建议使用外部系统来管理行为。
实施防护措施：在LLM之外建立防护措施以确保遵循预期。虽然训练模型不透露系统提示是有益的，但独立的系统更适合验证指令遵循情况。
确保安全控制独立于LLM进行：关键控制如权限分离和授权检查应独立于LLM进行，以保证安全完整性。

攻击场景示例：

场景#1： LLM的系统提示包含工具的凭证集，这些凭证被泄露给攻击者，攻击者利用这些凭证进行未经授权的操作。
场景#2： LLM的系统提示禁止生成攻击性内容、外部链接和代码执行，但攻击者通过提取系统提示并进行提示注入攻击来绕过这些限制，进行远程代码执行攻击。

LLM08:2025 向量和嵌入弱点

描述：

矢量和嵌入的漏洞在使用检索增强生成（RAG）与大型语言模型（LLM）的系统中带来了显著的安全挑战。在矢量和嵌入的生成、存储或检索中存在的弱点可能被恶意行为利用，无论是故意或无意的，来注入有害内容、操纵模型输出或访问敏感信息。

检索增强生成（RAG）是一种模型适应技术，旨在通过将预训练的语言模型与外部知识源结合来提高LLM应用的响应性能和上下文相关性。此增强利用矢量机制和嵌入。

常见风险示例：

未经授权访问和数据泄漏：
- 不充分或不协调的访问控制可能导致未经授权访问包含敏感信息的嵌入。没有适当的管理，模型可能会检索并泄露个人数据、专有信息或其他敏感内容。在增强过程中未经授权使用受版权保护的材料或不遵守数据使用政策可能导致法律后果。
跨上下文信息泄漏和联邦知识冲突：
- 在多租户环境中，多个用户或应用程序类共享同一矢量数据库，用户或查询之间的上下文泄漏构成风险。当来自多个源的数据互相矛盾时，会发生数据联邦知识冲突错误。这也可能发生在LLM无法用检索增强过程中新的数据替换旧知识时。
嵌入反转攻击：
- 攻击者可以利用漏洞反转嵌入并恢复大量来源信息，危及数据机密性。
数据中毒攻击：
- 数据中毒可能由恶意行为者故意或无意地发生。中毒数据可能来源于内部人员、提示、数据播种或未经验证的数据。
行为改变
- 检索增强可能会在不经意间改变基础模型的行为。例如，虽然事实准确性和相关性可能会提高，但诸如情商或同理心等方面可能会降低，这有可能会降低该模型在某些应用中的效能。

预防和缓解策略：

权限和访问控制：
- 实施细粒度的访问控制和权限感知的矢量和嵌入存储。确保在矢量数据库中严格的逻辑和访问分区，以防止不同用户或群体之间的未经授权访问。
数据验证和来源认证：
- 实施知识源的稳健数据验证管道。定期审计和验证知识库的完整性以查找隐藏代码和数据中毒。仅接受来自可信且经过验证的来源的数据。
组合和分类的数据审查：
- 在组合不同来源的数据时，彻底审查组合的数据集。在知识库中标记和分类数据，以控制访问级别并防止数据不匹配错误。
监控和日志记录：
- 保持检索活动的详细不可变日志，以检测和及时响应可疑行为。

示例攻击场景：

场景 1：数据中毒

攻击者创建一份包含隐藏文字的简历，如白色背景上的白色文字。然后将此简历提交给使用检索增强生成（RAG）进行初步筛选的求职系统。系统处理简历，包括隐藏文字。当系统稍后被查询关于候选人资格时，LLM遵循隐藏指令，导致推荐一个不合格的候选人进行进一步考虑。
缓解措施： 为防止这种情况，应实施忽略格式化并检测隐藏内容的文本提取工具。此外，所有输入文档在添加到RAG知识库之前必须经过验证。

LLM09:2025 错误信息

描述：

语言模型（LLM）中的错误信息是依赖这些模型的应用程序的一项重大漏洞。当LLM产生看似可信的错误或误导信息时，可能导致安全漏洞、声誉损害和法律责任。

错误信息的一个主要原因是幻觉，即LLM生成的内容看似准确但实际上不正确。幻觉发生在LLM使用统计模式填补其训练数据中的空白而不理解内容时，导致错误但似乎合乎逻辑的答案。尽管幻觉是错误信息的一个重要来源，其他因素还包括训练数据中的偏见和信息不完整。

过度依赖也是一个问题，发生在用户对LLM生成的内容给予过多信任而不验证其准确性时。这可能导致将错误数据整合到关键决策或流程中。

常见风险示例：

事实错误：
- 模型可能产生不正确的陈述，使用户基于错误信息做出决策。例如，加拿大航空公司的聊天机器人向旅客提供错误信息，导致运营中断和法律问题。航空公司因此面临成功的诉讼。
- 参考链接：BBC
无根据的断言：
- 模型可能做出无根据的声明，在医疗保健或法律程序等敏感领域可能造成危害。例如，ChatGPT在法律案件中捏造信息，导致法庭上的重大问题。
- 参考链接：LegalDive
专业知识的误导表现：
- 模型可能给人以理解复杂主题的假象，误导用户关于其专业知识的程度。

预防和缓解策略：

检索增强生成（RAG）：
- 使用检索增强生成，通过从可信外部数据库检索相关和经过验证的信息来增强模型输出的可靠性。这有助于减少幻觉和错误信息的风险。
模型微调：
- 通过微调或嵌入来增强模型以提高输出质量。参数高效调优（PET）和思维链提示等技术有助于减少错误信息的发生。
交叉验证和人工监督：
- 鼓励用户使用可信外部来源交叉核对LLM输出以确保准确性。实施人工监督和事实检查流程，对于敏感信息尤其重要。确保人工审核员经过适当培训以避免对AI生成内容的过度依赖。
自动验证机制：
- 应实施工具和流程以自动验证关键输出，特别是在高风险环境中。
风险沟通：
- 识别并向用户传达与LLM生成内容相关的风险和可能的危害，包括错误信息的潜力。
安全编码实践：
- 建立安全编码实践以防止因错误代码建议而导致的集成漏洞。
用户界面设计：
- 设计鼓励负责任使用LLM的API和用户界面。这包括集成内容过滤器、明确标记AI生成内容，并告知用户可靠性和准确性限制。
培训和教育：
- 为用户提供关于LLM的局限性、独立验证生成内容的重要性和批判性思维的全面培训。

示例攻击场景：

场景 1：
攻击者使用流行的编码助手寻找常见的幻觉包名称。一旦识别出这些不存在的库，他们就会将这些名称的恶意包发布到广泛使用的存储库。开发人员信任编码助手的建议，将这些恶意包集成到他们的软件中，导致未经授权的访问、代码注入或安全漏洞。
场景 2：
公司提供医疗诊断聊天机器人而不确保准确性，导致患者获得错误信息和有害后果。公司因此面临损害赔偿诉讼。此场景强调了由于对LLM系统监督不足导致的安全失效，尽管没有攻击者的主动参与，也构成声誉和财务风险。

LLM10:2025 无限制消耗

描述：

不受限制的消费描述了大型语言模型（LLM）基于输入查询或提示生成输出的过程。当LLM应用允许过度和不受控制的推断时，可能导致拒绝服务（DoS）、经济损失、模型盗窃和服务降级等风险。LLM的高计算需求，尤其是在云环境中，使其容易受到资源利用和未经授权使用的攻击。

常见风险示例：

可变长度输入洪水：
- 攻击者可以通过大量不同长度的输入使LLM过载，利用处理效率低下。这可能耗尽资源并可能使系统无响应，对服务可用性产生重大影响。
钱包拒绝服务（DoW）：
- 通过发起大量操作，攻击者利用基于使用量的云AI服务成本模型，导致提供商承担不可持续的财务负担，面临财务破产风险。
持续输入溢出：
- 不断地发送超过LLM上下文窗口的输入可能导致过度的计算资源使用，导致服务降级和运营中断。
资源密集型查询：
- 提交涉及复杂序列或复杂语言模式的异常要求的查询可能会耗尽系统资源，导致处理时间延长和潜在的系统故障。
通过API进行模型提取：
- 攻击者可能使用精心设计的输入和提示注入技术查询模型API。
功能模型复制：
- 攻击者可以通过使用目标模型生成合成训练数据来复制模型。这对专有模型和技术构成风险，因为它允许攻击者微调另一个基础模型，绕过传统的提取方法。
侧信道攻击：
- 攻击者可能利用LLM中的输入过滤技术执行侧信道攻击，从而收集模型权重和架构信息。这可能会破坏模型的安全性并导致进一步的利用。

防御措施：

输入验证：
- 实施严格的输入验证以确保输入不超过合理的大小限制。
限制暴露的logits和logprobs：
- 限制或混淆API响应中的“logit_bias”和“logprobs”的暴露，以保护概率不被泄露。
速率限制：
- 应用速率限制和用户配额以限制单个来源在一定时间内的请求数量。
资源分配管理：
- 动态监控和管理资源分配，以防止任何单个用户或请求消耗过多资源。
超时和节流：
- 为资源密集型操作设置超时并限制处理，以有效管理资源消耗。
沙箱技术：
- 限制LLM对网络、服务和API的访问。这项技术对于防止内部风险和威胁至关重要，管理LLM对数据和资源的访问范围，并缓解或防止侧信道攻击。
全面的日志记录、监控和异常检测：
- 持续监控资源使用情况，并实施日志记录以检测和响应异常的资源消耗模式。
水印技术：
- 实施水印框架以嵌入和检测LLM输出的未经授权使用。
优雅降级：
- 确保系统能够在压力或攻击下优雅降级以保持基本功能。
限制排队的动作和规模稳健性：
- 实施限制并使用动态扩展和负载平衡来有效管理系统需求。
对抗性鲁棒性训练：
- 训练模型识别和减轻对抗性查询和提取尝试。
故障令牌过滤：
- 编译已知故障令牌列表并扫描输出以防止它们进入模型上下文。
访问控制：
- 使用强访问控制，如基于角色的访问控制（RBAC），以防止未经授权访问模型存储库和训练环境。
集中式ML模型库存：
- 维护用于生产的模型的集中注册表以确保治理和访问控制。
自动化MLOps部署：
- 实施自动化的MLOps，具有治理、跟踪和批准工作流，以收紧访问和部署控制。