編按：本文綜合整理自 Ars Technica 原始報導、 Google 官方 Security Blog、 Scott Helme 技術部落格、 W3C DBSC 草案、 The Hacker News、 Flashpoint 與 Constella 資安報告，並加入 Siami 編輯部觀點與分析。
Google Chrome 近日正式將 Device Bound Session Credentials（DBSC，裝置綁定 Session 憑證） 推上 Windows 與 macOS 平台。這是一套以硬體信任根為基礎的 session cookie 保護機制，目標是把近年因 2FA、Passkey 普及而大量出現的「session cookie 竊取」攻擊鏈徹底打斷。
什麼是 Device Bound Session Credentials（DBSC）
DBSC 的核心概念是：把一把專屬於該 session 的非對稱加密金鑰，永久鎖在使用者裝置的硬體安全晶片內。Windows 裝置使用 TPM（Trusted Platform Module），macOS 與 iOS 裝置使用 Secure Enclave，其他平台則有對應的硬體金鑰儲存方案。
- 金鑰永遠無法匯出：即使惡意程式取得最高權限，也無法從 TPM 或 Secure Enclave 內把私鑰複製出來。
- 每次 session 配一把新金鑰：強化隱私，避免網站用同一把金鑰跨 session 追蹤使用者。
- 伺服器只收到公鑰：伺服器端只儲存公鑰，無法反向追蹤裝置指紋。
支援版本方面，Chrome 147 for Windows 與 Chrome 150 for macOS 已開始向部分使用者開放試驗。Google 在 2026 年 4 月時已先把 DBSC 推上 Chrome 146（Windows）的 GA 階段，這次是擴大到 macOS 與更多受測族群。
為什麼這件事重要
過去幾年，帳號外洩的攻擊手法出現了明顯的板塊遷徙：
過去幾年，帳號外洩的攻擊手法出現了明顯的板塊遷徙：
- 正面防線已強化：Passkey、FIDO2、2FA 大規模普及，純粹靠偷密碼、釣魚密碼的傳統攻擊成本越來越高。
- 攻擊者轉向後門：根據 Flashpoint 統計，2025 年全球有 1.8 億組憑證 從 580 萬台感染裝置外洩，其中 86% 的資料洩露事件含被盜 session cookies（DeepStrike 2025 報告）。
- 主流惡意程式主打 cookie：LummaC2、RedLine、StealC、Vidar 等家族把 SaaS、SSO、雲端控制台的 session cookie 當作首要目標。Constella 2026 Identity Breach Report 指出 感染到暗網市場平均 < 48 小時、勒索部署通常再 48 小時內發生。
換言之，使用者即使啟用 2FA，只要惡意程式偷走還在有效期內的 session cookie 並匯入攻擊者瀏覽器，整個登入狀態就會被接管。DBSC 正是要把這個「最後一哩」漏洞補起來。
DBSC 的運作機制
DBSC 不是 Token Binding 的重啟版，而是刻意避開當年 Token Binding 失敗的設計錯誤：
過去 Token Binding 失敗，是因為它要求修改 TLS 層，需要在 LB、CDN、reverse proxy 全面改基礎架構；DBSC 改在 HTTP 應用層運作，與現行基礎架構完全相容。
實際流程（DBSC 協議）：
- 伺服器透過
Secure-Session-Registrationheader 告訴瀏覽器：「我支援 DBSC，請到/auth/dbsc/register註冊」。 - 瀏覽器產生一對新的橢圓曲線金鑰（ES256），私鑰直接寫入 TPM/Secure Enclave。
- 伺服器儲存公鑰。
- 之後每次伺服器發出 short-lived session cookie（約 5 分鐘），Chrome 必須用 TPM 內的私鑰簽署伺服器給的 challenge 才能更新。
- 攻擊者即使偷走 cookie，沒私鑰就無法回應 challenge，session 立即失效。
Scott Helme（Report URI 創辦人）公開表示已在自家產品上部署 DBSC：「TPM / Secure Enclave 不會放出私鑰，攻擊者就是簽不了 challenge」，這是 DBSC 之所以能擋下 LummaC2 類攻擊的關鍵。
業界質疑：並非萬靈丹
並非所有資安專家都對 DBSC 完全買單。KnowBe4 旗下 CISO Advisor Roger Grimes 撰文指出 DBSC 仍存在攻擊面：
- 初始註冊階段可被釣魚：當使用者首次註冊 DBSC session 時，攻擊者仍可透過中間人攻擊註冊到自己的金鑰。
- TPM 並非萬能：部分舊裝置、虛擬機、嵌入式裝置缺乏 TPM，必須以軟體 fallback 處理。
- 使用者體驗摩擦：裝置遺失、韌體重灌、跨裝置登入時，仍需要設計 recovery 路徑。
Grimes 強調，DBSC 是「縱深防禦」的一塊拼圖，不能取代 anti-phishing 訓練、endpoint protection、identity provider 行為監控等其他機制。
數據解讀：攻擊面正在被 DBSC 縮小
把 2026 上半年的數據擺在一起看，DBSC 推出的時機剛好對應到攻擊高峰：
| 指標 | 數字 | 來源 |
|---|---|---|
| 2025 被盜憑證總數 | 1.8 億組 | Flashpoint |
| 2025 感染裝置數 | 580 萬台 | Flashpoint |
| 含 stolen cookies 的資料外洩占比 | 86% | DeepStrike 2025 |
| 感染到暗網市場平均時間 | < 48 小時 | Constella 2026 |
| 勒索軟體部署間隔 | < 48 小時 | Constella 2026 |
| LummaC2 微軟 2025 停押數 | 39.4 萬台 | Microsoft 2025 |
關鍵轉折：只要 DBSC 普及率到達一定程度，攻擊者即使偷到 cookie 也無法更新，session 在 5 分鐘內自動失效，整個 stolen-cookie-to-ransomware 鏈條的最後一環就會被切斷。
從產業生態來看，WebKit 已在 standards-positions 議題中正面看待 DBSC，Chromium 150 預設啟用、Electron 也已開出追蹤 issue。意味著未來 6-12 個月內，主流瀏覽器與嵌入式框架都可能會跟進。
對使用者與企業的實際意涵
- 一般使用者：使用 Chrome 147 (Windows) 與 Chrome 150 (macOS) 開啟支援 DBSC 的網站（目前以 Google Workspace 為主），可在 DevTools → Application 頁籤看到「device bound sessions」標籤。
- 企業 IT：建議在 Google Admin Console 中啟用 DBSC，並透過 Security Investigation Tool 監控 binding 狀態與 session 異常事件。
- 網站開發者：可參考 W3C DBSC Working Draft 與 Chrome 開發者文件，評估在自家登入流程加入 DBSC 支援。
- 資安監控團隊：stolen-cookie 監控仍是必要——DBSC 沒涵蓋的瀏覽器、作業系統、網站仍會是攻擊者的灰色地帶。
編按：本文綜合整理自 Ars Technica、 Google Security Blog、 Scott Helme 部落格、 W3C DBSC 草案、 The Hacker News、 Flashpoint、 Constella 2026 Identity Breach Report、 KnowBe4 部落格，並加入 Siami 編輯部觀點與分析。
網友熱門留言 (5)