今時のCookie事情

Transcript

1. 今時のCookie事情 2024.7.31 リテールアプリ共創部マッハチーム ⻄⽥将幸
2. Xへの投稿の際は、 ハッシュタグ #devio2024 でお願いいたします。 2 お願い
3. 今時のCookie事情 3
4. Cookieとは？ 4 そもそもCookieとは？
5. Cookieとは？ 5 ブラウザに保存できるテキストデータ
6. Cookieのユースケース 6 • 認証情報 • ユーザー情報 • ECサイトのカート情報 • ターゲティング広告で使われるトラッキング
7. Cookieのユースケース 7 ユーザー固有となるブラウザのストレージに 重複しないデータを保存することで ユーザーを識別することができる
8. Cookieの仕組み 8 サーバからブラウザへのレスポンスヘッダに Set-Cookie を送信すると... Set-Cookie: name=value; Secure; SameSite=Lax; HttpOnly 次のリクエストからブラウザがSet-Cookieで渡された 名前と値をCookieリクエストヘッダで送信する Cookie: name=value
9. JSからもアクセスできる 9 CookieはJavaScriptからもアクセスが可能 JavaScriptからアクセスできることで、 便利な簡易ストレージとして使うことができ る⼀⽅で、攻撃の経路が増えてしまう
10. Cookieのセキュリティ 10 Cookieのセキュリティ
11. Cookieの属性 11 • Path属性 • Domain属性 • HttpOnly属性 • Secure属性 Set-Cookie: name=value;Path=/; Domain=example.com; HttpOnly; Secure
12. Path属性 12 Set-Cookie: name=value;Path=/; Domain=example.com; HttpOnly; Secure Cookieを送信するパス。ユーザーがアクセスしてるパスが Path属性に指定したパスに含まれてないとCookieを送信し ない。 Path属性に指定した値のサブディクレトリも送信が許可さ れる。例えば /admin と指定すると /admin/dashboad でも Cookieが送信される。ただあまり使われてない 有名なフレームワークでは / (ルート) を指定されている
13. Domain属性 13 Set-Cookie: name=value;Path=/; Domain=example.com; HttpOnly; Secure Cookieが送信されるドメインを指定 何も指定しないのが最もセキュアで、ユーザーがアクセスし たサイトのドメインでしかCookieを送信しない 値を指定した場合、そのサブドメインでもCookieが送信さ れる 同じサブドメインで提供しているサービス同⼠でCookieを 共有しSSOするような場合に指定する
14. HttpOnly属性 14 Set-Cookie: name=value;Path=/; Domain=example.com; HttpOnly; Secure CookieをJavaScriptからアクセスできないようにする XSS(クロスサイトスクリプティング)のリスクを軽減 JavaScriptからアクセスさせる必要のないCoookieには必ず つけておく
15. Secure属性 15 Set-Cookie: name=value;Path=/; Domain=example.com; HttpOnly; Secure CookieをHTTPSでのみ送信する属性 HTTPで通信すると通信内容が傍受されCookieが盗み⾒られ る可能性がある 現代のWEBでHTTPで通信することはほぼないので、基本的 につけることになる
16. 属性で守られるセキュリティ 16 Cookieを盗み⾒させないことが⽬的 しかし、それだけでは守れない攻撃がある
17. Cookieのセキュリティ 17 CSRF
18. CSRFとは？ 18 Cookieが⾃動で送信される仕組みを使って悪 意ある第３者が本⼈が意図しない リクエストを本⼈のCookie（認証情報 ）と ともに正規のサイトに送信する攻撃
19. CSRFとは？ 19 攻撃者が罠サイトに誘導し 仕掛けられたJSやformを 使って正規サイトに リクエストを送信させる
20. CSRFの対策 20 • CSRFトークン • Same Origin Policy(同⼀オリジンポリシー) • Same Site
21. CSRFトークン 21 正規サイトでランダムなトークンを発⾏し、 そのトークンをformに保持しておく リクエスト時にトークンも⼀緒に送信し、 サーバー側で保存しているトークンと⽐較
22. Same Origin Policy 22 WEBアプリケーションとリソース(主にAPI)が 同⼀のオリジン(Same Origin)でない場合のアクセス を制限する 昨今のブラウザはデフォルト有効
23. CORS 23 CORS Cross Origin Resource Sharing
24. CROSとは？ 24 Cross Originでもリソースのアクセスを許可する仕組 み API側で Access-Control-xxx 関連のヘッダでアクセス できるWEBアプリのオリジンを指定 ブラウザ側ではJS等で書き換えられない Origin ヘッ ダを⾃動で送信する
25. CORS 25 単純リクエストでない 場合、ブラウザは Preflight リクエストを⾃動 で送信、CORS関連のヘッ ダを確認し、許可されてな い場合は処理を中断
26. Same Originとは？ 26 https://osaka.example.com/odessey URLのパス以外の部分が⼀致すると Same Origin ⼀致しないと Cross Origin
27. 単純リクエスト 27 Preflightが発⽣しない単純リクエストとは • GET、HEAD、POST  • HTTPヘッダを追加、変更していない • Content-Typeが以下のいずれか application/x-www-form-urlencoded multipart/form-data text/plain 通常のformを使ってのPOSTは Preflight が発⽣しない つまり、Cross Originのアクセスが許可されてる
28. Same Site 28 Same Site
29. Same Site 29 同⼀でないSiteに対してCookieの送信を制限する
30. Same Site 30 • Lax(デフォルト) ◦ トップナビゲーション(外部サイトからの遷移)のみ Cookieを送信する • Strict ◦ 3rd Party Cookieを送信しない • None ◦ 3rd Party Cookieを送信する Same Siteに設定できる値
31. Same Siteとは？ 31 https://osaka.example.com/odessey URLのパスとサブドメイン以外の部分が⼀致すると Same Site ⼀致しないと Cross Site
32. Same Siteのサブドメイン 32 ドメインのeTLD + 1が⼀致すると Same Site eTLDとはTLD(jp、com、net等)と実質的にTLDとし て扱われてる(co.jp、 github.io等)を含めたドメイン 実質的なTLDの1つ左のドメインが⼀致している場合 Same Siteとなる 例) www.osaka.example.comと api.osaka.example.com は samesite
33. サーバーサイドでの防御 33 CSRFはサーバーサイドでも追加で対策できる
34. API側でCSRFを防ぐ 34 • 副作⽤のあるAPIをGETで作成しない • HostとOriginヘッダが同じかチェックする • Sec-Fetch-Site が cross-origin かチェックする
35. リクエスト出⾃がわかるヘッダ 35 Fetch Metadata Request Headers
36. Fetch Metadata Request Headers 36 ただし、全てのブラウザが送信するわけでない ブラウザからリクエスト元の情報が送られてくる Sec-Fetch-Dest, Sec-Fetch-Mode, Sec-Fetch-Site, Sec-Fetch-User とあり、それぞれをチェックするこ とでセキュリティを強化できる if (request.headers[“Sec-Fetch-Site”] !== “same-origin”) { return “deny” }
37. 3rd Party Cookie 37 3rd Party Cookie
38. 3rd Party Cookieとは？ 38 Cross Siteに送信される Cookie 主に認証の連携、トラッキングに使われる サイトを跨いでユーザーを識別できる
39. 3rd Party Cookie規制の動き 39 他のサイトで検索していたキーワードに関連する 広告が別のサイトで表⽰されるなど、ユーザーの 知らないところでトラッキングされてる気持ち悪さが ある トラッキング⽤途に使われる 3rd Party Cookieを 廃⽌していく動きがある Chromeは今⽇時点で2025年早期の廃⽌を計画
40. 3rd Party Cookie規制後の世界 40 3rd Party Cookieの⽤途の中でも認証の連携など ユーザーにとって利便性の⾼い⽤途では 3rd Party Cookieを使えるようにしたい そのため、いくつかの条件で3rd Party Cookieが使え るよういろんな⽅法が模索されてる
41. Storage Access API 41 ユーザーにプロンプトを出し同意してもらうことで 3rd Party Cookieにアクセスできるようにするブラウ ザのAPI
42. CHIPS 42 Cookieをトップレベルサイト（埋め込む側)ごとに 分割して保存 埋め込まれる側の3rd Party Cookieがトップレベルサ イト毎に別々になるためサイトを跨いでユーザーをト ラッキングできない 埋め込み型のサポートチャットを提供するSaaSな ど、トップレベルサイトごとで別々のユーザーとして 管理されても問題ないところで利⽤できる
43. CHIPS 43 CHIPSではCookieを保存するキーをトップレベルサ イトのドメインのeTLD+1と埋め込まれた側(3rd Party)のドメインとの複合キーで保存している
44. まとめ 44 まとめ
45. まとめ 45 • Cookieのセキュリティ ◦ 属性だけでは不⼗分 ◦ CSRFの対策 • Same Origin, Same Siteでデフォルトである程度防いでる ◦ サーバーサイドで追加で防御できる • 3rd Party Cookieは廃⽌の⽅向 ◦ CHIPSやStorage Access APIなど緩和策が出てきている