裝置繫結工作階段憑證 (DBSC)

裝置繫結工作階段憑證 (DBSC) 會新增硬體支援的工作階段安全防護，進一步強化驗證機制。

Daniel Rubery
Daniel Rubery
José Luis Zapata

簡介

許多網站會使用存留時間較長的 Cookie 進行使用者驗證，但這類 Cookie 容易遭到工作階段劫持。裝置繫結工作階段憑證 (DBSC) 會新增一層硬體支援的安全防護，以降低這類風險，確保工作階段繫結至特定裝置。

本指南適用於在網路應用程式中維護驗證流程的開發人員。本文說明 DBSC 的運作方式，以及如何將其整合至網站。

DBSC 的運作方式

從高層次來看，DBSC 會導入與使用者裝置相關聯的加密金鑰配對。Chrome 會在登入期間產生這組金鑰，並將私密金鑰儲存在安全硬體中，例如信任平台模組 (TPM) (如有)。工作階段會使用短期 Cookie。其中一個 Cookie 過期時，Chrome 會先證明擁有私密金鑰，再重新整理 Cookie。這個程序會將工作階段連續性連結至原始裝置。

如果使用者的裝置不支援安全金鑰儲存空間，DBSC 會順利回復為標準行為，不會中斷驗證流程。

導入程序總覽

如要將 DBSC 整合至應用程式，您需要進行下列變更：

  • 修改登入流程，加入 Secure-Session-Registration 標頭。
  • 新增工作階段註冊端點，該端點必須：
    • 將公開金鑰與使用者工作階段建立關聯。
    • 提供工作階段設定。
    • 改用短期 Cookie。
  • 新增重新整理端點，處理 Cookie 續訂和金鑰擁有權驗證。

您現有的大部分端點都不需要變更。DBSC 的設計宗旨是提供加成效果，且不會造成干擾。

如果缺少或過期必要的短期 Cookie，Chrome 會暫停要求並嘗試重新整理 Cookie。這樣一來，應用程式就能繼續使用一般工作階段 Cookie 檢查，確認使用者已登入。由於這與一般驗證流程相符，因此 DBSC 只需要對登入邏輯進行少量變更即可運作。

導入步驟

本節將逐步說明如何對驗證系統進行必要變更，包括如何修改登入流程、處理工作階段註冊，以及管理短期 Cookie 重新整理。每個步驟都經過精心設計，可與現有基礎架構順暢整合。

實作步驟會遵循已登入使用者在 DBSC 啟用時的常見流程：登入時註冊，然後定期重新整理短期 Cookie。您可以視應用程式的工作階段敏感度，獨立測試及實作每個步驟。

顯示 DBSC 流程的圖表

1. 修改登入流程

使用者登入後，請回覆長期有效的 Cookie 和 Secure-Session-Registration 標頭。例如：

成功註冊工作階段後，系統會傳回下列 HTTP 回應標頭：

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

如果裝置支援安全金鑰儲存，Chrome 會在 JSON Web Token (JWT) 中使用公開金鑰，與 /StartSession 端點聯絡。

本例中的 auth_cookie 代表您的工作階段權杖。只要與工作階段設定中的 name 欄位相符，且應用程式中一律使用這個名稱，您就可以隨意命名這個 Cookie。

2. 實作工作階段註冊端點

在 /StartSession，您的伺服器應：

  • 將收到的公開金鑰與使用者工作階段建立關聯。
  • 以工作階段設定回應。
  • 以存留時間較短的 Cookie 取代存留時間較長的 Cookie。

在下列範例中，短期 Cookie 設定為 10 分鐘後到期：

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. 實作重新整理端點

短期 Cookie 過期後，Chrome 會啟動重新整理流程，證明私密金鑰的擁有權。這項程序需要 Chrome 和伺服器協調動作：

  1. Chrome 會將使用者的要求延後至您的應用程式，並傳送重新整理要求至 /RefreshEndpoint：

    POST /RefreshEndpoint HTTP/1.1
Sec-Secure-Session-Id: session_id

  2. 伺服器會傳回驗證問題：

    HTTP/1.1 403 Forbidden
Secure-Session-Challenge: "challenge_value"

  3. Chrome 會使用儲存的私密金鑰簽署驗證問題，然後重試要求：

    POST /RefreshEndpoint HTTP/1.1
Sec-Secure-Session-Id: session_id
Secure-Session-Response: <JWT proof>

  4. 伺服器會驗證簽署的證明，並核發更新的短期有效 Cookie：

    HTTP/1.1 200 OK

Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax

  5. Chrome 會收到重新整理的 Cookie，並繼續處理原先延遲的請求。

替代整合模式

為提升韌性，網站可以在短期 Cookie 旁新增第二個非 DBSC Cookie。這個長期有效的 Cookie 只會用於核發新的短期有效權杖，並協助區分真正未經驗證的要求和暫時性的 DBSC 失敗。

  • 即使 DBSC 失敗，長期有效的 Cookie 仍會保留。
  • 系統會使用 DBSC 重新整理短期 Cookie，且必須使用這類 Cookie 才能執行敏感作業。

這個模式可讓網站進一步控管邊緣案例的處理方式。

注意事項和備用行為

在下列情況下，Chrome 可能會略過 DBSC 作業，並傳送不含 DBSC 管理的短期 Cookie 的要求：

  • 由於網路錯誤或伺服器問題，無法連線至重新整理端點。
  • TPM 忙碌中或發生簽署錯誤。由於 TPM 會在系統程序之間共用，過度重新整理可能會超出其速率限制。
  • DBSC 管理的短期 Cookie 是第三方 Cookie，且使用者已在瀏覽器設定中封鎖第三方 Cookie。

在這些情況下，如果長期有效的 Cookie 仍存在，Chrome 就會改用這類 Cookie。只有在實作項目同時包含長期和短期 Cookie 時，這項備援機制才會生效。如果沒有，Chrome 會傳送要求，但不含 Cookie。

摘要

裝置綁定工作階段憑證可提升工作階段安全性，且對應用程式的影響極小。密碼金鑰會將工作階段與特定裝置綁定，進一步防範工作階段遭人盜用。大多數使用者都能享有這項優點，不會遇到任何中斷情況，而且 DBSC 會在不支援的硬體上順利回復。

詳情請參閱 DBSC 規格。