東葛.dev #8

Transcript

1. Cookie Theftに備える 2025/08/30 東葛.dev #8
2. 🐙自己紹介 - ▪▪です - https://bsky.app/profile/736b.moe - https://x.com/shiomiyan - オシゴト: ウェブセキュリティ - プライベート - 冬はスノーボード - それ以外は軽い登山・ハイキングなど... - 初東葛.devです 早朝の尾瀬

3. ウェブセキュリティな話をします ※キャッチアップしたてなので、お手柔らかに...
4. 🍪Cookie Theft（唐突） - 認証済みCookieを窃取し、利用者になりすます - 手口は様々 - フィッシング攻撃 - Web3 のマルウェアが話題なので解析してみた | zenn.dev - 北朝鮮を背景とするサイバー攻撃グループ TraderTraitor による 暗号資産関連事業者 を標的としたサイバー攻撃について - サプライチェーン攻撃 - Popular npm linter packages hijacked via phishing to drop malware - 標的端末でマルウェアを実行できさえすれば何でもいい - マルウェアでクレデンシャルかき集めて攻撃者サーバーにポイ🤾 - 収穫したCookieは💰になる - UXを考えると、有効期限の長いCookieを発行しがち
5. 🦹Cookieを盗む - 結構簡単 - 実態はファイルシステムに書き出されている - ブラウザでなくともユーザー権限で参照できるし、解読可能 参考: The Current State of Browser Cookies
6. アプリガチガチだけど利用者が侵害されるケース - アプリの認証はガチガチに実装できる（Passkey使うとか） - 攻撃者が利用者の認証済みCookieを使ってアプリにアクセス すれば、そのユーザーになれる - どれだけ認証を固めても突破される - 事象自体は「認証済みCookieで認証できる」という話 - → それはそう - 被害を抑えることはできる 👉 Device Bound Session Credentials (DBSC)
7. Device Bound Session Credentials - 認証時の端末以外でCookieを使い続けられないように する仕組み - 盗まれたあとのリスクを下げよう、という感じ - 認証時に端末とCookieを紐づける（デバイスバインディング） - 認証Cookieは短命（Max-Age=600とか）にして、期限が切れ たらリフレッシュ、リフレッシュに失敗したら再認証する - Chromeのフィーチャーフラグを有効にすれば使える（W3C Working Draft）
8. DBSCを絡めたCookie発行のフロー
9. セッション開始 サーバーはブラウザにセッション開始を知らせる HTTP/1.1 200 OK
 Sec-Session-Registration: (ES256 RS256);path="/startsession";challenge="xyz" ブラウザはサーバーに秘密鍵で署名したJWTを返す POST /startsession HTTP/1.1
 Host: auth.example.com
 Sec-Session-Response: <JWT proof> // Header
 {
 "alg": "<Signature Algorithm>",
 "typ": "dbsc+jwt",
 }
 // Payload
 {
 "aud": "<URL of this request>",
 "jti": "<challenge value>",
 "iat": "<unix timestamp>",
 "key": "<public key JWK>",
 ...
 }

10. セッション開始 サーバーはブラウザに、認証Cookieとその期限・リフレッシュに 関する指示を返す（ブラウザはこれを記憶する） HTTP/1.1 200 OK
 Content-Type: application/json
 Set-Cookie: auth_cookie=abcdef0123; Max-Age=600; Secure; HttpOnly
 {
 "session_identifier": "session_id",
 "refresh_url": "/RefreshEndpoint",
 "credentials": [{
 "type": "cookie",
 "name": "auth_cookie",
 "attributes": "Domain=example.com; Path=/; Secure; HttpOnly; SameSite=None"
 }]
 }

12. リフレッシュ Cookieの期限が切れると、ブラウザはサーバーに更新をリクエス トする POST /RefreshEndpoint HTTP/1.1
 Host: auth.example.com
 Sec-Session-Id: session_id
 サーバーはブラウザに鍵を所持しているかどうかを確認する HTTP/1.1 403 Forbidden
 Sec-Session-Challenge: "challenge_value";id="session_id"
 

13. リフレッシュ ブラウザはサーバーに秘密鍵で署名したJWTを返す POST /RefreshEndpoint HTTP/1.1
 Sec-Session-Response: <JWT proof>
 サーバーはJWTを検証し、認証Cookieを再発行する HTTP/1.1 200 OK
 Set-Cookie: auth_cookie=xyz123; Max-Age=600; Secure; HttpOnly 以下ループ🔁
15. 個人の感想 - 長期間有効な認証Cookieを発行する必要がなくなるので、一 定の軽減効果は見込めそう - セッション有効期限が短くてもUXを損なわない - 一方で、フィッシングなどアカウントハイジャックは、やられ るときは一瞬でやられるらしい - 短命Cookieでどの程度悪用を減らせるのかは気になるところ - 売りにくくはなるが、その一瞬で悪用するだけになるのでは、という疑問？ - Explainerでも言及はされているので、それでも一定の効果がある、とい うことなのだと思う: Note, however, that the definition of "long-lived" depends upon the configured refresh period; within that period, attackers may continue to have short-lived access to any established sessions. - フレームワークに任せることができるとよい
16. 参考記事など - Cookie Theft 対策と Device Bound Session Credentials | blog.jxck.io - Device Bound Session Credentials | w3c.github.io - GitHub - w3c/webappsec-dbsc - GitHub - drubery/dbsc-test-server - Cookie Theft Mitigation - OWASP Cheat Sheet Series - Phishing campaign targets YouTube creators with cookie theft malware | blog.google
17. fin.