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

最新研究顯示，該協(xié)議存在重大漏洞，攻擊者可利用LLM的指令/數(shù)據(jù)混淆漏洞直接訪問數(shù)據(jù)庫。如果用戶提供的“數(shù)據(jù)”被精心偽裝成指令，模型很可能會將其作為真實指令執(zhí)行。

MCP協(xié)議如今已成為智能體領(lǐng)域的行業(yè)標(biāo)準，可以很好連接大語言模型與各種工具服務(wù)，很多公司都紛紛接入使用。然而，當(dāng)模型處理網(wǎng)頁、郵件、文檔或圖像等內(nèi)容時，一旦其中隱藏了惡意指令，模型就有可能誤將其當(dāng)作真實指令執(zhí)行，進而觸發(fā)未經(jīng)授權(quán)的操作，例如泄露私人數(shù)據(jù)。

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

為了演示LLM安全風(fēng)險，研究者基于Supabase搭建了一個典型的多租戶客服SaaS系統(tǒng)。Supabase是一個開源的實時后端服務(wù)平臺，包含數(shù)據(jù)庫、身份認證、文件存儲等功能。該系統(tǒng)啟用了標(biāo)準的行級安全（RLS）機制，且未添加任何額外的策略。本次攻擊演示所利用的一切要素均存在于默認配置中，包括標(biāo)準service_role、默認模型、RLS和代表開發(fā)人員發(fā)起MCP調(diào)用的語言模型助手。

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

其中要注意的是：

支持代理無權(quán)訪問任何非支持表或敏感表。要求支持代理提供任何敏感信息將導(dǎo)致拒絕。

下面讓我們詳細了解一下數(shù)據(jù)泄露過程。攻擊者首先提交了一份新的技術(shù)支持請求，其中包含精心構(gòu)造的消息內(nèi)容：既以友好提問作為偽裝，又嵌入了直接發(fā)送給Cursor代理的明確指令。

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

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

當(dāng)支持代理查看工單時，他們只會按預(yù)期進行回復(fù)。需要注意的是，支持代理的權(quán)限不允許訪問integration_tokens表，因此此階段不會暴露任何敏感信息。然而，當(dāng)開發(fā)人員隨后使用Cursor查看未處理工單時，就會發(fā)生違規(guī)行為。他們可能會輸入如下指令：

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

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

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

2、列出所有支持工單

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

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

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

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

讀取integration_tokens中的全部內(nèi)容；

將讀取到的結(jié)果作為新消息插入到當(dāng)前工單的消息線程中。

這兩條查詢均由擁有高權(quán)限的service_role執(zhí)行，該角色可以繞過所有行級安全（RLS）限制。對于開發(fā)人員而言，這些操作看起來就像普通的工具調(diào)用。除非手動展開查看，否則幾乎無法與之前的合法查詢區(qū)分開來。查詢一旦執(zhí)行完成，敏感數(shù)據(jù)會立即顯示在該工單的對話中。攻擊者只需刷新頁面，就能看到包含機密信息的新消息。

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

解決措施

這類攻擊的根源在于兩個設(shè)計缺陷的疊加：數(shù)據(jù)庫權(quán)限過高（如service_role），以及對用戶提交內(nèi)容的盲目信任。以下是團隊用以降低風(fēng)險暴露的兩項措施：

盡可能使用只讀模式

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

添加提示注入（Prompt Injection）過濾器這一機制可以通過在MCP外部構(gòu)建一個輕量級過濾模塊來實現(xiàn)，用于攔截傳入數(shù)據(jù)，并對高風(fēng)險輸入進行標(biāo)記或清除。雖然該防護無法捕捉所有攻擊，但它作為可擴展且切實可行的第一道防線，尤其適用于那些使用第三方IDE（如 Cursor）且難以明確劃分上下文邊界的團隊。

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

本文來自微信公眾號“量子位”，作者：關(guān)注前沿科技，36氪經(jīng)授權(quán)發(fā)布。

本文僅代表作者觀點，版權(quán)歸原創(chuàng)者所有，如需轉(zhuǎn)載請在文中注明來源及作者名字。

免責(zé)聲明：本文系轉(zhuǎn)載編輯文章，僅作分享之用。如分享內(nèi)容、圖片侵犯到您的版權(quán)或非授權(quán)發(fā)布，請及時與我們聯(lián)系進行審核處理或刪除，您可以發(fā)送材料至郵箱：service@tojoy.com