# AI应用安全 - 训练阶段

> 来源: AISS绿盟大模型安全智链社区 | 拆自 ai-app-security.md
> 阶段: 训练阶段（GAARM.0034-0036 第三方组件/插件/不安全代码）

## 训练阶段

### LLMs应用不安全输出处理

> 风险编号: GAARM.0035.003
> 生命周期: 训练阶段

**攻击概述**

该风险是指当下游组件在接受大型语言模型 (LLM) 输出却未进行适当审查时，导致出现出现的一种安全风险。模型下游组件中包括各种功能的Agent，当缺乏相关的输出处理，会导致攻击者通过模型滥用Agent实现攻击行为，例如，攻击者可以通过输入特定的文本，诱导LLM输出包含敏感信息的响应，从而窃取用户数据，或者直接输出非预期的攻击Payload，导致下游出现RCE、SSRF等漏洞。

**攻击案例**

案例
描述




案例一
CVE-2023-29374 是 Langchain 的一个任意代码执行漏洞，使用 0.0.131 及之前版本的 Langchain，并调用 Langchain LLMMathChain 链的程序，存在包含任意命令执行的安全风险，可能导致 OpenAI key 等敏感信息泄漏、Langchain 服务端被控等问题。


案例二
Auto-GPT在v0.4.3之前版本中存在路径遍历漏洞，这个漏洞会导致运行Auto-GPT的主机上任意代码在docker环境之外执行。攻击者可利用该漏洞对目标有针对性的发起攻击，危害站点系统安全

**攻击风险**

敏感信息泄露：LLM 有时不会在其响应中清理 JavaScript。在这种情况下，攻击者可能会使用精心设计的Prompt导致 LLM 返回 JavaScript 有效负载，当受害者的浏览器解析该有效负载时，会受到攻击导致敏感信息泄露，如对话历史泄露等。
任意代码执行：攻击者可以通过漏洞执行任意代码。这可能导致攻击者在服务器上执行恶意操作，例如植入后门、提取敏感数据或中断服务。
定向

**缓解措施**

缓解方式
描述




零信任框架
在此框架中，每个访问资源的请求都被视为来自不受信任的网络，系统会对其进行检查、身份验证和核实，以此带来系统安全


沙盒环境
尝试利用沙盒环境来执行代码，以确保更大的系统安全。例如，仅在专用的临时 Docker 容器内执行代码可以显著限制恶意代码的潜在影响

**参考**

https://genai.owasp.org/wp-content/uploads/2024/05/OWASP-Top-10-for-LLM-Applications-v1_1_Chinese.pdf
https://cloud.baidu.com/article/3253170
https://www.akto.io/blog/insecure-output-handling-in-llms-insights
https://journal.hexmos.com/insecure-output-handling/
https://systemweakness.com/new-prompt-injection-attack-on-chatgpt-web-version-ef717492c5c2

---
### LLMs应用传统漏洞风险

> 风险编号: GAARM.0035.002
> 生命周期: 训练阶段

**攻击概述**

传统的应用安全漏洞不仅存在于传统软件系统中，也可能存在于LLM应用程序当中。例如，常见API接口攻击，账户接管，代码执行等，传统的风险漏洞仍然在LLM中存在，因此在训练阶段必须严格遵循安全最佳实践，以确保系统在应对传统风险的时候有足够的防护能力，否则可能会导致服务中断、账户接管、数据篡改等一系列危险。

**攻击案例**

案例
描述




案例一
案例报导了ChatGPT受到DDoS（分布式拒绝服务）攻击的迹象，外部攻击者试图通过反复发送Ping请求，从而使网络或服务器超载而崩溃


案例二
ChatGPT-Next-Web应用程序存在SSRF漏洞(CVE-2023-49785),可以使用此漏洞探测内网网络资源

**攻击风险**

服务中断：拒绝服务攻击（DoS）或资源耗尽会导致LLM应用无法响应用户请求，影响业务连续性。
系统控制：远程代码执行或脚本执行漏洞可能使攻击者接管服务器，植入恶意软件或执行破坏性操作。

**缓解措施**

缓解方式
描述




强化API安全
确保所有API接口都经过严格的身份验证和授权控制，限制访问权限。


最小权限原则
限制或禁用LLM应用中不必要的命令执行功能，减少潜在攻击面。


定期安全评估
定期对LLM应用进行安全漏洞扫描，及时修补发现的安全问题。

**参考**

https://sec.cafe/handbook/security_research/ai_security/llm_security/attack/

---
### LLMs插件：不安全输入处理

> 风险编号: GAARM.0035.001
> 生命周期: 训练阶段

**攻击概述**

该风险是指由于LLMs的插件存在不安全输入处理，将风险引入到大模型中。例如，插件很可能会从模型中实现来自模型的自由文本输入，而不进行验证或类型检查以处理上下文大小限制，使得潜在攻击者可以构造一个恶意请求发送给插件，可能导致各种不希望发生的行为，甚至包括远程代码执行。

**攻击案例**

案例
描述




案例一
LangChains中的PALChain被发现存在代码执行风险

**攻击风险**

未经授权的请求执行：攻击者可以直接利用LLMs应用漏洞或者通过操纵输入提示，使LLMs应用执行意外的请求，访问或操作受限制的资源。
敏感信息泄露：通过LLMs访问受限资源可能导致敏感信息的未经授权的获取和泄露。

**缓解措施**

缓解方式
描述




输入验证和过滤
实施严格的输入验证和净化策略，以确保所有输入数据在被LLMs处理前都经过检查和清理


最小权限原则
遵循最小权限原则，只为LLMs提供完成其任务所必需的最小访问权限，避免过度授权

**参考**

https://owasp.org/www-project-top-10-for-large-language-model-applications/Archive/0_1_vulns/SSRF.html
https://www.horizon3.ai/attack-research/attack-blogs/nextchat-an-ai-chatbot-that-lets-you-talk-to-anyone-you-want-to/
https://genai.owasp.org/wp-content/uploads/2024/05/OWASP-Top-10-for-LLM-Applications-v1_1_Chinese.pdf

---
### LLMs插件：业务过度代理

> 风险编号: GAARM.0036
> 生命周期: 训练阶段

**攻击概述**

基于LLM的系统通常由开发人员授予一定程度的业务代理能力，即与其他系统进行交互并在响应提示时执行操作的能力。而过度代理是设计开发阶段安全风险，该风险导致在LLM出现意外/模糊输出时执行破坏性操作，根本原因通常是：功能过多或自主权过多。过度代理可以导致涉及机密性、完整性和可用性等方面的一系列影响，这取决于LLM应用程序能够与哪些系统进行交互。例如，赋予了LLM系统过度自主权，导致LLM基于应用程序或插件未能独立验证和批准高影响操作时，允许删除用户文档的插件执行删除操作时，无需用户的任何确认。

**攻击案例**

案例
描述




案例一
该视频展示了如何通过利用过度代理的漏洞进行对用户密码的非法重置

**攻击风险**

敏感信息泄露：业务过度代理导致LLM被恶意操控时可能泄露敏感信息以及隐私。

**缓解措施**

缓解方式
描述




最小权限原则
限制LLM代理被允许调用的插件/工具，仅限于所需的最小功能。例如，如果LLM基础系统不需要获取URL内容的能力，那么不应该向LLM代理提供这样的插件


避免开放式功能
在可能的情况下避免开放式功能（例如运行shell命令、获取URL等），并使用更细粒度功能的插件/工具。例如，LLM基础应用程序可能需要将某些输出写入文件。如果使用插件运行shell功能来实现这一点，那么不希望的操作的范围就会非常大（可以执行任何其他shell命令）。更安全的替代方案是构建一个只支持特定功能的文件写入插件。

**参考**

https://genai.owasp.org/wp-content/uploads/2024/05/OWASP-Top-10-for-LLM-Applications-v1_1_Chinese.pdf

---
### RAG开发框架漏洞

> 风险编号: GAARM.0034.002
> 生命周期: 训练阶段

**攻击概述**

RAG（Retrieval-Augmented Generation）是结合信息检索和生成的框架，在大型语言模型（LLM）的开发中用于增强模型的生成能力。由于RAG框架依赖于检索模块从外部数据源获取信息，如果检索模块的源数据不准确或不可靠，可能导致生成的回答包含错误或误导性信息；并且框架本身引入的各种Agent，也可能存在相关的安全风险。RAG框架相关的安全风险主要集中于RAG的生成模块、信息检索模块、集成插件和外部接口等方面，由于对RAG设计的不安全，导致可能引入其中的安全漏洞到LLM应用。例如，如果RAG检索模块的设计允许服务器发起不受限制的请求，可能会导致SSRF漏洞的利用。

**攻击案例**

案例
描述




案例一
由于LangChain框架中存在的SSRF以及PALChain的RCE漏洞，给使用框架的LLM应用带来了安全风险

**攻击风险**

信息泄露：攻击者可能通过路径遍历漏洞访问敏感文件或系统配置文件，泄露系统内部信息。
系统控制：如果系统文件包含敏感的配置信息或脚本，攻击者可能进一步利用这些信息来控制系统。
命令执行：框架中的数据表达式运算、Python解释器等Agent，可能被利用造成RCE攻击。

**缓解措施**

缓解方式
描述




输入验证
严格验证和清理所有用户输入，防止路径遍历攻击。


权限管理
在设置适当的文件权限，防止未授权的文件访问。


更新和修复
确保应用程序和相关依赖的最新版本，及时应用安全补丁以修复已知漏洞。

**参考**

https://www.wehelpwin.com/article/5063
https://medium.com/nfactor-technologies/rag-poisoning-an-emerging-threat-in-ai-systems-660f9ff279f9
https://ironcorelabs.com/security-risks-rag/

---
### 不安全的代码实践

> 风险编号: GAARM.0035
> 生命周期: 训练阶段

**攻击概述**

不安全的代码实践是指基于大模型集成框架，开发LLMs应用过程中由于设计缺陷导致的安全问题。在LLMs应用程序开发过程中采用的代码逻辑，可能会带来安全风险，给LLMs应用程序引入可被利用的安全漏洞。其中的安全漏洞可能包含两大类：

LLMs应用程序服务存在传统的漏洞，例如对外服务的Chat系统服务存在越权查看他人对话记录等风险；
LLMs集成框架中的新型Tools、Agents、Chains中包含安全风险，导致攻击者可以基于LLMs间接利用相关漏洞；

**攻击案例**

案例
描述




案例一
LangChains中的PALChain被发现存在代码执行风险


案例二
LangChains中被挖掘出多个RCE高危漏洞

**攻击风险**

不安全的编码实践：LLMs 在生成代码时可能会遵循不安全的编码实践，导致生成的代码含有安全漏洞。
未经授权的请求执行：攻击者可以直接利用LLMs应用漏洞或者通过操纵输入提示，使LLMs应用执行意外的请求，访问或操作受限制的资源。

**缓解措施**

缓解方式
描述




自动化检测评估
利用静态分析工具检测代码中的不安全模式，以提高代码安全性


最小权限原则
遵循最小权限原则，只为LLMs提供完成其任务所必需的最小访问权限，避免过度代理授权


输入验证和过滤
实施严格的输入验证和净化策略，以确保所有输入数据在被LLMs处理前都经过检查和清理

**参考**

https://arxiv.org/html/2312.04724v1

---
### 数据处理组件漏洞

> 风险编号: GAARM.0034.001
> 生命周期: 训练阶段

**攻击概述**

在人工智能（AI）模型的开发过程中，数据集的安全性是一个不容忽视的重要方面。在Hugging Face、GitHub等平台可能存在一些带有恶意后门的数据集，而这些数据集可以通过LLMs数据处理组件的特性或者漏洞，对AI模型的安全性构成威胁。当开发者使用这些受污染的数据集进行模型训练时，数据集中隐藏的恶意代码可能会被执行，从而导致一系列安全问题，如AI模型、数据集和代码的泄露或篡改。

**攻击案例**

案例
描述




案例一
Hugging Face的datasets组件被发现存在不安全特性，使用该组件加载恶意数据集时，可能导致命令执行等风险

**攻击风险**

系统入侵：攻击者构造的恶意脚本可以连接到攻击者服务器，执行系统命令，从而控制受害者的服务器。
数据泄露：恶意脚本可以窃取服务器上的训练数据、模型代码等敏感数据，导致知识产权和用户隐私的泄露。
模型参数篡改：大模型的参数可能被恶意篡改，影响模型的准确性和可靠性。

**缓解措施**

缓解方式
描述




训练/微调数据集的可信来源
确保来源数据集可信，检查数据集脚本中是否存在恶意Python代码，谨慎使用在Hugging Face上被提示存在安全风险的数据集


大模型组件供应链安全防护
持续跟进关注大模型原生安全、基础安全及大模型赋能研发安全等领域的最新供应链安全动态和建议

**参考**

https://security.tencent.com/index.php/blog/msg/209

---
### 第三方组件漏洞

> 风险编号: GAARM.0034
> 生命周期: 训练阶段

**攻击概述**

该攻击是指LLMs应用开发者在模型训练阶段可能会使用第三方商业或者开源库组件，在这些第三方组件中有可能包含恶意代码、组件漏洞等，可能导致开发机、服务器受到入侵，属于AI环境下的供应链安全风险。

**攻击案例**

案例
描述




案例一
Redis数据库Python客户端redis-py使用异步接口，取消命令时可能导致用户业务数据读取出现错乱(CVE-2023-28858)


案例二
TorchServe可导致越权服务器访问，并在易受攻击的实例上实现远程代码执行


案例三
Hugging Face的datasets组件存在漏洞，允许通过恶意数据集实施攻击，可能导致用户设备被侵入和大模型参数被窃取或篡改


案例四
本文研究了后门攻击对预训练好的模型的影响。攻击者可以通过植入后门，操纵模型的推荐结果，从而达到恶意营销或其他目的


案例五
ChatGPT-Next-Web存在SSRF和反射性XSS漏洞

**攻击风险**

供应链后门投毒攻击：AI开发者在使用第三方开源库加载数据集时，若数据集被植入恶意代码，可能会使PC或服务器遭受攻击。
模型参数泄露或篡改：导致模型参数被窃取或篡改，影响模型的安全性和可靠性。

**缓解措施**

缓解方式
描述




大模型组件供应链安全防护
对于已知的安全漏洞，如TorchServe的CVE-2023-43654，应及时更新到安全的版本


训练/微调数据集的可信来源
确保数据集来源可信，检查数据集脚本中是否存在恶意Python代码，避免使用在Hugging Face上被提示存在安全风险的数据集


严格控制开源组件引入
建立企业内部的开源治理体系，严格控制开源组件的引入，并通过工具实现自动化监测和跟踪

**参考**

https://hiddenlayer.com/research/insane-in-the-supply-chain/

---

---

