MCP生態實戰價值：Supabase漏洞反思與MCP Server鑒權加固

Supabase漏洞事件復盤

Hacker News上一篇關于“Supabase MCP漏洞可導出全庫SQL”的討論，實際指向一個更具體的問題：Supabase的MCP服務端未對/mcp/export端點做租戶隔離和操作權限校驗。攻擊者只需構造一個合法認證頭，就能觸發全庫導出，拿到所有表結構和數據。

這不是MCP協議本身的漏洞，而是Supabase在實現MCP Server時跳過了三個關鍵環節：

• 沒綁定請求上下文到用戶身份（例如沒提取JWT中的tenant_id或role字段）
• 沒校驗操作語義（export屬于高危動作，不應開放給普通用戶）
• 沒限制導出范圍（默認導出全部schema，未強制指定--schema=app_public之類約束）

這個案例暴露的不是協議缺陷，而是MCP Server開發中常見的“協議搬運工”陷阱：照搬協議定義，卻忽略業務語義層的訪問控制。

MCP Server必須守住的三道防線

MCP協議本身不規定鑒權模型，它只定義消息格式和路由規則。Server實現者必須自己補上這三層防護：

1. 上下文綁定：把請求錨定到真實身份

MCP請求里帶Authorization頭，但不能只驗證token是否有效。要解析出sub、tenant_id、scope等聲明，并在后續所有處理中顯式傳遞。

# 正確做法：解析并注入上下文
from flask import g, request
import jwt

def auth_middleware():
    token = request.headers.get('Authorization', '').replace('Bearer ', '')
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=['HS256'])
        g.user_id = payload['sub']
        g.tenant_id = payload['tenant_id']
        g.scopes = set(payload.get('scope', '').split())
    except Exception:
        return {'error': 'Invalid token'}, 401

@app.before_request
def before_request():
    return auth_middleware()

2. 動作分級：按操作敏感度動態授權

MCP操作不能一刀切。list_tools可以公開，export_db必須要求admin:tenant scope，delete_tool則需額外校驗工具歸屬。

def require_scope(*required_scopes):
    def decorator(f):
        def wrapped(*args, **kwargs):
            missing = set(required_scopes) - g.scopes
            if missing:
                return {'error': f'Missing scopes: {missing}'}, 403
            # 額外檢查：export_db必須限定schema
            if 'export_db' in required_scopes and request.args.get('schema') != g.tenant_id:
                return {'error': 'Export schema must match tenant'}, 403
            return f(*args, **kwargs)
        return wrapped
    return decorator

@app.route('/mcp/export', methods=['POST'])
@require_scope('export_db')
def export_db():
    # 此時g.tenant_id和scopes均已驗證
    return run_export(g.tenant_id)

3. 數據沙箱：用數據庫能力做物理隔離

別靠應用層if-else過濾數據。用PostgreSQL的Row Level Security（RLS）或MySQL的Schema級權限，讓數據庫自己攔住越權查詢。

-- PostgreSQL RLS策略示例
ALTER TABLE public.tools ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON public.tools
  USING (tenant_id = current_setting('app.current_tenant', true)::uuid);

然后在應用層設置會話變量：

@app.before_request
def set_tenant_context():
    db.execute("SET app.current_tenant = %s", (g.tenant_id,))

這樣即使代碼漏掉某處校驗，數據庫也會拒絕返回其他租戶的數據。

鑒權加固不是加功能，是改流程

很多團隊把鑒權當成“加個中間件”，結果變成層層嵌套的裝飾器。真正有效的加固，是把權限判斷嵌入到核心路徑里：

• 工具注冊時，記錄owner_tenant_id
• 請求解析后，立即查tools表確認該工具屬于當前租戶
• 執行前，用pg_advisory_xact_lock()對租戶ID加事務鎖，防并發沖突
• 日志里強制記錄tenant_id、user_id、action、duration_ms

@app.route('/mcp/execute', methods=['POST'])
def execute_tool():
    tool_name = request.json['tool']
    # 1. 查工具歸屬
    tool = db.fetch_one("SELECT * FROM tools WHERE name = %s AND tenant_id = %s", 
                        (tool_name, g.tenant_id))
    if not tool:
        return {'error': 'Tool not found or access denied'}, 404
    
    # 2. 加租戶鎖（防并發修改配置）
    db.execute("SELECT pg_advisory_xact_lock(hashtext(%s))", (g.tenant_id,))
    
    # 3. 執行并計時
    start = time.time()
    result = run_tool(tool, request.json['args'])
    duration = int((time.time() - start) * 1000)
    
    # 4. 記錄審計日志（含租戶上下文）
    audit_log.insert({
        'tenant_id': g.tenant_id,
        'user_id': g.user_id,
        'action': 'execute_tool',
        'tool': tool_name,
        'duration_ms': duration,
        'status': 'success' if result else 'failed'
    })
    
    return result

商業化落地的關鍵：把安全設計變成客戶能感知的價值

金融客戶不關心你用了RBAC還是ABAC，但他們清楚知道：“如果你們的MCP Server被攻破，我的交易數據會不會流到競爭對手那里？”

所以商業化路徑要倒過來推：

1. 從合規需求反推技術方案

• GDPR → 要求數據不出境 → 在MCP Server里加region字段，路由時強制匹配
• HIPAA → 要求審計日志留存6年 → 把audit_log表設為分區表，按月自動歸檔
• 等保三級 → 要求雙因素登錄 → 在token簽發前，校驗TOTP code

2. 把防護能力包裝成可售特性

3. 用客戶自己的環境驗證效果

別只講PPT。給POC客戶部署一個帶審計看板的實例：

• 實時顯示“今日攔截越權請求：17次”
• 展示一條被拒請求的完整鏈路：JWT解析→scope校驗失敗→拒絕→寫入審計日志
• 提供一鍵生成合規報告的按鈕（含GDPR/HIPAA條款映射）

真實項目踩坑記錄

我們給一家跨境支付公司上線MCP Server時，在/mcp/transfer接口栽過跟頭：

• 初始版本只校驗了transfer_funds scope，沒校驗from_account是否屬于當前租戶
• 攻擊者用自己租戶的token，把from_account改成另一家客戶的賬戶ID，成功轉出資金

• 修復方案不是加if判斷，而是：

  1. 在數據庫加外鍵約束：transfers.from_account_id → accounts.id + accounts.tenant_id = transfers.tenant_id
  2. 查詢時強制JOIN：SELECT * FROM transfers t JOIN accounts a ON t.from_account_id = a.id AND a.tenant_id = %s
  3. 所有account ID參數，統一走uuid類型校驗，防SQL注入

這次事故讓我們確認一條原則：鑒權邏輯必須下沉到數據訪問層，應用層只做快速失?。╢ast fail），不承擔最終裁決責任。

下一步行動清單

• [ ] 檢查現有MCP Server所有端點，標記出export、delete、exec類高危動作
• [ ] 給每個高危端點補上tenant_id顯式校驗，刪掉所有“全局查詢”SQL
• [ ] 在數據庫啟用RLS或對應隔離機制，用EXPLAIN ANALYZE驗證策略生效
• [ ] 把審計日志字段從user_id擴展為{tenant_id,user_id,ip,ua}，接入SIEM系統
• [ ] 更新客戶文檔，在“安全特性”章節直接寫明：“所有導出操作強制限定schema，無法跨租戶”