GoogleはChromeの脆弱性を修正し、盗まれたクッキーが無効になるようにしました
GoogleはChrome 146でクッキーセッションの盗難防止機能を追加しました
*新技術「Device Bound Session Credentials(DBSC)」は、ユーザーのアクティブなセッションをデバイスのハードウェアに暗号的に結び付けます。*
変更点
プラットフォーム | 保護の仕組み
---|---
Windows | Trusted Platform Module(TPM)モジュールを使用します。チップはエクスポートできないユニークなキーを生成します。新しいクッキーセッションは、Chrome がプライベートキーを所有していることを確認した後にのみ発行されます。
macOS | Secure Enclave(TPMの類似機能)を通じて将来のブラウザアップデートで保護が追加されます。
仕組み
1. 新しいセッションを作成すると、Chrome はセキュリティチップに紐付けられた公開鍵/秘密鍵ペアを生成します。
2. サーバーは公開鍵のみを受け取り、それを使ってクッキーセッションを暗号化します。
3. データへアクセスするには、クライアントが秘密鍵を所有していることを証明しなければならず、これは同じデバイス上でしか可能ではありません。
4. 攻撃者がクッキーを盗んでもチップにアクセスできない場合、そのセッションは即座に無効になります。
重要性
- セッションクッキーは認証トークンであり、ユーザーはパスワードを再入力せずにサービスにログインできます。
- LummaC2 のような情報収集型マルウェアはこれらのファイルとブラウザメモリを読み取りデータを盗みます。
- ソフトウェアベースの保護は常に有効とは限りません。攻撃者がマシンにアクセスできれば、任意の難易度のクッキーを取得できます。
DBSC はデータ交換を最小化します:公開鍵のみがサーバーへ送信され、デバイス識別子は隠されたままです。各セッションは個別のキーで保護されるため、異なるセッション間でユーザー活動を追跡することが困難になります。
テストとサポート
- Google は Okta を含む複数のウェブプラットフォームと協力して DBSC の初期バージョンをテストしました。
- セッション盗難の減少が顕著に確認されました。
- プロトコルは Microsoft と共同でオープンなウェブ標準として開発され、ウェブセキュリティ専門家から承認を得ています。
サイトへの導入方法
1. DBSC を利用するサインアップとクッキー更新ポイントをバックエンドに追加します。
2. 既存のフロントエンドには影響がなく、互換性は維持されます。
仕様は W3C のウェブサイトで入手可能で、詳細な実装ガイドは Google のドキュメントと GitHub リポジトリに掲載されています。
結論:Chrome 146 の新機能はクッキーセッションの盗難からより確実に保護し、それらをユーザーのハードウェアに結び付けます。これにより、盗まれたトークンはほぼ瞬時に無効化され、ウェブアプリケーション全体の安全性が向上します
コメント (0)
感想を共有してください。礼儀正しく、話題に沿ってお願いします。
コメントするにはログイン