所有使用MCP協(xié)議的企業(yè)注意：你的數(shù)據(jù)庫可能正在“裸奔”！

最新研究顯示，該協(xié)議存在重大漏洞，攻擊者可利用LLM的指令/數(shù)據(jù)混淆漏洞直接訪問數(shù)據(jù)庫。

如果用戶提供的“數(shù)據(jù)”被精心偽裝成指令，模型很可能會將其作為真實指令執(zhí)行。

要知道，MCP協(xié)議如今已成為智能體領域的行業(yè)標準，可以很好連接大語言模型與各種工具服務，很多公司都紛紛接入使用。

然而，當模型處理網(wǎng)頁、郵件、文檔或圖像等內(nèi)容時，一旦其中隱藏了惡意指令，模型就有可能誤將其當作真實指令執(zhí)行，進而觸發(fā)未經(jīng)授權的操作，例如泄露私人數(shù)據(jù)。

數(shù)據(jù)是如何被泄露的？

為了演示LLM安全風險，研究者基于Supabase搭建了一個典型的多租戶客服SaaS系統(tǒng)。Supabase是一個開源的實時后端服務平臺，包含數(shù)據(jù)庫、身份認證、文件存儲等功能。

該系統(tǒng)啟用了標準的行級安全（RLS）機制，且未添加任何額外的策略。

本次攻擊演示所利用的一切要素均存在于默認配置中，包括標準service_role、默認模型、RLS和代表開發(fā)人員發(fā)起MCP調(diào)用的語言模型助手。

該系統(tǒng)涉及的角色和權限邊界如下所示：

其中要注意的是：

支持代理無權訪問任何非支持表或敏感表。要求支持代理提供任何敏感信息將導致拒絕。

下面讓我們詳細了解一下數(shù)據(jù)泄露過程。

攻擊者首先提交了一份新的技術支持請求，其中包含精心構造的消息內(nèi)容：既以友好提問作為偽裝，又嵌入了直接發(fā)送給Cursor代理的明確指令。

在系統(tǒng)中的對話界面如下所示：

這條消息通過正常的工單提交通道進入數(shù)據(jù)庫，存儲在客戶消息表中，未被任何過濾或阻斷。

當支持代理查看工單時，他們只會按預期進行回復。需要注意的是，支持代理的權限不允許訪問integration_tokens表，因此此階段不會暴露任何敏感信息。

然而，當開發(fā)人員隨后使用Cursor查看未處理工單時，就會發(fā)生違規(guī)行為。他們可能會輸入如下指令：

請顯示最新的未處理支持工單。

此時，Cursor的代理通過Supabase MCP集成，自動發(fā)起一系列自動化SQL查詢：

1、加載項目的數(shù)據(jù)庫架構

2、列出所有支持工單

3、篩選出狀態(tài)為“未解決”的工單

4、獲取最新工單的所有消息

在此過程中，代理讀取了攻擊者提交的消息，并按照其中嵌入的指令執(zhí)行相應操作。

最終，系統(tǒng)生成了兩條新的SQL查詢語句：

• 讀取integration_tokens中的全部內(nèi)容；
• 將讀取到的結果作為新消息插入到當前工單的消息線程中。

這兩條查詢均由擁有高權限的service_role執(zhí)行，該角色可以繞過所有行級安全（RLS）限制。

對于開發(fā)人員而言，這些操作看起來就像普通的工具調(diào)用。除非手動展開查看，否則幾乎無法與之前的合法查詢區(qū)分開來。

查詢一旦執(zhí)行完成，敏感數(shù)據(jù)會立即顯示在該工單的對話中。

攻擊者只需刷新頁面，就能看到包含機密信息的新消息。

從權限角度來看，這一過程完全合規(guī)。

解決措施

這類攻擊的根源在于兩個設計缺陷的疊加：數(shù)據(jù)庫權限過高（如service_role），以及對用戶提交內(nèi)容的盲目信任。

以下是團隊用以降低風險暴露的兩項措施：

盡可能使用只讀模式

啟用該模式后，即使提示詞被惡意利用，也無法執(zhí)行插入（insert）、更新（update）或刪除（delete）等操作。

添加提示注入（Prompt Injection）過濾器這一機制可以通過在MCP外部構建一個輕量級過濾模塊來實現(xiàn)，用于攔截傳入數(shù)據(jù)，并對高風險輸入進行標記或清除。

雖然該防護無法捕捉所有攻擊，但它作為可擴展且切實可行的第一道防線，尤其適用于那些使用第三方IDE（如 Cursor）且難以明確劃分上下文邊界的團隊。

參考鏈接：https://www.generalanalysis.com/blog/supabase-mcp-blog