Gemini Live API 令牌漏洞：一個欄位漏填，駭客就 hijack AI 語音會話

漏咗嘅 live_connect_constraints 欄位

根據 Ferdiansyah 嘅文章，Google 嘅參考實作喺 token minting 時 冇用到 live_connect_constraints 欄位 ^A。呢個欄位應該包含一個 bidi_generate_content_setup 物件，將 token 綁定到指定嘅模型、system instruction 同工具集。

當 live_connect_constraints 係空或者冇嘅時候，就冇任何限制被執行。黑客只要拎到呢個 ephemeral token，就可以發送一個 由客戶端控制嘅 setup frame，指定任何模型、system prompt 同工具。伺服器因為冇 token 綁定嘅值做驗證，就會接受黑客嘅配置。

重要提示： 提供嘅來源並冇包括 Google 官方關於 live_connect_constraints 嘅文件、CVE 或者 Google 安全公告。呢個講法係根據 Ferdiansyah 嘅 Medium 文章，未經官方證實，但好可能係真嘅 ^A。

影響：黑客用一個冇限制嘅 token 可以做啲乜

如果呢個漏洞係真嘅，對於任何喺瀏覽器環境用 Gemini Live API 嘅應用程式嚟講，後果都相當嚴重：

• 透過工具做到 sandboxed 代碼執行 — Gemini Live API 嘅例子包括客戶端支援加入自訂工具 ^D。黑客如果可以注入一個惡意工具定義，就有機會喺應用程式嘅 sandbox 入面執行代碼。
• 濫用計算資源 — hijack 咗嘅會話會消耗 victim 應用程式嘅 quota 同 billing。因為 ephemeral tokens 係設計成一次性使用嘅，黑客仲可以透過後端嘅 minting 端點不停咁申請新 token，推高成本 ^G。
• 篡改 prompt — 控制 setup frame 就等於控制 system instruction。黑客可以將個會話用嚟竊取敏感資料、生成有害內容，或者扮成受信任嘅代理 ^D。
• 重複攻擊會話 — Live API 會話有大約 10 分鐘嘅連接限制 ^DD。黑客需要 reconnect，但係用返同一個冇限制嘅 token 流程，就可以不停咁 hijack 個會話。

Google AI 論壇嘅開發者都報告過 ephemeral tokens 忽略 system instructions 同埋喺 constrained 端點上失效嘅問題，反映成個生態系統仲喺發展階段 ^DD。

一個欄位就搞掂嘅修復

Ferdiansyah 提出嘅修復方法好直接：喺 token minting 時候補返 live_connect_constraints.bidi_generate_content_setup 欄位，填入三個值：

1. model — 要用嘅確切 Gemini 模型（例如 models/gemini-2.5-flash-native-audio-latest）。
2. system_instruction — 預期嘅 system prompt，結構係 parts 入面包含 text。
3. tools — 一個空陣列 [] 或者只係允許嘅工具，防止客戶端注入。

以下係 Ferdiansyah 文章入面嘅示範 Python 代碼 ^A：

token = gemini_client.auth_tokens.create({
    "uses": 1,
    "expire_time": now + timedelta(seconds=60),
    "new_session_expire_time": now + timedelta(seconds=60),
    "live_connect_constraints": {
        "bidi_generate_content_setup": {
            "model": "models/gemini-2.5-flash-native-audio-latest",
            "system_instruction": {
                "parts": [{"text": "你係一個客戶支援助理..."}]
            },
            "tools": []
        }
    }
})

注意： 因為 live_connect_constraints 喺提供嘅 Google API 官方參考文件度冇記載，呢個例子係根據 Ferdiansyah 自己嘅描述，應該喺用到生產環境前先測試一下 ^A。

仲未確認嘅嘢

以下關鍵點喺提供嘅來源入面都未經證實：

• 冇 Google 官方文件確認 live_connect_constraints 嘅存在或者結構。
• 冇 CVE 或者安全公告被發布。
• 冇獨立嘅重現漏洞嘅報告。
• BidiGenerateContentConstrained 端點喺收到冇限制 token 時嘅確切行為，喺提供嘅官方參考文件度冇記載 ^DS。

開發者而家應該做嘅嘢

喺 Google 發布官方公告之前，最安全嘅做法係當呢個漏洞好大機會係真嘅，主動修復：

1. 審計你嘅 ephemeral token minting 代碼 — 檢查你個後端有冇用到 live_connect_constraints 或者類似嘅欄位。
2. 永遠唔好暴露 raw API keys — 對瀏覽器面向嘅連接一定要用 ephemeral tokens ^S。
3. set 緊啲 token 過期時間 — Google 建議 newSessionExpireTime 設為大約 60 秒，限制 token 被盜用嘅時間窗 ^G。
4. 伺服器端驗證 setup frames — 就算客戶端自己 send 配置，你嘅後端都應該強制執行預期嘅模型、prompt 同工具。
5. 監察有冇被濫用 — 留意唔尋常嘅會話模式，尤其係同一個 token 嘅重複連接或者意想不到嘅工具調用。

Gemini Live API 係一個好強大嘅工具，用嚟建立即時語音同影片體驗。一個喺 token minting 過程入面漏咗嘅欄位唔應該削弱佢嘅能力——但開發者一定要確保自己嘅實作係完整嘅。

呢篇文章係根據 27 個提供嘅來源做事實核查，包括 Google 官方文件、社群論壇討論同研究員嘅原文。研究員嘅關鍵講法未能喺官方來源得到獨立證實。