Cookie Theft 対策と Device Bound Session Credentials

マルウェア対策

Cookie はあくまでブラウザがローカルに保存している値であるため、ユーザの権限でインストールされたマルウェアは、保存されたファイルにアクセスできてしまうのだ。

なお、昔のブラウザは、それこそ平文テキストで保存されていたりもしたが、さすがに今はそこまで簡易ではない。

例えば Chrome は様々なデータをローカルの SQLite に保存することが多いが、Cookie に関しては Mac の Keychain, Linux の Kwallet など、アプリからしかアクセスできない安全な領域に保存している。

ところが Windows は、DPAPI というログインユーザ権限で実行されたアプリからはアクセスできてしまう領域にあるため、マルウェアによる窃取の危険性があった。

そこで、Windows でも App-Bound Encryption という機能で、これを保護するよう変更が入った。

• Improving the security of Chrome cookies on Windows
  • https://security.googleblog.com/2024/07/improving-security-of-chrome-cookies-on.html

DMM の攻撃発覚が 2024/3 で、このエントリが 2024/7 公開なので、事件が契機だったのか?と勘ぐってしまったが、作業のタイムラインを見ると 2021 年頃から継続的に作業をしているので、たまたま重なっただけのようにも見える。

• add application bound encryption primitives for chrome [40227925] - Chromium
  • https://issues.chromium.org/issues/40227925

事件の詳細は公開されている以上にわからないが、もし仮に Ginco の社員が使っていたのが Windows Chrome であり、この変更が間に合っていたら 482 億の流出が防げていた可能性があるのなら、このパッチのもたらす影響の大きさがよくわかる。

フィッシング対策

マルウェアよりも簡単なのは、ユーザの方を騙す手口だ。(DMM の攻撃も、ソーシャル経由ではあるが)

フィッシングサイトでログイン画面を偽装し、ID/Password を窃取する方法は知られていたが、二段階認証等があれば Password だけを盗まれても攻撃のリスクは減らせる。しかし、入力された ID/Password を裏で Proxy して本サイトに転記、同様に TOTP Token などもユーザに求めてそれを転記すれば、フィッシングサイトの裏にいる攻撃者が、ログイン済みの Cookie を受けとれる可能性もある。

ユーザは本サイトにリダイレクトしておけば、「なんかログインできなかった」ともう一度正規のログインを行うだけなので、攻撃されたことすら気づけないかもしれない。

ドメイン名を見て偽のサイトであることに気づくのが、ユーザができる第一の策だ。長いサブドメインを使って、部分的に本物に見せかける攻撃を防ぐために、モバイルブラウザが eTLD+1 のみの短縮表示を始めたのも、こうした理由が大きい。

それでも、人間の注意には限界があるので、各ベンダはパスワードマネージャを推奨し、機械的に偽ドメインに気付けるようにユーザへの啓蒙を進めている。パスワードマネージャの普及が求められるのは、簡単な文字列が再利用されるのを防ぐだけではない。Passkey 普及のゴールも、どちらかというとパスワードマネージャの普及にあると筆者は考えている。

Cookie Theft 対策

Cookie が Bearer Token である以上、サーバが受け取った Cookie が有効なものであっても、それが窃取されたものかどうか、確信を持つことはできない。

そこで、Session に紐づけてメタ情報を保存しておき、ユーザの行動に発生する変化を監視する方法が知られている。

具体的には以下のような情報を用いる。

• IP
• User-Agent
• Accept
• Accept-Language
• Sec-Fetch-*

これらの値をリクエストから収集し、Cookie を発行した時点と値が変わっていれば、それは窃取した他のユーザから使われている可能性が高い。

もちろん、移動すれば IP は変わるし、アップデートすれば User-Agent は変わる。つまり、偽陽性があるため確実な検出はできないが、再認証や CAPTCHA を挟むことで安全側に倒し、リスクを低減する方式だ。

(Private Relay を有効にしていると、Google サーチで CAPTCHA が頻出するなど、不便もあるため閾値は難しいが。)

この手法について具体的な施策は、あまり公開されることがなかった。しかし、去年 Slack が、タイムスタンプなどの要素も追加した、より強固な対策の実施内容を共有しているため参考になる。

• Catching Compromised Cookies - Engineering at Slack
  • https://slack.engineering/catching-compromised-cookies/

Demonstrating Proof-of-Possession in the Browser Application (BPoP)

Microsoft は DPoP に似た BPoP というプロトコルを提案していた。といっても、Explainer を書いただけで終わっている。

• MSEdgeExplainers/BindingContext/explainer.md at main · MicrosoftEdge/MSEdgeExplainers
  • https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/BindingContext/explainer.md

これは、ほぼこのあと解説する DBSC と同じようなものであり、すでに MS は DBSC の方に協力する方向になっているようなので、この仕様の解説は省く。

• DBSC (Device Bound Session Credentials) · Issue #106 · WICG/proposals
  • https://github.com/WICG/proposals/issues/106#issuecomment-1624111068
• Device Bound Session Credentials · Issue #912 · mozilla/standards-positions
  • https://github.com/mozilla/standards-positions/issues/912#issuecomment-2420716960

TPM による管理

通常、TLS の鍵、特に CA や GAFA レベルのサービスで用いる秘密鍵は、漏洩時の影響が大きすぎるため「プルトニウムと同等のセキュリティレベルで扱う」と冗談めいて言われるくらい、厳重に管理される必要がある。そこで、鍵の生成は一般に行われる OpenSSL の genrsa のようなカジュアルな方法ではなく、専用ハードウェアモジュールの中で行われる。

このようなモジュールは HSM (Hardware Security Module) と呼ばれ、内部で生成された秘密鍵は、そもそも取り出すことができない。もし壊して取り出そうとすると、鍵そのものが失われる(耐タンパ性)。署名等の計算が必要な場合は、モジュールに対してリクエストすると、鍵を用いた計算結果が中で行われ、計算結果だけが返ってくるといった仕組みだ。これなら、鍵の窃取に対して堅牢になる。しかし、こうしたモジュールは非常に高価で、扱うのも専門業者くらいだった。

ところが、近年ではデバイスにおける TPM (Trusted Platform Module) の実装が広がっている。これは、基盤に埋め込まれ隔離されたハードウェアで、秘密鍵を生成/管理できる、安価な HSM のようなものと言える。

現状は、全てのデバイスが TPM を持っているとは限らないが、Win11 からは TPM を持つことが必須になり、Chrome の調査では Win ユーザの 60% 程度は TPM が利用できる状態にあると報告され、徐々に普及が進んでいると言える。

もし TPM を持たないデバイスの場合は、ソフトウェアでエミュレートすることでフォールバックが可能だ。そちらは TPM ほど安全ではないにせよ、全体のセキュリティの底上げにはなる。

もちろん、TPM に対して署名を依頼することは他のユーザ(特に、より権限の高いユーザ)でも可能であり、攻撃を完全には防げない。しかし、そのような悪意のあるアプリの動きは、マルウェアとして検知するのがある程度容易であるため、総合的には対策が可能とされている。

少なくとも、この仕組みを Cookie に持ち込めれば、従来よりはかなり安全になるだろう。

Sec-Session-Registration

ここでいう Session の開始は、ログインフローの最後に Authorized Session が開始する時点などを想定している。

つまり、ログイン認証のレスポンスで Sec-Session-Registration を返すことで、クライアントに鍵ペアの生成をリクエストできる。

HTTP/1.1 302 Found
Location: /
Sec-Session-Registration: (RS256 ES256);challenge="challenge_value";path="session"

構造は SFV になっており、最初は暗号方式のリストから始まり、後で用いるチャレンジと、エンドポイントのパスが含まれている。

Sec-Session-Response

レスポンスを受け取ったクライアントは、TPM で生成した鍵を JWT でシリアライズし、Sec-Session-Response に付与して、先程の指定したエンドポイントにリクエストする。body はない。

ブラウザが内部的に送るリクエストのため、Dev Tools の Network タブに今は出ない。早く内部デバッガ (chrome://dbsc-internals)が欲しいところだ。

POST /session HTTP/1.1
Host: example.com
Sec-Session-Response: eyJ...

実際に送られてきた JWT は以下のようなものだった。

// Header
{
  "typ": "JWT",
  "alg": "RS256"
}
// Payload
{
  "aud": "https://example.com/session",
  "jti": "challenge_value",
  "iat": "1736267817",
  "key": {
    "e": "AQAB",
    "kty": "RSA",
    "n": "oPJngC..."
  },
  "authorization": ""
}
// Signature
"gkkfn2VDUQzJHv7..."

この鍵をサーバ側で保存する。

---

TODO: ここから下はまだ Chrome には実装されてなかったため、挙動が確認できていない。

https://github.com/drubery/dbsc/issues/88#issuecomment-2591379358

現状は、仕様ベースで解説し、挙動が確認でき次第更新する。

Session Registration Instructions JSON

このリクエストに対し、サーバは以下のような JSON を body で送る。

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 65535
Set-Cookie: __Host-session-id=deadbeef; Path=/; Secure; HttpOnly; Max-Age=604800

{
  "session_identifier": "b434736b1daa31f7",
  "refresh_url": "/refresh",
  "scope": {
    "origin": "example.com"
  },
  "credentials": [{
    "type": "cookie",
    "name": "__Host-session-id",
    "attributes": "Path=/; Secure; HttpOnly; Max-Age=604800"
  }]
}

ここで Set-Cookie する Cookie は、従来の Cookie と同じだ。

つまり、従来の Cookie のデプロイと互換性があり、セッション管理自体を新しいヘッダなどに移行する必要はない。

Refresh Request

この Cookie の期限が切れたあと、Cookie を必要とするリクエストを実施する際に、ブラウザは DBSC の Refresh をサーバに対して実施することになる。

つまり、Max-Age が経過した後に / にアクセスする場合は、そのアクセスを一旦保留して、裏側で先程指定された refresh_url である /refresh に以下のようなリクエストを行う。

POST /refresh HTTP/1.1
Host: example.com
Sec-Session-Id: b434736b1daa31f7

これが、「割り当てられた Session の Credential の Refresh」を要求している。

サーバはこれに対して、検証用の Challenge を返す。

HTTP/1.1 401 Unauthorized
Sec-Session-Challenge: "challenge_value";id="b434736b1daa31f7"

クライアントは、秘密鍵を用いてこれに応答する。

POST /refresh HTTP/1.1
Sec-Session-Response: JWT proof

検証に成功すれば、再度 Set-Cookie することで Cookie を更新することができる。

レスポンスとして、設定時と全く同じ JSON を返すことで更新が可能だ。

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 65535
Set-Cookie: __Host-session-id=deadbeef; Path=/; Secure; HttpOnly; Max-Age=604800

{
  "session_identifier": "b434736b1daa31f7",
  "refresh_url": "/refresh",
  "scope": {
    "origin": "example.com"
  },
  "credentials": [{
    "type": "cookie",
    "name": "__Host-session-id",
    "attributes": "Path=/; Secure; HttpOnly; Max-Age=604800"
  }]
}

これを受け取ったクライアントは、保留していたリクエストをすべて送信することになる。

また、このリクエストはクライアントが Refresh を要求してこなくても送信できるため、期限が切れる前に Credential を新しくしておくことで、リクエストの保留を避けることも可能だ。

この Refresh の要求をサーバのタイミングでできることは、単なる更新だけでなく、最初に問題視した「Cookie を送ってきているのは想定したクライアントか?」を確認する手段に使うことができることを意味する。