Google、Chrome 146でDBSCを一般提供 Cookie窃取対策を事後検知から事前防止

セキュリティニュース

投稿日時: 更新日時:

Google、Chrome 146でDBSCを一般提供 Cookie窃取対策を事後検知から事前防止

Googleは2026年4月9日、Device Bound Session Credentials、DBSCをChrome 146で一般提供に移行すると発表しました。あわせて、macOS向けにも今後のChromeリリースで対応を広げる方針を示しています。

DBSCは、認証セッションを端末固有の秘密鍵と結び付けることで、攻撃者がCookieを盗み出しても再利用しにくくする仕組みです。Googleは2024年4月に構想を公表して以降、Googleアカウントの一部セッションで先行運用しており、保護対象セッションではセッション窃取の大幅な減少を確認したとしています。

概要

今回の発表は、Cookieを使った従来のセッション管理そのものを置き換える話ではありません。Googleが打ち出したのは、既存のCookieベース認証を生かしながら、その継続利用に端末上の安全な鍵保有を求める仕組みを、実運用可能な形でWebに持ち込むという動きです。

ChromeはWindowsではTPM、macOSではSecure Enclaveのようなハードウェア保護領域を使って秘密鍵を保持し、サーバー側はその鍵の保有証明ができたときだけ短命なセッションクッキーを更新します。これにより、盗まれたCookieはすぐに期限切れとなり、攻撃者の側では価値が大きく下がります。

重要なのは、これはブラウザ単独で完結する防御ではない点です。DBSCを有効にするには、Webサービス側が登録用エンドポイントと更新用エンドポイントを実装し、ログイン後のセッションを短命Cookieへ移行できるようにする必要があります。

つまり、Chrome側の一般提供は大きな前進ですが、実際の保護効果はSaaS事業者、IdP、社内Webアプリ提供側の実装が進んで初めて広がります。

なぜ今、この対策が必要なのか

背景にあるのは、インフォスティーラーによるCookie窃取の深刻化です。Googleは、LummaC2のようなマルウェア群が既存の認証Cookieをブラウザのローカルファイルやメモリから抜き取り、攻撃者基盤へ送信する手口を問題視しています。

Cookieはログイン後の認証状態そのものを表すため、攻撃者はパスワードを知らなくても、さらに多要素認証を突破しなくても、被害者のアカウントへ入り込めます。

ここで厄介なのは、OSやブラウザの権限構造上、端末上でブラウザと同等レベルの権限を得たマルウェアに対し、ソフトウェアだけでCookieの持ち出しを完全に防ぐのは難しいという点です。そのため従来は、不正利用が起きた後にアクセス元や挙動の異常を検知する、いわば事後対応に頼らざるを得ませんでした。

DBSCはこの前提を変え、盗まれても使えない状態に近づけることで、防御の主戦場を事後検知から事前無力化へ移そうとしています。

DBSCとは

DBSCでは、ユーザーがログインするとChromeが端末内で公開鍵と秘密鍵のペアを生成し、秘密鍵を安全な領域に保持します。

サーバーはその公開鍵をセッションへ関連付け、以後は短命Cookieを使って認証状態を維持します。

短命Cookieが切れるたびに、Chromeはサーバーから受け取ったチャレンジに対して秘密鍵で署名し、正当な端末上にいることを証明します。サーバーがこれを検証できた場合にだけ、新しい短命Cookieが払い出されます。

この方式の実務上の利点は、フロントエンドや既存の認証ロジックを大きく変えずに導入しやすい点です。Chromeの開発者向け資料では、ログインフローにSecure-Session-Registrationヘッダーを追加し、登録エンドポイントで公開鍵の紐付けと短命Cookieへの切り替えを行い、さらに更新エンドポイントで鍵保有証明を検証する流れが示されています。

既存エンドポイントの大半には変更が不要とされており、段階的に組み込みやすい設計です。

一方で、制約もあります。DBSCはHTTPSが前提で、現時点ではPartitioned cookiesを対象にしていません。また、端末が安全な鍵保管に対応していない場合は、通常の挙動へフォールバックします。

加えて、登録時点ですでに高度なマルウェア感染が起きているケースでは、秘密鍵の保護が破られる可能性もゼロではありません。Googleも、これは標準的なCookie窃取より難度が高く検知しやすい攻撃になる一方、万能ではないと位置付けています。

プライバシー面の整理

端末に結び付けるという説明だけを見ると、デバイス識別やトラッキング強化を懸念する声は出やすいはずです。この点についてGoogleとW3C草案は、セッションごとに別の鍵を使う設計であり、同一端末上の別サイトや別セッションを横断して関連付ける用途には使えないとしています。

サーバーへ渡る情報も、鍵保有の証明に必要なセッション単位の公開鍵が中心で、恒久的なデバイス識別子やアテステーション情報を広く渡す設計ではありません。

この設計思想は、セキュリティ強化とプライバシー保護の両立を狙ったものとして評価できます。Cookie窃取対策の名目で、新たなフィンガープリンティング手段を増やしてしまえば、標準化や普及は進みません。

DBSCがW3CのWeb Application Security Working Groupでオープン標準として議論されているのは、その懸念を抑え込みながら実装可能性を高めるためでもあります。

今後のポイント

今回のリリースは、ChromeとGoogleアカウントでの先行利用から、より広いWebエコシステムへ広げる段階に入ったという意味があります。実際、GoogleはOktaを含む外部プレイヤーとOrigin Trialを進め、標準化もW3Cで継続しています。

今後の焦点は、Windows以外への対応拡大、SSOを含む複雑な企業環境への適用、そして対応サイトの裾野がどこまで広がるかです。