除了 Webhook，另一個高風險點是 MCP-SSE 端點。
這類端點會建立 長連線 (long-lived connection)，讓客戶端持續接收 AI / MCP 的回應。
如果沒有防護，駭客可以藉由 SSE 發送惡意 payload，或佔住連線資源，造成服務癱瘓。

攻擊場景

1. 駭客直接連線到 SSE 端點

   • 例如：

     http://your-n8n-domain/api/stream
     

2. 發送惡意 Payload
   {"prompt": "DROP TABLE users; --"}

可能發生的攻擊

1. Prompt Injection：讓 LLM 執行敏感指令，呼叫外部 API 或產生惡意 SQL。
2. Resource DoS：不斷開啟 SSE 連線，耗盡 CPU / 記憶體 / 網路。
3. 資料外洩：藉由長連線持續觀察模型輸出，側錄敏感資訊。

模擬攻擊

用 curl 模擬 SSE 攻擊：

• 模擬駭客發送 payload：

  curl -N -X POST "http://localhost:8000/api/stream" \
    -H "Content-Type: application/json" \
    -d '{"prompt": "DROP TABLE users; --"}'
  

-N 代表「保持長連線」，適合 SSE 測試

你會看到伺服器逐步輸出：

• 模擬 DoS → 用 ab 或 hey 開數千 SSE 連線，觀察 CPU 與記憶體。

  hey -n 1000 -c 100 -m POST -T "application/json" -d '{"prompt":"hello"}' http://localhost:8000/api/stream
  

  

為什麼 MCP-SSE 更危險？

1. 長連線 → 攻擊者可以無限時間佔用資源，比單次 Webhook 更難防。
2. 即時互動 → 攻擊者可即時調整 prompt，直到模型產生預期的惡意輸出。
3. 隱蔽性高 → SSE 輸出看似「正常資料流」，很難在網路層馬上攔截。

今日總結

這次模擬展示了 MCP-SSE 端點在缺乏防護時的高風險性。與單次 Webhook 攻擊相比，SSE 的「長連線特性」讓攻擊者更容易：

1. 持續注入惡意 Prompt → 導致 LLM 執行敏感操作（SQL Injection / 任意 API 呼叫）。
2. 佔用資源發動 DoS → 大量同時連線快速消耗 CPU 與記憶體，使服務無法回應正常使用者。
3. 側錄或竊取敏感資訊 → SSE 輸出的即時資料流可被惡意監聽，增加資訊外洩風險。

MCP-SSE 端點若無驗證與流量控制，等於向攻擊者敞開大門，不但容易被濫用，還可能引發大規模資安事故。

經後續請教專家後發現本主題文章有許多錯誤，參考價值低，在這邊先跟讀者道歉，帶給大家錯誤資訊