Google DevSite RCE漏洞：Cookie與共用密鑰如何連成風險鏈

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-13

Google 的開發者網站共用平台 DevSite 被揭發曾出現遠端程式碼執行（RCE）漏洞。iThome 報道指出，研究人員 Simon Koeck 發現，未登入 Google 帳戶的攻擊者理論上可偽造獲網站接受的 Cookie，繼而令 server 執行非預期的程式邏輯。報道稱 Google 已在 10 月 7 日完成修補；現有資料並未顯示有用戶資料外洩或實際入侵個案，因此事件重點在於已被證實的漏洞鏈，以及它對網站架構設計帶來的警示。

受影響的並非單一頁面功能。iThome 指出，DevSite 為多個 Google 開發者網站所採用，而研究人員發現一把可在 developers.google.com 取得的簽章金鑰，亦能令 firebase.google.com、developer.android.com 及其他相關網站接受偽造 Cookie。這意味著，若一個共用平台將信任邊界處理得過於寬鬆，原本看似局限於單一網站的缺陷，便可能隨平台覆蓋範圍擴大。

漏洞不是由單一錯誤造成

這宗事件的關鍵，在於數個本應彼此分隔的設計決定被串連起來。iThome 報道稱，Koeck 在檢視 DevSite 的 OAuth 登入程序時，注意到連線階段 Cookie 的大小約為 1,200 位元組，與一般只承載 CSRF 權杖及登入後跳轉地址的需要不相稱。進一步分析後，他發現 Cookie 內含未加密的 OAuth 用戶端密鑰。將敏感憑證交予瀏覽器保存，已令其暴露面大幅增加；若該憑證同時可被用作驗證資料真偽，風險便由「資料洩露」升級為「信任被偽造」。

報道所述的另一個問題，是 Cookie 簽章與當中存放的 OAuth 用戶端密鑰使用同一把密鑰。簽章的本意是讓 server 分辨資料有否被竄改，但這項保護的前提是簽章金鑰絕不可被客戶端取得。一旦密鑰被寫入客戶端可讀取的 Cookie，攻擊者便可能自行產生看似有效的資料。從設計角度看，這不是加密演算法強度不足，而是密鑰用途沒有分離：同一項機密同時負責身分流程資料與完整性驗證，令防線失去意義。

pickle 將偽造資料變成執行風險

單憑可偽造 Cookie 未必必然導致 RCE，但 DevSite 的處理方式補上了最危險的一環。iThome 指出，網站在接收 OAuth 登入回呼時，會透過 Python 的 pickle 模組還原 Cookie 內的資料。pickle 適合在可信任環境保存及讀回 Python 物件，卻不應用於可由外部人士控制或偽造的輸入；其反序列化過程可觸發物件指定的行為，因而不只是把文字或欄位「讀回」那麼簡單。

Koeck 的驗證方式亦界定了報道可確認的範圍。iThome 報道稱，研究人員為免影響正式系統，沒有執行系統指令，而是安排 server 延遲數秒回應，再以回應時間改變確認指定函式確有被執行。這種概念驗證足以支持 RCE 風險的判定，但不等同已展示資料被取走、帳戶被接管或其他後續影響。對閱讀漏洞資訊的人而言，分清「可執行的技術風險」與「已觀察到的實際損害」，是評估事件嚴重性時不可省略的一步。

共用平台放大密鑰管理代價

從 iThome 所描述的跨網域 Cookie 接受情況推論，DevSite 的平台化優勢同時帶來集中的風險：共用元件能減少重複開發，但只要簽章金鑰、驗證規則或 session 格式被多個站點沿用，一處失守就可能擴展至多個服務。這不代表所有共用元件都不安全；問題在於不同網域、不同服務與不同權限層級，是否仍被同一個秘密與同一套信任規則綁定。密鑰輪換、用途隔離與服務範圍限制，在這類架構中不只是營運細節，而是限制事故半徑的安全控制。

對開發團隊來說，事件可轉化為一輪具體檢查。首先，瀏覽器端不應持有可用作簽署、驗證或取得高權限資源的秘密；即使資料經簽署，也應假定 Cookie 的內容可被看見及嘗試修改。其次，驗證資料完整性的密鑰，應與 OAuth 用戶端憑證及其他用途的密鑰分開管理，並按服務或環境縮小適用範圍。最後，任何由 client 帶回的資料，即使外觀上像是由自家系統產生，也不宜交由不安全的反序列化機制直接還原。

修補後仍要追問平台邊界

iThome 報道稱，Koeck 在 8 月 6 日向 Google 通報，Google 在 8 月 27 日核定 9 萬美元漏洞獎金，當中包括因報告質素而額外增加的 20%，並於 10 月 7 日完成修補。時間線反映研究人員通報、供應商確認及修正之間已有既定協調程序，但外界未能單從該報道得知修補採取了哪些技術措施，也未能確認所有曾使用相同設計的服務是否已完成獨立審查。

接下來值得觀察的，是 Google 會否進一步說明受影響 DevSite 網站的完整範圍，以及修補是否涉及淘汰 pickle、撤換或分割共用簽章金鑰，並使既有 session 失效。對營運 OAuth 登入、跨網域服務或共用網站平台的工程人員而言，這宗事件提供了一個直接案例：機密一旦送到 client、信任一旦跨站共用，再疊加不安全反序列化，原本各自可控的問題便會連成高影響漏洞鏈。