Googleはかねてより、ハードウェアに紐づけられた高度な認証セキュリティフレームワークのテストを進めてきました。そしてこのたび、同アーキテクチャが「Device Bound Session Credentials（DBSC）」として正式にリリースされました。ただし、本機能を有効化するには、各ウェブサービスの管理者が主体的に実装を行う必要があります。対応が完了すれば、たとえセッションCookieが盗まれても、攻撃者にとって完全に無効なデータとなります。その結果、不正に入手したクレデンシャルを使ったアカウント乗っ取りを根本から防ぐことができます。
ソフトウェアのみによる防御の限界
ユーザーは気づかないうちに、悪意のある拡張機能やソフトウェアを自分の環境に取り込んでしまうことが少なくありません。こうした不正なアプリケーションは、ブラウザのメモリからセッショントークンをひそかに収集します。サイバー犯罪者はこの取得したクレデンシャルを使い、パスワードによる従来の防御を難なく突破します。さらに、こうした手口は組織的に大規模展開され、盗んだセッション情報を大量売買する闇市場として急速に成長しています。
通常のOSには、ソフトウェア防御だけでトークン窃取を防ぐ仕組みが本来的に備わっていません。これまでセキュリティチームは、侵害後の不正利用パターンを検知するヒューリスティクスを頼りにセッションハイジャックへの対処を行ってきました。しかし残念ながら、巧妙な攻撃者はこうした事後検知の仕組みを容易にかわしてしまいます。DBSCはこの状況を一変させます。受動的な監視から積極的な予防へと防御の軸足を移すことで、ウェブ全体のセキュリティを根本から変えるものです。このプロトコルにより、流出したデータは不正な第三者にとって一切の利用価値を持たなくなります。
暗号によるデバイスバインディングの仕組み
このプロトコルは、認証セッションを暗号技術によって特定の物理デバイスに紐づけます。具体的には、Windows TPMやmacOSのSecure Enclaveといったオンボードのハードウェアセキュリティモジュールを利用します。これらの専用モジュールは、外部に持ち出すことのできない固有の暗号鍵ペアを生成します。
シームレスなバックグラウンド処理
新しいセッションCookieが発行される際には、Google Chromeが秘密鍵の所持を証明する必要があります。この秘密鍵はハードウェア上に保存されており、遠隔の攻撃者が外部に持ち出すことは不可能なため、仮にトークンが盗まれても即座に無効となります。
さらに、この構成によりウェブ開発者は専用のバックエンド評価APIを導入することもできます。ハードウェアに紐づいたセッション管理への移行も、フロントエンドとの完全な互換性を維持したまま行えます。複雑な暗号鍵のローテーションはブラウザが裏側で自動処理するため、ウェブアプリケーション側は通常のCookieと同じ感覚で扱えます。
導入手順とドキュメントガイド
アカウントの安全性を最大化したいウェブ管理者は、まずGoogleが公開しているオープンソースの実装ドキュメントを参照することをお勧めします。その上で、バックエンドの本番サーバーに対応した認証ポリシーを展開する必要があります。この防御策を適切に実装することで、セッションハイジャックの脆弱性を完全に無効化できます。
技術仕様ドキュメント
- W3Cアーキテクチャ仕様：DBSC技術仕様書
- Chromeエンジニアリングリファレンス：DBSCプラットフォームドキュメント
翻訳元: https://meterpreter.org/device-bound-session-credentials-dbsc-google/
