去年企業(yè)安全團隊還在討論"AI會不會寫漏洞代碼"，今年攻擊者已經(jīng)用AI助手的基礎設施反咬了一口。MCP（模型上下文協(xié)議，Model Context Protocol）作為AI連接外部工具的"萬能插頭"，正在成為紅隊的新游樂場。

這篇是系列第二篇。作者從安全架構師切換成紅隊視角，用三個真實攻擊場景驗證：你畫的信任邊界，在實戰(zhàn)中到底漏了多少風。

場景一：計算器App的供應鏈伏擊

攻擊起點是一臺開發(fā)者的Mac。 他裝了個"程序員計算器"App，看起來人畜無害——進制轉換、位運算、IEEE 754浮點展示，功能干凈到讓人放松警惕。

這個App注冊了MCP服務器。用戶授權時看到的權限描述是："讀取當前文件內容以進行數(shù)值分析"。聽起來合理，計算器需要讀數(shù)字嘛。

但MCP的權限模型有個縫隙：它讀的是"當前活躍編輯器的內容"，而非"用戶選中的數(shù)字"。攻擊者利用這個語義差，讓計算器在后臺持續(xù)掃描VS Code的活躍標簽頁。當檢測到SSH私鑰的PEM格式特征（`-----BEGIN OPENSSH PRIVATE KEY-----`）時，立即通過隱蔽信道外發(fā)。

整個過程中，用戶只點過一次授權。沒有彈窗，沒有額外提示。計算器甚至真的在正常工作——你輸入`0xFF & 0x0F`，它返回`0x0F`，功能完全可用。

作者復盤時提到一個細節(jié)：這個攻擊能成立，是因為MCP的權限提示把"讀取當前文件"包裝成了"讀取當前數(shù)值"。用戶理解的是"讀我選中的那串數(shù)字"，實際 granted 的是"讀整個編輯器緩沖區(qū)"。這種認知差在UI層面被放大了。

場景二：文檔助手的持久化后門

第二個場景更隱蔽。攻擊目標是一個企業(yè)內部的MCP服務器，功能是給AI提供"搜索公司知識庫"的能力。代碼審計沒發(fā)現(xiàn)問題，依賴掃描也干凈。

紅隊在響應格式里埋了雷。

MCP服務器返回的內容支持Markdown。攻擊者構造了一個特殊的搜索結果：標題正常，摘要正常，但里面嵌了一個被CSS隱藏的``。當AI助手把結果渲染給用戶的聊天界面時，這個iframe在后臺加載了攻擊者的控制端。</p> <p>這里的信任邊界崩塌發(fā)生在兩個環(huán)節(jié)：一是MCP服務器沒對返回內容做凈化（認為"自己的數(shù)據(jù)是可信的"），二是AI客戶端把服務器返回的內容直接塞進前端渲染（認為"MCP層已經(jīng)處理過安全"）。兩邊都假設對方負責，結果兩邊都漏了。</p> <p>作者把這叫"雙向信任盲區(qū)"——比單向漏洞更難發(fā)現(xiàn)，因為單獨審計任何一方都顯得合規(guī)。</p> <p><h5>場景三：工具調用的參數(shù)污染</h5></p> <p>第三個攻擊針對的是MCP的"工具調用"機制。企業(yè)給AI配了個數(shù)據(jù)庫查詢工具，權限控制很嚴：只能讀，不能寫；只能訪問`analytics`庫，不能碰`production`。</p> <p>紅隊的突破點在參數(shù)解析。MCP工具的定義里，參數(shù)類型是JSON Schema。但某些服務端實現(xiàn)用的是寬松的解析器，允許類型強制轉換。攻擊者提交了一個看起來合法的查詢參數(shù)：</p> <p><b>{"table": "user_events", "where": {"user_id": "12345"}}</b></p> <p>服務端校驗通過：table在白名單，where結構正確。但實際執(zhí)行時，寬松的解析器把`user_id`的值當成SQL片段處理了。最終執(zhí)行的查詢變成了`SELECT * FROM user_events WHERE user_id = 12345 OR 1=1`，數(shù)據(jù)全漏。</p> <p>作者強調這不是SQL注入的新變種，而是MCP層和數(shù)據(jù)庫層之間的"協(xié)議語義斷層"。MCP以為自己在傳結構化數(shù)據(jù)，數(shù)據(jù)庫層收到的卻是可被操縱的字符串。中間這層轉換沒做嚴格邊界檢查。</p> <p><h5>Triple Gate的實戰(zhàn)檢驗</h5></p> <p>回到第一篇提出的Triple Gate架構：Identity Gate（身份）、Intent Gate（意圖）、Action Gate（行為）。這三個場景分別擊穿了哪一層？</p> <p>計算器App繞過了Intent Gate。用戶授權時的"意圖"被UI描述扭曲了，系統(tǒng)記錄的intent和用戶的真實意圖不一致。</p> <p>文檔助手的iframe繞過了Action Gate。身份驗過了，意圖看起來也正常（搜索請求），但執(zhí)行階段的行為超出了預期邊界。</p> <p>參數(shù)污染則是三層都"形式上通過"：身份合法、意圖表面合規(guī)、行為在MCP層看來也沒越界——問題出在MCP層和下游系統(tǒng)之間的信任傳遞。</p> <p>作者的紅隊結論很直接：<b>信任邊界不能只畫在MCP服務器門口，得畫到每一個數(shù)據(jù)轉換的接縫處。</b></p> <p>具體建議包括：權限描述必須用用戶能理解的動詞（"讀取當前編輯器全部內容"而非"讀取當前文件"）、返回內容強制走凈化流水線、參數(shù)解析用嚴格模式并顯式拒絕類型強制轉換。</p> <p>但最扎心的一條是：企業(yè)現(xiàn)在部署的MCP服務器，有多少做過真正的紅隊測試？作者沒給數(shù)字，只留了一句——</p> <p>「我們審計的十幾個生產(chǎn)環(huán)境MCP實現(xiàn)里，能完整通過這三個場景測試的，數(shù)量是零。」</p> <p>你的MCP服務器，經(jīng)得起計算器App的考驗嗎？</p>