大模型原生安全与基础安全教学文档

一、前言

随着AI技术的快速发展，大模型如腾讯混元大模型等已广泛应用于实际场景，包括安全漏洞修复、腾讯会议AI助手等。然而，AI与WEB应用的结合若使用不当，会带来各种安全问题。PortSwigger提供了多个实验场景，展示了LLM(大语言模型)可能存在的安全风险。

二、LLM安全风险类型

1. 暴露过多接口(Excessive Agency)

问题描述：LLM API暴露了过多的功能接口，可能导致越权访问。

实验案例：

• 实验环境：https://portswigger.net/web-security/llm-attacks/lab-exploiting-llm-apis-with-excessive-agency
• 攻击步骤：
  1. 直接咨询AI助手有哪些可用接口
  2. 获取到不应暴露的敏感接口信息
  3. 测试未授权接口，如执行SQL语句：

     select table_name from information_schema.tables limit 10;
     

防御措施：

• 严格控制LLM暴露的接口范围
• 实现严格的权限控制机制
• 对敏感操作进行二次验证

2. LLM API接口漏洞

问题描述：LLM API本身存在漏洞，可能被利用进行未授权操作或数据泄露。

攻击方式：

• 参数注入
• 未授权访问
• 功能滥用

防御措施：

• 实施严格的输入验证
• 完善的错误处理机制
• 接口访问日志监控

3. 间接提示词注入(Indirect Prompt Injection)

问题描述：攻击者通过间接方式向LLM注入恶意提示，绕过直接输入限制。

实验案例：

• 实验环境：https://portswigger.net/web-security/llm-attacks/lab-indirect-prompt-injection

攻击方式：

• 通过第三方数据源注入恶意指令
• 利用LLM的记忆功能进行持久化攻击

防御措施：

• 实现提示词过滤和净化
• 限制LLM对不可信数据源的处理
• 设置执行上下文隔离

4. 不安全的输出处理(Insecure Output Handling)

问题描述：LLM的输出未经适当处理直接传递给其他系统组件，可能导致注入攻击。

风险场景：

• LLM输出直接作为SQL查询
• LLM输出直接作为系统命令
• LLM输出直接作为API参数

防御措施：

• 对所有LLM输出进行验证和转义
• 实施输出内容白名单机制
• 避免将LLM输出直接用于敏感操作

三、实践建议

1. 最小权限原则：LLM应仅拥有完成任务所需的最小权限
2. 输入输出验证：对所有输入和输出进行严格验证
3. 审计日志：记录所有LLM交互以供审计
4. 沙箱环境：在高风险操作中使用沙箱环境
5. 持续监控：实时监控异常行为模式

四、总结

大模型的安全问题既包括传统的基础安全问题，也有其特有的原生安全问题。开发者在集成LLM时，需要同时关注：

• 传统的API安全、输入验证、权限控制等基础安全
• LLM特有的提示词注入、过度代理、输出处理等原生安全问题

通过实施全面的安全措施，可以在享受AI技术带来便利的同时，有效降低安全风险。