MCP协议曝出大漏洞:会泄露整个数据库

时令 发自 凹非寺
量子位 | 公众号 QbitAI

所有使用MCP协议的企业注意:你的数据库可能正在“裸奔”!

最新研究显示,该协议存在重大漏洞,攻击者可利用LLM的指令/数据混淆漏洞直接访问数据库

如果用户提供的“数据”被精心伪装成指令,模型很可能会将其作为真实指令执行。

要知道,MCP协议今已成为智能体领域的行业标准,可以很好连接大语言模型与各种工具服务,很多公司都纷纷接入使用。

然而,当模型处理网页、邮件、文档或图像等内容时,一旦其中隐藏了恶意指令,模型就有可能误将其当作真实指令执行,进而触发未经授权的操作,例如泄露私人数据。

数据是如何被泄露的?

为了演示LLM安全风险,研究者基于Supabase搭建了一个典型的多租户客服SaaS系统。Supabase是一个开源的实时后端服务平台,包含数据库、身份认证、文件存储等功能。

该系统启用了标准的行级安全(RLS)机制,且未添加任何额外的策略。

本次攻击演示所利用的一切要素均存在于默认配置中,包括标准service_role、默认模型、RLS和代表开发人员发起MCP调用的语言模型助手。

该系统涉及的角色和权限边界如下所示:

其中要注意的是:

支持代理无权访问任何非支持表或敏感表。要求支持代理提供任何敏感信息将导致拒绝。

下面让我们详细了解一下数据泄露过程

攻击者首先提交了一份新的技术支持请求,其中包含精心构造的消息内容:既以友好提问作为伪装,又嵌入了直接发送给Cursor代理的明确指令。

在系统中的对话界面如下所示:

这条消息通过正常的工单提交通道进入数据库,存储在客户消息表中,未被任何过滤或阻断。

当支持代理查看工单时,他们只会按预期进行回复。需要注意的是,支持代理的权限不允许访问integration_tokens表,因此此阶段不会暴露任何敏感信息。

然而,当开发人员随后使用Cursor查看未处理工单时,就会发生违规行为。他们可能会输入如下指令:

请显示最新的未处理支持工单。

此时,Cursor的代理通过Supabase MCP集成,自动发起一系列自动化SQL查询:

1、加载项目的数据库架构

2、列出所有支持工单

3、筛选出状态为“未解决”的工单

4、获取最新工单的所有消息

在此过程中,代理读取了攻击者提交的消息,并按照其中嵌入的指令执行相应操作。

最终,系统生成了两条新的SQL查询语句:

  • 读取integration_tokens中的全部内容;

  • 将读取到的结果作为新消息插入到当前工单的消息线程中。

这两条查询均由拥有高权限的service_role执行,该角色可以绕过所有行级安全(RLS)限制。

对于开发人员而言,这些操作看起来就像普通的工具调用。除非手动展开查看,否则几乎无法与之前的合法查询区分开来。

查询一旦执行完成,敏感数据会立即显示在该工单的对话中。

攻击者只需刷新页面,就能看到包含机密信息的新消息。

从权限角度来看,这一过程完全合规。

解决措施

这类攻击的根源在于两个设计缺陷的叠加:数据库权限过高(如service_role),以及对用户提交内容的盲目信任。

以下是团队用以降低风险暴露的两项措施:

尽可能使用只读模式

启用该模式后,即使提示词被恶意利用,也无法执行插入(insert)、更新(update)或删除(delete)等操作。

添加提示注入(Prompt Injection)过滤器
这一机制可以通过在MCP外部构建一个轻量级过滤模块来实现,用于拦截传入数据,并对高风险输入进行标记或清除。

虽然该防护无法捕捉所有攻击,但它作为可扩展且切实可行的第一道防线,尤其适用于那些使用第三方IDE(如 Cursor)且难以明确划分上下文边界的团队。

(文:量子位)

发表评论