7月15日之前入驻华为云，可参与Check抽奖活动，抽奖活动在文末

1. 《OWASP 大模型应用最常见的10个关键安全问题》项目简介（OWASP TOP10 LLMs Project）

*OWASP Top 10 for Large Language Model Applications

OWASP 大模型应用程序 Top 10 项目旨在向开发人员、设计人员、架构师、经理和组织介绍部署和管理大型语言模型（LLM）时的潜在安全风险。该项目提供了LLM应用程序中常见的10大最关键漏洞的列表，突出了它们的潜在影响，易于利用以及在实际应用程序中的普遍性。漏洞的示例包括提示注入、数据泄漏、沙盒不足和未经授权的代码执行等。目标是提高对这些漏洞的认识，建议修正策略，并最终改善LLM应用程序的安全状况。

本文主要参照目前最新的版本:《OWASP Top 10 for Large Language Models (0.5)》翻译整理。

OWASP LLMs TOP10 示意图

2. LLM01: 提示注入（Prompt Injections）

LLMs 中的提示注入漏洞涉及狡猾的输入，导致未检测到的操作。影响范围从数据暴露到未经授权的操作，以及为攻击者的目标服务。

当攻击者通过多个通道使用构建的输入提示操纵受信任的大型语言模型（LLM）时，就会发生提示注入漏洞。由于对LLM输出的固有信任，这种操作通常未被发现。

存在两种类型：直接（攻击者影响 LLM 的输入）和间接（“中毒”数据源影响 LLM）。

结果的范围可以从暴露敏感信息到影响决策。在复杂的情况下，LLM可能会被诱骗到未经授权的操作或冒充中，有效地服务于攻击者的目标，而不会提醒用户或触发保护措施。

2.1. 预防措施

权限控制
将LLM的权限限制为其功能所需的最低权限。防止 LLM 在未经明确批准的情况下更改用户的状态。
增强的输入验证
实施可靠的输入验证和清理方法，以过滤掉来自不受信任来源的潜在恶意提示输入。
外部内容交互的隔离和控制
将不受信任的内容与用户提示隔离开来，并控制与外部内容的交互，尤其是与可能导致不可逆转的操作或暴露个人身份信息（PII）的插件的交互。
信任管理
在LLM，外部源和可扩展功能（例如，插件或下游函数）之间建立信任边界。将LLM视为不受信任的用户，并保持最终用户对决策过程的控制。

3. LLM02: 不安全输出（Insecure Output Handling）

当插件或应用程序接受LLM输出时，如果缺少安全控制就可能导致 XSS、CSRF、SSRF、权限提升、远程代码执行，并可能启用代理劫持攻击。

不安全输出处理漏洞是一种提示注入漏洞，当插件或应用程序在没有适当审查的情况下盲目接受大型语言模型（LLM）输出并将其直接传递给后端、特权或客户端函数时，就会出现该漏洞。由于LLM生成的内容可以通过提示输入来控制，因此此行为类似于为用户提供对附加功能的间接访问。

成功利用不安全输出处理漏洞可导致 Web 浏览器中出现 XSS 和 CSRF，以及后端系统上的 SSRF、权限提升或远程代码执行。当应用程序允许 LLM 内容执行超出预期用户权限的操作时，此漏洞的影响会增加。此外，这可以与代理劫持攻击结合使用，以允许攻击者以特权访问目标用户的环境。

3.1. 预防措施

将模型视为任何其他用户，并对从模型到后端函数的响应应用适当的输入验证;
将来自模型的输出进行编码，以减少不需要的JavaScript或Markdown代码解释。

4. LLM03: 训练数据投毒（Training Data Poisoning）

LLM从不同的文本中学习，但有训练数据中毒的风险，导致用户错误信息。

大型语言模型（LLM）使用不同的原始文本来学习和生成输出。攻击者引入漏洞的训练数据中毒可能会破坏模型，使用户接触到不正确的信息。LLM的OWASP列表强调了过度依赖AI内容的风险。关键数据源包括用于 T5 和 GPT-3 等模型的Common Crawl、WebText 和 OpenWebText，包含公共新闻和维基百科和书籍，占 GPT-16 训练数据的 3%。

4.1. 预防措施

验证培训数据的供应链（如果来自外部）并保持证明，类似于 SBOM（软件物料清单）方法;
- 验证数据源和其中数据的合法性;
- 通过针对不同用例的单独训练数据制作不同的模型，以创建更精细、更准确的生成AI输出;
- 确保存在足够的沙盒，以防止模型抓取意外数据源;
- 对特定训练数据或数据源类别使用严格的审查或输入过滤器来控制伪造数据的数量;
- 实施专门的LLM来衡量不良后果，并使用强化学习技术培训其他LLM;
- 在LLM生命周期的测试阶段执行基于LLM的红队练习或LLM漏洞扫描。

5. LLM04: 拒绝服务（Denial of Service）

攻击者以特别消耗资源的方式与LLM交互，导致他们和其他用户的服务质量下降，或产生高资源成本。

5.1. 预防措施

限制每个请求的资源使用量;
限制每个步骤的资源使用，以便涉及复杂部分的请求执行速度;
限制系统中对LLM响应做出反应的排队操作数和总操作数。

6. LLM05: 供应链安全（Supply Chain）

由于漏洞导致偏见，安全漏洞或系统故障，LLM供应链存在完整性风险。问题来自预先训练的模型、众包数据和插件扩展。

LLM 中的供应链可能容易受到攻击，影响训练数据、ML 模型、部署平台的完整性，并导致有偏见的结果、安全漏洞或完整的系统故障。传统上，漏洞集中在软件组件上，但由于迁移学习、重用预训练模型以及众包数据的普及，漏洞在人工智能中得到了扩展。在公共LLM中，诸如OpenGPT扩展插件之类的LLM也是易受此漏洞影响的领域。

6.1. 预防措施

仔细审查来源和供应商;
对组件进行漏洞扫描，不仅在部署到生产环境时，而且在用于开发和测试之前;
模型开发环境使用自己的精选包存储库进行漏洞检查;
代码签名;
对提供服务的整个链路进行稳健性测试，防止对模型和数据，以及整个 MLOps 管道的篡改和投毒;
实施对抗性稳健性训练，以帮助检测提取查询;
审查和监控供应商安全和访问;
审计。

7. LLM06: 权限问题（Permission Issues）

插件之间缺乏授权跟踪可能会使间接提示注入或恶意插件使用成为可能，从而导致权限提升、机密性丢失和潜在的远程代码执行。

插件之间不跟踪授权，允许恶意行为者通过间接提示注入、使用恶意插件或其他方法在 LLM 用户的上下文中采取行动。这可能会导致权限提升、机密性丢失，甚至远程代码执行，具体取决于可用的插件。

7.1. 预防措施

需要手动授权敏感插件执行的任何操作;
每个用户输入调用不超过一个插件，在调用之间重置任何插件提供的数据;
防止在任何其他插件之后调用敏感插件;
对所有插件内容执行污点跟踪，确保调用插件的授权级别对应于向 LLM 提示符提供输入的任何插件的最低授权。

8. LLM07: 数据泄露（Data Leakage）

LLM中的数据泄漏可能会暴露敏感信息或专有详细信息，从而导致隐私和安全漏洞。适当的数据清理和明确的使用条款对于预防至关重要。

当LLM通过其响应意外泄露敏感信息，专有算法或其他机密细节时，就会发生数据泄漏。这可能会导致未经授权访问敏感数据或知识产权、侵犯隐私和其他安全漏洞。重要的是要注意，LLM应用程序的用户应该了解如何与LLM交互，并确定他们如何无意中输入敏感数据的风险。
反之亦然，LLM 应用程序应执行足够的数据清理和清理验证，以帮助防止用户数据进入训练模型数据。此外，托管LLM的公司应提供适当的用户条款政策，以使用户了解如何处理数据。

8.1. 预防措施

集成适当的数据清理和清理技术，以防止用户数据进入训练模型数据;
实施强大的输入验证和清理方法，以识别和过滤掉潜在的恶意输入;
通过 SAST（静态应用程序安全测试）和 SBOM（软件物料清单）证明等技术，保持持续的供应链风险缓解，以识别和修复第三方软件或软件包依赖项中的漏洞;
实施专门的LLM以针对不良后果进行基准测试，并使用强化学习技术培训其他LLM;
在LLM生命周期的测试阶段执行基于LLM的红队练习或LLM漏洞扫描。

9. LLM08: 过度代理（Excessive Agency）

当LLM与其他系统接口时，不受限制的代理可能会导致不良的操作和操作。像网络应用程序一样，LLM不应该自我监管, 控件必须嵌入到 API 中。

LLM可以被授予一定程度的代理权 - 与其他系统接口以采取行动的能力。LLM的任何不受限制的不良操作（无论根源原因如何，例如，幻觉，直接/间接提示注射，或只是设计不良的良性提示等）都可能导致采取不希望的行动。就像我们从不信任 Web 应用程序中的客户端验证一样，LLM 不应该被信任来自我监管或自我限制，控件应嵌入到所连接系统的 API 中。

9.1. 预防措施

将授予 LMM 的权限减少到限制不良操作范围所需的最小值;
实施速率限制以减少不良操作的数量;
利用人机交互控制，要求人工在执行所有操作之前批准所有操作。

10. LLM09: 过度依赖LLM生成的内容（Overreliance）

过度依赖LLM会导致错误信息或由于“幻觉”而导致的不当内容。如果没有适当的监督，这可能会导致法律问题和声誉损害。

过度依赖LLM是一个安全漏洞，当系统过度依赖LLM进行决策或内容生成而没有足够的监督，验证机制或风险沟通时，就会出现这种漏洞。LLM虽然能够产生创造性和信息丰富的内容，但也容易受到“幻觉”的影响，产生事实上不正确，荒谬或不适当的内容。如果不经过检查，这些幻觉可能导致错误信息、沟通不畅、潜在的法律问题以及对公司声誉产生影响。