Cross Plugin Request Forgery (CPRF)：大模型安全的隐秘威胁

大语言模型（LLMs）如 ChatGPT、Claude 等的应用正在快速扩展。为了实现更多样化的能力，这些模型通过插件扩展与外部系统交互，比如数据库查询、调用外部 API、生成报告等。然而，这种灵活性也带来了潜在风险，Cross Plugin Request Forgery (CPRF) 是一种鲜为人知但危险的漏洞。它利用插件之间的信任关系，通过伪造请求实现未授权操作，可能导致数据泄露、功能滥用甚至攻击链扩展。

本文旨在揭示 CPRF 的原理、在大模型中的威胁模型、风险挖掘思路以及真实案例，帮助开发者和安全研究人员应对这种新型威胁。    

1. 什么是 Cross Plugin Request Forgery (CPRF)

1.1 定义

Cross Plugin Request Forgery (CPRF) 是一种安全漏洞，攻击者利用插件之间的通信机制，伪造请求操控其他插件执行未授权的操作。这种攻击依赖于以下条件：

插件之间存在通信机制（如上下文共享、API 调用）。

插件未对通信请求来源或内容进行严格验证。

插件拥有超出攻击者权限的操作能力。

1.2 工作原理

CPRF 的核心是攻击者通过伪造通信请求，冒充可信插件发送数据或指令，从而欺骗目标插件执行敏感操作。其步骤包括：

信息收集          
攻击者分析插件间的通信模式，确定目标插件和通信接口。

伪造请求          
攻击者构造恶意请求，利用插件通信机制发送至目标插件。

执行操作          
如果目标插件缺乏验证机制，便会执行伪造请求中的操作。

2. 大模型中的威胁模型

在大模型生态中，插件的广泛使用带来了 CPRF 的多样化表现形式。以下是大模型插件生态中 CPRF 的主要威胁点：

2.1 上下文共享的信任漏洞

大模型通常允许多个插件共享上下文数据。例如，用户请求通过插件 A 查询数据库，再通过插件 B 生成可视化报告。如果插件 B 未验证上下文的真实性，恶意插件可以伪造数据，篡改报告内容。

2.2 插件 API 的滥用

插件之间可能通过 REST API 或 RPC 交互。如果 API 缺乏认证，恶意插件可以伪造合法插件的请求，操控其他插件。例如，一个翻译插件可能调用另一个语言检测插件的 API，而攻击者可以伪造调用并篡改结果。    

2.3 权限边界不清

一些插件拥有高权限（如访问用户数据、文件系统等），而其他插件权限较低。如果高权限插件对通信请求无差别响应，则可能被低权限插件利用来执行越权操作。

3. 风险挖掘思路

3.1 插件通信机制的分析

数据流分析          
追踪插件之间的数据流，确定哪些插件共享上下文或调用接口。重点关注：

• 插件是否直接接受未经验证的外部输入。

• 插件是否依赖其他插件的返回结果进行操作。

接口暴露点挖掘          
检查插件暴露的通信接口，分析其访问控制机制。例如：

• 是否验证请求来源？

• 是否对输入参数进行校验？

3.2 权限模型审计

权限边界检查          
分析每个插件的权限范围，重点识别高权限插件是否允许低权限插件间接调用敏感功能。

最小权限原则验证          
检查插件是否仅拥有完成任务所需的最小权限。

3.3 模拟攻击场景

伪造请求测试          
构造恶意请求，尝试篡改插件通信的上下文或直接调用目标接口。

沙盒运行分析          
将插件运行在隔离环境中，观察是否存在不合理的权限提升或通信模式。

4. 真实案例：大模型插件中的 CPRF

案例 1：财务助手与报告生成插件

背景          
某大模型支持财务助手插件（用于生成用户的财务数据）和报告生成插件（将数据转化为可视化图表）。财务助手需要高权限访问用户敏感数据，而报告插件负责输出操作。    

攻击场景          
攻击者开发了一个恶意插件，通过共享上下文的方式，伪造财务助手的请求，指示其生成超出权限范围的敏感财务数据并传递给报告生成插件。

漏洞原因

财务助手插件未验证请求的来源是否可信。

报告生成插件直接信任了上下文中的数据。

修复措施

在插件通信中引入请求签名机制，验证请求来源的合法性。

对财务助手插件的操作范围增加权限校验。

案例 2：文件上传与代码执行插件

背景          
某大模型支持两个插件：一个用于文件上传，另一个用于执行代码。用户可上传代码文件，并由代码执行插件运行。

攻击场景          
攻击者通过文件上传插件上传恶意脚本，并利用 CPRF 将脚本路径传递给代码执行插件，导致远程命令执行。

漏洞原因

文件上传插件未限制上传文件的类型和路径。

代码执行插件对传入的文件路径未进行验证。

修复措施

限制文件上传插件的权限，仅允许其存储文件而非直接操作路径。

在代码执行插件中增加对输入路径的严格验证。

5. 防御 CPRF 的综合策略

5.1 插件间通信安全

数字签名          
所有插件间通信请求必须携带数字签名，以确保请求来源可信。

Token 机制          
使用唯一的通信 Token 对每次请求进行验证，防止伪造。

5.2 插件隔离与权限控制

沙盒化运行          
将插件运行在隔离环境中，防止其直接访问核心数据或功能。    

权限最小化          
每个插件仅授予完成任务所需的最小权限，避免权限滥用。

5.3 数据校验与监控

上下文验证          
插件在处理上下文数据前，需验证数据的完整性和来源。

日志与审计          
记录插件之间的所有通信行为，便于溯源和攻击检测。    

原文始发于微信公众号（暴暴的皮卡丘）：Cross Plugin Request Forgery (CPRF)：大模型安全的隐秘威胁