今時のCookie事情 - Speaker Deck

今時のCookie事情

by sutetotanuki

Slide 1

Slide 1 text

今時のCookie事情 2024.7.31 リテールアプリ共創部マッハチーム⻄⽥将幸

Slide 2

Slide 2 text

Xへの投稿の際は、ハッシュタグ #devio2024 でお願いいたします。 2 お願い

Slide 3

Slide 3 text

今時のCookie事情 3

Slide 4

Slide 4 text

Cookieとは？ 4 そもそもCookieとは？

Slide 5

Slide 5 text

Cookieとは？ 5 ブラウザに保存できるテキストデータ

Slide 6

Slide 6 text

Cookieのユースケース 6 ● 認証情報 ● ユーザー情報 ● ECサイトのカート情報 ● ターゲティング広告で使われるトラッキング

Slide 7

Slide 7 text

Cookieのユースケース 7 ユーザー固有となるブラウザのストレージに重複しないデータを保存することでユーザーを識別することができる

Slide 8

Slide 8 text

Cookieの仕組み 8 サーバからブラウザへのレスポンスヘッダに Set-Cookie を送信すると... Set-Cookie: name=value; Secure; SameSite=Lax; HttpOnly 次のリクエストからブラウザがSet-Cookieで渡された名前と値をCookieリクエストヘッダで送信する Cookie: name=value

Slide 9

Slide 9 text

JSからもアクセスできる 9 CookieはJavaScriptからもアクセスが可能 JavaScriptからアクセスできることで、便利な簡易ストレージとして使うことができる⼀⽅で、攻撃の経路が増えてしまう

Slide 10

Slide 10 text

Cookieのセキュリティ 10 Cookieのセキュリティ

Slide 11

Slide 11 text

Cookieの属性 11 ● Path属性 ● Domain属性 ● HttpOnly属性 ● Secure属性 Set-Cookie: name=value;Path=/; Domain=example.com; HttpOnly; Secure

Slide 12

Slide 12 text

Path属性 12 Set-Cookie: name=value;Path=/; Domain=example.com; HttpOnly; Secure Cookieを送信するパス。ユーザーがアクセスしてるパスが Path属性に指定したパスに含まれてないとCookieを送信しない。 Path属性に指定した値のサブディクレトリも送信が許可される。例えば /admin と指定すると /admin/dashboad でも Cookieが送信される。ただあまり使われてない有名なフレームワークでは / (ルート) を指定されている

Slide 13

Slide 13 text

Domain属性 13 Set-Cookie: name=value;Path=/; Domain=example.com; HttpOnly; Secure Cookieが送信されるドメインを指定何も指定しないのが最もセキュアで、ユーザーがアクセスしたサイトのドメインでしかCookieを送信しない値を指定した場合、そのサブドメインでもCookieが送信される同じサブドメインで提供しているサービス同⼠でCookieを共有しSSOするような場合に指定する

Slide 14

Slide 14 text

HttpOnly属性 14 Set-Cookie: name=value;Path=/; Domain=example.com; HttpOnly; Secure CookieをJavaScriptからアクセスできないようにする XSS(クロスサイトスクリプティング)のリスクを軽減 JavaScriptからアクセスさせる必要のないCoookieには必ずつけておく

Slide 15

Slide 15 text

Secure属性 15 Set-Cookie: name=value;Path=/; Domain=example.com; HttpOnly; Secure CookieをHTTPSでのみ送信する属性 HTTPで通信すると通信内容が傍受されCookieが盗み⾒られる可能性がある現代のWEBでHTTPで通信することはほぼないので、基本的につけることになる

Slide 16

Slide 16 text

属性で守られるセキュリティ 16 Cookieを盗み⾒させないことが⽬的しかし、それだけでは守れない攻撃がある

Slide 17

Slide 17 text

Cookieのセキュリティ 17 CSRF

Slide 18

Slide 18 text

CSRFとは？ 18 Cookieが⾃動で送信される仕組みを使って悪意ある第３者が本⼈が意図しないリクエストを本⼈のCookie（認証情報）とともに正規のサイトに送信する攻撃

Slide 19

Slide 19 text

CSRFとは？ 19 攻撃者が罠サイトに誘導し仕掛けられたJSやformを使って正規サイトにリクエストを送信させる

Slide 20

Slide 20 text

CSRFの対策 20 ● CSRFトークン ● Same Origin Policy(同⼀オリジンポリシー) ● Same Site

Slide 21

Slide 21 text

CSRFトークン 21 正規サイトでランダムなトークンを発⾏し、そのトークンをformに保持しておくリクエスト時にトークンも⼀緒に送信し、サーバー側で保存しているトークンと⽐較

Slide 22

Slide 22 text

Same Origin Policy 22 WEBアプリケーションとリソース(主にAPI)が同⼀のオリジン(Same Origin)でない場合のアクセスを制限する昨今のブラウザはデフォルト有効

Slide 23

Slide 23 text

CORS 23 CORS Cross Origin Resource Sharing

Slide 24

Slide 24 text

CROSとは？ 24 Cross Originでもリソースのアクセスを許可する仕組み API側で Access-Control-xxx 関連のヘッダでアクセスできるWEBアプリのオリジンを指定ブラウザ側ではJS等で書き換えられない Origin ヘッダを⾃動で送信する

Slide 25

Slide 25 text

CORS 25 単純リクエストでない場合、ブラウザは Preﬂight リクエストを⾃動で送信、CORS関連のヘッダを確認し、許可されてない場合は処理を中断

Slide 26

Slide 26 text

Same Originとは？ 26 https://osaka.example.com/odessey URLのパス以外の部分が⼀致すると Same Origin ⼀致しないと Cross Origin

Slide 27

Slide 27 text

単純リクエスト 27 Preﬂightが発⽣しない単純リクエストとは ● GET、HEAD、POST ● HTTPヘッダを追加、変更していない ● Content-Typeが以下のいずれか application/x-www-form-urlencoded multipart/form-data text/plain 通常のformを使ってのPOSTは Preﬂight が発⽣しないつまり、Cross Originのアクセスが許可されてる

Slide 28

Slide 28 text

Same Site 28 Same Site

Slide 29

Slide 29 text

Same Site 29 同⼀でないSiteに対してCookieの送信を制限する

Slide 30

Slide 30 text

Same Site 30 ● Lax(デフォルト) ○ トップナビゲーション(外部サイトからの遷移)のみ Cookieを送信する ● Strict ○ 3rd Party Cookieを送信しない ● None ○ 3rd Party Cookieを送信する Same Siteに設定できる値

Slide 31

Slide 31 text

Same Siteとは？ 31 https://osaka.example.com/odessey URLのパスとサブドメイン以外の部分が⼀致すると Same Site ⼀致しないと Cross Site

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

サーバーサイドでの防御 33 CSRFはサーバーサイドでも追加で対策できる

Slide 34

Slide 34 text

API側でCSRFを防ぐ 34 ● 副作⽤のあるAPIをGETで作成しない ● HostとOriginヘッダが同じかチェックする ● Sec-Fetch-Site が cross-origin かチェックする

Slide 35

Slide 35 text

リクエスト出⾃がわかるヘッダ 35 Fetch Metadata Request Headers

Slide 36

Slide 36 text

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” }

Slide 37

Slide 37 text

3rd Party Cookie 37 3rd Party Cookie

Slide 38

Slide 38 text

3rd Party Cookieとは？ 38 Cross Siteに送信される Cookie 主に認証の連携、トラッキングに使われるサイトを跨いでユーザーを識別できる

Slide 39

Slide 39 text

3rd Party Cookie規制の動き 39 他のサイトで検索していたキーワードに関連する広告が別のサイトで表⽰されるなど、ユーザーの知らないところでトラッキングされてる気持ち悪さがあるトラッキング⽤途に使われる 3rd Party Cookieを廃⽌していく動きがある Chromeは今⽇時点で2025年早期の廃⽌を計画

Slide 40

Slide 40 text

3rd Party Cookie規制後の世界 40 3rd Party Cookieの⽤途の中でも認証の連携などユーザーにとって利便性の⾼い⽤途では 3rd Party Cookieを使えるようにしたいそのため、いくつかの条件で3rd Party Cookieが使えるよういろんな⽅法が模索されてる

Slide 41

Slide 41 text

Storage Access API 41 ユーザーにプロンプトを出し同意してもらうことで 3rd Party CookieにアクセスできるようにするブラウザのAPI

Slide 42

Slide 42 text

CHIPS 42 Cookieをトップレベルサイト（埋め込む側)ごとに分割して保存埋め込まれる側の3rd Party Cookieがトップレベルサイト毎に別々になるためサイトを跨いでユーザーをトラッキングできない埋め込み型のサポートチャットを提供するSaaSなど、トップレベルサイトごとで別々のユーザーとして管理されても問題ないところで利⽤できる

Slide 43

Slide 43 text

CHIPS 43 CHIPSではCookieを保存するキーをトップレベルサイトのドメインのeTLD+1と埋め込まれた側(3rd Party)のドメインとの複合キーで保存している

Slide 44

Slide 44 text

まとめ 44 まとめ

Slide 45

Slide 45 text

まとめ 45 ● Cookieのセキュリティ ○ 属性だけでは不⼗分 ○ CSRFの対策 ● Same Origin, Same Siteでデフォルトである程度防いでる ○ サーバーサイドで追加で防御できる ● 3rd Party Cookieは廃⽌の⽅向 ○ CHIPSやStorage Access APIなど緩和策が出てきている