Googleは、Windows版Chrome 146でDevice Bound Session Credentials (DBSC)保護をロールアウトした。
macOSユーザーは、まだ発表されていない将来のChromeリリースでこのセキュリティ機能の恩恵を受けることになる。
この新しい保護機能は2024年に発表され、ユーザーのセッションをコンピュータのセキュリティチップ（WindowsではTPM（Trusted Platform Module）、macOSではSecure Enclave）など、特定のハードウェアに暗号的にリンクさせることで機能します。
機密データを暗号化・復号化するための固有の公開鍵・秘密鍵はセキュリティ・チップによって生成されるため、マシンからエクスポートすることはできない。
これにより、セッションデータを保護する一意の秘密鍵がマシンからエクスポートできないため、攻撃者が盗んだセッションデータを使用することができなくなる。
「新しい短命のセッション・クッキーを発行するには、対応する秘密鍵をクロームがサーバーに所有していることを証明する必要があります」とグーグルは今日の発表で述べています。
この鍵がなければ、流出したセッション・クッキーは期限切れとなり、攻撃者にはほとんど使えなくなります。
ソースはこちら：Google
セッション・クッキーは認証トークンとして機能し、通常はより長い有効時間を持ち、ユーザ名とパスワードに基づいてサーバサイドで作成されます。
サーバはセッションクッキーを識別のために使用し、ブラウザに送信します。ブラウザはオンラインサービスにアクセスするときにセッションクッキーを提示します。
セッションクッキーは、認証情報を提供することなくサーバへの認証を可能にするため、脅威行為者はセッションクッキーを収集するために infostealer と呼ばれる特殊なマルウェアを使用します。
Googleによると、LummaC2のような複数のinfostealerマルウェアファミリーは、「これらの認証情報を採取するのがますます巧妙になってきており」、ハッカーがユーザーのアカウントにアクセスすることを可能にしています。
「重要なのは、一度洗練されたマルウェアがマシンにアクセスすると、ブラウザが認証クッキーを保存しているローカルファイルやメモリを読み取ることができるということです。その結果、どのオペレーティング・システムでも、ソフトウェアだけでクッキーの流出を防ぐ信頼できる方法はありません。
DBSCプロトコルは設計上プライベートであるように構築されており、各セッションは個別のキーによってバックアップされています。これは、ウェブサイトが同じデバイス上の複数のセッションまたはサイトにわたってユーザーの活動を相関させることを防ぎます。
さらに、このプロトコルは、所有証明に必要なセッションごとの公開鍵のみを必要とする最小限の情報交換を可能にし、デバイス識別子を漏らしません。
Oktaを含む複数のウェブ・プラットフォームと提携し、DBSCの初期バージョンを1年間テストした結果、Googleはセッション盗難イベントの顕著な減少を確認した。
グーグルは、オープンなウェブ標準としてDBSCプロトコルを開発するためにマイクロソフトと提携し、”ウェブセキュリティを担当する業界の多くから “意見を得た。
ウェブサイトは、既存のフロントエンドとの互換性を犠牲にすることなく、専用の登録および更新エンドポイントをバックエンドに追加することで、より安全なハードウェア結合セッションにアップグレードすることができます。
ウェブ開発者は、DBSC実装の詳細についてGoogleのガイドを参照することができる。仕様書はWorld Wide Web Consortium (W3C)のウェブサイトから入手可能であり、説明書はGitHubにある。
.ia_ad { background-color：#width: 95%; max-width: 800px; margin: 15px auto; border-radius: 8px; border：1px solid #d6ddee; display: flex; align-items: stretch; padding: 0; overflow: hidden; }：0; overflow: hidden; } .ia_lef { flex: 1; max-width: 200px; height: auto; display: flex; align-items: stretch; } .ia_lef a { display: flex; width: 100%; height: 100%; } .ia_lef a img { width: 100%; height: 100%; border-radius: 8px 0 0 8px; margin: 0; display: block; } .ia_rig { flex: 2; padding：display: flex; flex-direction: column; justify-content: center; } .ia_rig h2 { font-size: 17px !important; font-weight: 700; color：#line-height: 1.4; font-family：margin: 0 0 14px 0; } .ia_rig p { font-weight: bold; font-size: 14px; margin: 0 0 clamp(6px, 2vw, 14px) 0; } .ia_button { background-color：#border：1px solid #3b59aa; color: black; text-align: center; text-decoration: none; border-radius: 8px; display: inline-block; font-size: 16px; font-weight: bold; cursor: pointer; padding：width: fit-content; } .ia_button a { text-decoration: none; color: inherit; display: block; } @media (max-width: 600px) { .ia_ad { flex-direction: column; align-items: center; } .ia_lef { max-width: 100%; } .ia_lef a img { border-radius: 8px 8px 0 0; } .ia_rig { padding：15px;
width: 100%;
}
.ia_button {
width: 100%;
margin: 0px auto;
}
}
自動ペンテストは6面のうち1面のみをカバーする。
自動ペンテストはパスの存在を証明する。BASは、あなたのコントロールがそれを止めるかどうかを証明します。ほとんどのチームは、一方を実行し、もう一方を実行しない。
このホワイトペーパーは、6つの検証サーフェスをマッピングし、どこでカバーが終了するかを示し、実務者にあらゆるツール評価のための3つの診断質問を提供します。
Comments