遺漏的 live_connect_constraints 欄位

根據 Ferdiansyah 的文章，令牌產出的參考實作完全遺漏了 live_connect_constraints 欄位 。這個欄位本應包含一個 bidi_generate_content_setup 物件，用來將令牌綁定到特定的模型、系統指令和一組工具。

當 live_connect_constraints 為空或不存在時，任何約束都不會生效。取得令牌的攻擊者便可以發送一個客戶端控制的設定訊框（setup frame），任意指定想要的模型、系統提示和工具。由於伺服器沒有令牌綁定的數值可供驗證，便會接受攻擊者的設定。

重要提醒： 提供的資料來源並未包含 Google 官方關於 live_connect_constraints 的文件、CVE 編號或 Google 的安全公告來確認這項行為。此聲明來自 Ferdiansyah 的 Medium 文章，應視為未經官方證實但具合理性的資訊 。

影響：攻擊者能利用不受限的令牌做什麼？

如果這項漏洞為真，對任何在瀏覽器環境中使用 Gemini Live API 的應用程式都將造成嚴重後果：

• 透過工具進行沙盒程式碼執行 — Gemini Live API 的範例包含支援客戶端添加自訂工具 。能注入惡意工具定義的攻擊者，可能可以在應用程式的沙盒中執行程式碼。
• 運算資源濫用 — 被挾持的會話會消耗受害應用程式的配額與費用。由於短期令牌設計為一次性的連線使用，攻擊者還可以透過後端產出令牌的端點重複請求新令牌，導致費用飆升 。
• 提示詞竄改 — 控制設定訊框就等於控制系統指令。攻擊者可以重新利用這個會話來竊取敏感資訊、生成有害內容，或冒充受信任的代理 。
• 重複會話濫用 — Live API 會話有約 10 分鐘的連線限制 。攻擊者雖然需要重新連線，但使用同樣不受限的令牌流程，就能反覆挾持會話。

在 Google AI 論壇上，已有開發者回報短期令牌會忽略系統指令，以及在受限端點上無法如預期運作等問題，顯示整個生態系統仍在發展中 。

只需一個欄位的修補方式

Ferdiansyah 提出的修補方法非常直接：在產出令牌時，填入 live_connect_constraints.bidi_generate_content_setup 欄位，並包含三個數值：

1. model — 要使用的確切 Gemini 模型（例如 models/gemini-2.5-flash-native-audio-latest）。
2. system_instruction — 預期的系統提示，以包含 text 的 parts 結構呈現。
3. tools — 設為空陣列 [] 或僅包含明確允許的工具，以阻止客戶端注入。

以下是取自 Ferdiansyah 文章的示範性 Python 程式碼 ：

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 的描述，在正式環境使用前應先以實際 API 進行測試 。

尚未確認的部分

以下關鍵點在提供的資料來源中仍未獲得證實：

• 無官方 Google 文件確認 live_connect_constraints 的存在或其結構。
• 無 CVE 或安全公告發布。
• 無獨立第三方成功重現此漏洞的紀錄。
• 當 BidiGenerateContentConstrained 端點收到不受限令牌時的具體行為，在提供的官方參考資料中並無說明 。

開發者現在應該做的事

在 Google 發布官方公告之前，最安全的做法是將此漏洞視為合理威脅，並主動套用修補：

1. 稽核你的短期令牌產出程式碼 — 檢查後端是否有填入 live_connect_constraints 或其等效欄位。
2. 絕不暴露原始 API 金鑰 — 面對瀏覽器的連線一律使用短期令牌 。
3. 設定嚴格的令牌到期時間 — Google 建議將 newSessionExpireTime 設為約 60 秒，以限縮令牌被盜用的攻擊窗口 。
4. 在伺服器端驗證設定訊框 — 即使客戶端自行發送設定，你的後端也應強制執行預期的模型、提示和工具。
5. 監控異常行為 — 留意不尋常的會話模式，特別是來自同一個令牌的重複連線，或意料之外的工具呼叫。

Gemini Live API 是構建即時語音和視訊體驗的強大工具。令牌產出過程中一個遺漏的欄位不應破壞這項能力——但開發者必須確保其實作是完整的。

本文已根據 27 份提供的資料來源進行事實查核，包括 Google 官方文件、社群論壇討論以及研究員的原篇文章。研究員提出的關鍵主張在截稿前未能透過官方來源獨立證實。

遺漏的 live_connect_constraints 欄位

根據 Ferdiansyah 的文章，令牌產出的參考實作完全遺漏了 live_connect_constraints 欄位 。這個欄位本應包含一個 bidi_generate_content_setup 物件，用來將令牌綁定到特定的模型、系統指令和一組工具。

當 live_connect_constraints 為空或不存在時，任何約束都不會生效。取得令牌的攻擊者便可以發送一個客戶端控制的設定訊框（setup frame），任意指定想要的模型、系統提示和工具。由於伺服器沒有令牌綁定的數值可供驗證，便會接受攻擊者的設定。

重要提醒： 提供的資料來源並未包含 Google 官方關於 live_connect_constraints 的文件、CVE 編號或 Google 的安全公告來確認這項行為。此聲明來自 Ferdiansyah 的 Medium 文章，應視為未經官方證實但具合理性的資訊 。

影響：攻擊者能利用不受限的令牌做什麼？

如果這項漏洞為真，對任何在瀏覽器環境中使用 Gemini Live API 的應用程式都將造成嚴重後果：

• 透過工具進行沙盒程式碼執行 — Gemini Live API 的範例包含支援客戶端添加自訂工具 。能注入惡意工具定義的攻擊者，可能可以在應用程式的沙盒中執行程式碼。
• 運算資源濫用 — 被挾持的會話會消耗受害應用程式的配額與費用。由於短期令牌設計為一次性的連線使用，攻擊者還可以透過後端產出令牌的端點重複請求新令牌，導致費用飆升 。
• 提示詞竄改 — 控制設定訊框就等於控制系統指令。攻擊者可以重新利用這個會話來竊取敏感資訊、生成有害內容，或冒充受信任的代理 。
• 重複會話濫用 — Live API 會話有約 10 分鐘的連線限制 。攻擊者雖然需要重新連線，但使用同樣不受限的令牌流程，就能反覆挾持會話。

在 Google AI 論壇上，已有開發者回報短期令牌會忽略系統指令，以及在受限端點上無法如預期運作等問題，顯示整個生態系統仍在發展中 。

只需一個欄位的修補方式

Ferdiansyah 提出的修補方法非常直接：在產出令牌時，填入 live_connect_constraints.bidi_generate_content_setup 欄位，並包含三個數值：

1. model — 要使用的確切 Gemini 模型（例如 models/gemini-2.5-flash-native-audio-latest）。
2. system_instruction — 預期的系統提示，以包含 text 的 parts 結構呈現。
3. tools — 設為空陣列 [] 或僅包含明確允許的工具，以阻止客戶端注入。

以下是取自 Ferdiansyah 文章的示範性 Python 程式碼 ：

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 的描述，在正式環境使用前應先以實際 API 進行測試 。

尚未確認的部分

以下關鍵點在提供的資料來源中仍未獲得證實：

• 無官方 Google 文件確認 live_connect_constraints 的存在或其結構。
• 無 CVE 或安全公告發布。
• 無獨立第三方成功重現此漏洞的紀錄。
• 當 BidiGenerateContentConstrained 端點收到不受限令牌時的具體行為，在提供的官方參考資料中並無說明 。

開發者現在應該做的事

在 Google 發布官方公告之前，最安全的做法是將此漏洞視為合理威脅，並主動套用修補：

1. 稽核你的短期令牌產出程式碼 — 檢查後端是否有填入 live_connect_constraints 或其等效欄位。
2. 絕不暴露原始 API 金鑰 — 面對瀏覽器的連線一律使用短期令牌 。
3. 設定嚴格的令牌到期時間 — Google 建議將 newSessionExpireTime 設為約 60 秒，以限縮令牌被盜用的攻擊窗口 。
4. 在伺服器端驗證設定訊框 — 即使客戶端自行發送設定，你的後端也應強制執行預期的模型、提示和工具。
5. 監控異常行為 — 留意不尋常的會話模式，特別是來自同一個令牌的重複連線，或意料之外的工具呼叫。

Gemini Live API 是構建即時語音和視訊體驗的強大工具。令牌產出過程中一個遺漏的欄位不應破壞這項能力——但開發者必須確保其實作是完整的。

本文已根據 27 份提供的資料來源進行事實查核，包括 Google 官方文件、社群論壇討論以及研究員的原篇文章。研究員提出的關鍵主張在截稿前未能透過官方來源獨立證實。