⽇本語ドメインが暴いた Cookie のブラウザ差

Ginza.js

Transcript

1. GINZA.JS #11 / LIGHTNING TALK ⽇本語ドメインが暴いた Cookie のブラウザ差 同じコードでも、Safari と Chrome で変わる結果について たてけん GMOペパボ‧新卒1年⽬ 01
2. ⾃⼰紹介 所属 出⾝ GMOペパボ ∕ エンジニア（新卒1年⽬） 2026年7⽉、ムームードメインに配属 愛知県 保有ドメイン Web 歴 たてけん GMOペパボ‧新卒1年⽬ 𝕏 @tateken_create 覇気.com Web は未経験で⼊社、配属2ヶ⽉⽬ 趣味 興味のあること 旅⾏ / お笑い / アニメ / イラスト AI エージェントを使った開発 zenn.dev/tateken ⼈数が思ったより多くて緊張しています😭 02
3. なぜ Cookie を選んだのか テーマ探しの旅 01 配属先のフロントは Nuxt JavaScript を触れそうという想定 → 03
4. なぜ Cookie を選んだのか テーマ探しの旅 01 02 配属先のフロントは Nuxt JavaScript を触れそうという想定 → メインのロジックは Rails や PHP 深く触れる場⾯は限定的 27PRのうち、Ruby 4,311⾏に対して、JavaScript 72⾏ 💦 03
5. なぜ Cookie を選んだのか テーマ探しの旅 01 02 配属先のフロントは Nuxt JavaScript を触れそうという想定 → メインのロジックは Rails や PHP 深く触れる場⾯は限定的 03 → jsのフォルダを⾒る中で ⾏き着いた先が、Cookie 前から気になってはいたが、よくわからず適当に許可していた 03
6. アジェンダ 01 Cookie の基礎 この後の話で使う3点のみに限定 02 ブラウザ差の発⾒ サブドメインを使った検証と、ブラウザごとの結果の相違 03 サードパーティ Cookie の現状 ブラウザごとの姿勢と、この1年の動き 04 CookieStore API 後継 API の登場と、返る中⾝の相違 05 AI と Cookie エージェント経由での⾒え⽅と、DBSC という⽅向 04
7. 01 CHAPTER Cookie の基礎 Cookie の概念と、この後の話で使う3点 01 Cookie の基礎 02 ブラウザ差の発⾒ 03 サードパーティ Cookie の現状 04 CookieStore API 05 AI と Cookie 05
8. Cookie とは サーバーがブラウザに預ける、⼩さなメモ HTTP そのものは前のやり取りを覚えない仕組み ログイン状態やカートの中⾝を保つために、ブラウザ側で値を持つ 01 02 03 サーバーが渡す ブラウザが保存する 次から⾃動で返る Set-Cookie ヘッダーで値を渡す → どのドメイン向けの値かを 添え て、端末に保管 → 条件に合うリクエストに、 ブラウザが⾃動で付与 どのリクエストに付くかを決めるのが属性 ここからの3点は、その属性の話 06
9. 基礎 ①｜届く範囲 Domain 属性の有無で変わる、Cookie の届く先 第2章の検証を読み解くための前提 Domain 指定なし a=1; path=/ 発⾏したホスト名と完全に⼀致するリクエスト にのみ送信 サブドメインには⼀切届かない Domain 指定あり a=1; domain=example.com; path=/ shop.example.com でも evil.example.com でも、 同 じ Cookie が読み書きできる状態 指定ドメインとその全サブドメインに到達 発⾏したホストにのみ到達 （host-only） 07
10. 基礎 ②｜サーバーに戻る情報 リクエストに載るのは name=value のみ RFC 6265 §4.2.2 送られるとき ｜ 値のみ 保存されるとき ｜ 属性つき Set-Cookie: session=abc; Domain=example.com; Path=/ → Cookie: session=abc Domain と Path は⾮送信 サーバー側から⾒えない、その Cookie の出どころ 08
11. 基礎 ③｜JavaScript からの⾒え⽅ document.cookie は、ただの⽂字列 読み書きはいずれも⽂字列操作、属性の取得は不可 Console >document.cookie "foo=1; bar=2; baz=3" 属性の取得を含む後継の API については、第4章で 09
12. 02 CHAPTER ⼿を動かしてわかったブラウザの挙動 サブドメインのcookie管理 01 Cookie の基礎 02 ブラウザ差の発⾒ 03 サードパーティ Cookie の現状 04 CookieStore API 05 AI と Cookie 10
13. きっかけ このサブドメイン売れるのでは？ 覇気.com 11
14. きっかけ このサブドメイン売れるのでは？ （名前）の.覇気.com 覇気.com （⾷べ物）の.覇気.com 11
15. きっかけ このサブドメイン売れるのでは？ （名前）の.覇気.com で簡単にできる！ 覇気.com （⾷べ物）の.覇気.com 11
16. きっかけ このサブドメイン売れるのでは？ （名前）の.覇気.com 適当に配って⼤丈夫？ セキュリティは？ 覇気.com （⾷べ物）の.覇気.com 11
17. きっかけ このサブドメイン売れるのでは？ （名前）の.覇気.com 適当に配って⼤丈夫？ セキュリティは？ 覇気.com （⾷べ物）の.覇気.com 全然悪⽤できることがわかった 11
18. 検証！ 隣のサブドメインから、同名の Cookie を差し込めるか shop.覇気.com evil.覇気.com 正規のサイト側 隣のサブドメイン側 sess=legit; path=/ ← sess=attacker; domain=覇気.com; path=/ 注⼊ Domain 指定なし shop ⾃⾝にしか届かない状態 親ドメイン指定 全サブドメインに届く状態 挙動の確認を⽬的とした、⾃⾝のドメイン上での検証 11
19. 検証の結果 Chrome では、2つが共存してしまうことを確認 name が同⼀でも、domain が異なれば別の Cookie として保存 Chrome 151  Console (shop.覇気.com) 実際のリクエストヘッダ cookie: sess=legit; sess=attacker >document.cookie.match(/sess=[^;]_/g) ["sess=legit", "sess=attacker"] どちらが正規の発⾏分か、サーバー側では判別不能 12
20. 検証の結果 Safari では、変化なし違う結果 Safari — Console (shop.覇気.com) >document.cookie.match(/sess=[^;]_/g) Safari ["sess=legit"] Domain 属性を無視し host-only として保存 evil ⾃⾝にしか届かない 注入した attacker は保存されていない エラーも警告も皆無 書けたように⾒えて、届く範囲だけに相違 13
21. 切り分けの結果 差の原因は、⽇本語表記！ domain の書き⽅だけを変え、他は同⼀条件で実⾏ ① domain=覇気.com ② domain=xn--7qwx14d.com Chrome 151 Chrome 151 ["x=PUNY", "x=HOSTONLY"] ["x=PUNY", "x=HOSTONLY"] Safari Safari ["x=HOSTONLY"] ["x=PUNY", "x=HOSTONLY"] punycode 表記であれば、Safari も Chrome と同じ挙動 14
22. 仕様の記述 仕様上、どちらが正しいとも判定できない状態 策定中のドラフト RFC 6265bis の記述 リクエスト元のホスト名 §5.1.2「U-label を A-label に変換せよ」＝ punycode 化の明⽰ Domain 属性の値 §5.6.3「⼩⽂字に変換せよ」のみ A-label 変換の規定は不在 Chrome の解釈 Safari の解釈 Domain 属性も punycode 化して受理 明⽂の裏づけは不在 ⽂字列として厳密に⽐較し、不⼀致のため host-only へ 同じコードでも結果は分かれ、仕様にも空⽩が存在 15
23. ここまでを踏まえて ブラウザ間の違いという観点で、 他も⾒てみる Domain 属性の1点だけで結果が分かれるなら、他にも同じような箇所があるはず！！！ NEXT  03 NEXT  04 サードパーティ Cookie CookieStore API ブロックするかどうかが、ブラウザごとに分かれる領域 同じ呼び出しでも、返る中⾝が違う領域 実際にAIと⼿を動かしながら⽣まれた興味！ 16
24. 03 CHAPTER サードパーティ Cookie の現状 ブラウザごとの姿勢と、この1年の動き 01 Cookie の基礎 02 ブラウザ差の発⾒ 03 サードパーティ Cookie の現状 04 CookieStore API 05 AI と Cookie 17
25. サードパーティ Cookie とは 閲覧中のサイト以外が発⾏する Cookie Cookie はドメインに紐づくため、経由したサイトを問わず同じ値が送信対象 同⼀の閲覧者 ↓ ↓ A社サイト 埋め込みが起点 ページ内の画像やタグが別ドメインへリクエストを送り、その先が Cookie を発⾏する構造 B社サイト ↓ 複数サイトに同じタグ どちらのサイトからも同⼀の発⾏元へ、同じ uid が⾃動的に送信 ad.example 双⽅から同⼀の uid が到達し、同⼀⼈物と識別できる 結果としての横断的な追跡 サイトをまたいだ閲覧の結びつけが成⽴ これが廃⽌議論の発端 18
26. ブラウザごとの姿勢 ここでも、ブラウザごとに分かれる対応 デフォルトでの扱いは三者三様 Safari 2020年〜 ブロック ITP により、デフォルトで全⾯的にブロック Firefox 2022年〜 分離 Total Cookie Protection により、サイトごとに別の保管箱へ分離 Chrome 存続（唯一） 廃⽌の宣⾔と延期の繰り返し デフォルトでの存続は Chrome のみ シェア最⼤の Chrome の判断が、全体の⾏⽅を握る構図 19
27. 2025年10⽉17⽇の発表 代替として⽤意された技術のほうが、廃⽌に Privacy Sandbox サードパーティ Cookie をやめても広告や計測が成り⽴つように、Google が⽤意してきた代替技術群 廃⽌する10個 継続する3つ Topics（興味カテゴリの推定）、Protected Audience（リ ターゲティング広告）、Attribution Reporting（成果計測） など CHIPS FedCM Private State Tokens 理由は「利⽤がほとんど広がらなかったため」 広告以外の⽤途で使われているもの 20
28. 起きたことの構図 サードパーティ Cookie の廃⽌のため、10個の代替技術を⽤意 ↓ サードパーティ Cookie は継続 ↓ 廃⽌のために作った10個が、先に廃⽌対象 同⽇、英国の競争当局（CMA）も4年間の監視を終了 21
29. その後の経過 2026年8⽉現在、その10個もなお Chrome 上に存続 Chrome 144（2026-01-13） ⾮推奨化 警告の表⽰のみで、動作は継続 当初の削除予定 Chrome 150（2026-06-30） 実際の Chrome 150 リリースノート "There are no deprecations or removals in this release." 背景は、API Owners による当初からの条件 ⾮推奨は承認しつつ、削除には利⽤率の低下の確認が前提 違うことは知っいたが、ここまでバラバラだとは思わなかった 22
30. 04 CHAPTER CookieStore API document.cookie の後継、そして再びブラウザ差の 話 01 Cookie の基礎 02 ブラウザ差の発⾒ 03 サードパーティ Cookie の現状 04 CookieStore API 05 AI と Cookie 23
31. 後継の API 1994年以来の⽂字列操作に、後継となる API 属性の取得、Promise ベースの操作、変更の購読までを標準で提供 cookieStore 3エンジンでの利⽤可否 87 Chrome / Edge await cookieStore.get('foo') await cookieStore.set({ name: 'foo', value: '1' }) Firefox 140（202506） Safari 18.4（202503） cookieStore.addEventListener('change', handler) Baseline「Newly available — Since June 2025」 24
32. 返る中⾝の相違 同⼀の呼び出しでも、返るプロパティの数に相違 同じ Object.keys(await cookieStore.get('x')) の結果 Chrome 151 — 8個 ["domain", "expires", "name", "partitioned", "path", "sameSite", "secure", "value"] Safari — 2個 ["name", "value"] Domain 指定の有無を問わず同一の結果 プライバシー上の判断 document.cookie 以上を返さない設計⽅針で、仕様側も Chrome を縮⼩版に合わせる変更をマージ済み 今回の経緯がなければそういったブラウザ間の差異に関して、AIに指⽰することもできなかった 25
33. 05 CHAPTER AI が Cookie を読める時代 ブラウザを操作するエージェントの登場と、その先の対策 01 Cookie の基礎 02 ブラウザ差の発⾒ 03 サードパーティ Cookie の現状 04 CookieStore API 05 AI と Cookie 26
34. エージェントから⾒た Cookie ブラウザを操作する AI の登場で、 前提が⼀つ変わる Chrome DevTools MCP のような仕組みでは、DevTools Protocol 経由でブラウザを操作 ここでは HttpOnly の Cookie も値まで参照可能 従来の前提 エージェント経由 HttpOnly により、JavaScript から読めない状態 DevTools Protocol は認証 Cookie を値ごと返却 Chromium も「ローカル攻撃者は脅威モデル外」と明記 document.cookie → 認証 Cookie は現れない Network.getAllCookies → 値まで 同じ端末で動くソフトウェアに対しては、HttpOnly の効果も範囲外 27
35. その先の対策 DBSC ｜ Cookie を端末に紐づける⽅向 Device Bound Session Credentials 値そのものを隠すのではなく、他の端末で使えなくするという発想 仕組みの要点 現在の位置 セッションを端末内の秘密鍵に結びつけ、ブラウザが 定 期的に署名で更新 値の複製だけでは成⽴しない構造 Chrome で先⾏して実装が進む段階 他エンジンの対応と 合わせて、これから⾒ていく領域 Cookie は今も動いている領域 ここでもブラウザごとの差が要点 28
36. まとめ このLTがあったからこそ⽣まれた興味！！！ 29
38. おわり ご清聴ありがとうございました たてけん 𝕏 @tateken_create zenn.dev/tateken 30
39. APPENDIX おまけ 本編では扱わない、2つの補⾜ 31
40. おまけ ① 同じ端末で動くエージェントに対しては、HttpOnly の効果も範囲外 HttpOnly は JavaScript からの読み取りを禁じる属性であり、セッション保護の定番 DevTools Protocol 経由での⾒え⽅ Chrome 136 で remote-debugging-port を制限した理由 document.cookie に現れない認証 Cookie も、 Network.getAllCookies では値まで取得可能 "Since App-Bound Encryption was enabled we've seen an increase in attackers using Chrome Remote Debugging to extract cookies." Chromium は「ローカル攻撃者は脅威モデル外」と明記 32
41. おまけ ② CHIPS ｜ 埋め込み先ごとの保管箱 サードパーティ Cookie には、追跡と、埋め込み先での状態保持という正反対の⽤途が混在 区別の⼿段がないまま⼀括でブロックさ れ、正当なウィジェットにも影響 Set-Cookie: __Host-session=abc; SameSite=None; Secure; Path=/; Partitioned 属性なし ｜ 保管箱は1つ どのサイト経由でも同じ値を読める Safari の対応の変遷 Safari 18.4 （2025-03） 対応 Safari 18.5 （2025-05） 削除 Safari 26.2 （2025-12） 再対応 属性あり ｜ 埋め込み先ごとに保管箱を分離 横断的な追跡は不成⽴ 全ブラウザでの利⽤可能時期は2025年12⽉ 33