目的
- Cookieの仕様を知る。
結果
Cookie
- 以下の３つの用途で使用される
- セッション管理
- サーバーが覚えておくべきもの（ログイン、ショッピングカートなど）
- パーソナライズ
- ユーザー設定、テーマ、その他の設定
- トラッキング
- ユーザーの行動の記録
- セッション管理
- クライアントへデータを保存する手段として
Cookieが使われていたが、現在では、ストレージAPIを使用することが推奨されている。 - Cookieは全てのリクエストで送信されるので、性能を悪化させる必要がある。
- ⇨
Web Storage APIとIndexedDBがある。
- ⇨
- サーバーはレスポンスで
Set-Cookieヘッダーを送信することができる。 - 有効期限や期間を設定でき、それが切れると、その後は
Cookieが送信されなくなる - 特定のドメインやパスへの追加の制約を設定できる
Cookieをどこに送信するかを制限できる
Set-CookieヘッダーとCookieヘッダー
Cookieの持続時間の定義
- ２通りの方法で定義することができる
Cookieへのアクセス制限
Secure属性
- HTTPSプロトコル上の暗号化されたリクエストでのみサーバーに送信され、安全でないHTTPでは送信されない
- ただし、これによってCookie内の機密情報へのアクセスを全て防げない。
- 例えば、クライアントのハードディスクへアクセスすることで読み取られる可能性がある
HttpOnly属性
JavascriptのDocument.cookie APIにアクセスできなくなり、サーバーに送信されるだけになる- 例えば、サーバー側のセッションを持続させる
CookieはJavascriptが利用する必要はないので、HttpOnly属性をつけるべき - この予防策は、クロスサイトスクリプティング攻撃(
XSS)を緩和するのに役立つ
- 例えば、サーバー側のセッションを持続させる
Cookieの送信先の定義
DomainおよびPath属性は、Cookieのスコープを定義する
Domain属性
Cookieを受信することができるホストを指定する- 指定されていない場合は、規定で
Cookieを設定したのと同じホストとなり、サブドメイン以外は除外される - 指定された場合、サブドメインは常に含まれる。そのため、
Domainを指定すると省略時よりも制限が緩和される。ただし、サブドメイン間でユーザーに関する情報を共有する場合は有用になる。
Path属性
Cookieヘッダーを送信するためにリクエストされたURLの中に含む必要があるURLのパスを示す
SameSite属性（= Strict, Lax, None）
- この属性により、サーバーがサイト間リクエストと一緒に
Cookieを送るべきでないことを要求できる - クロスサイトリクエストフォージェリー（CSRF）に対して幾らかの防御になる
Strict
- 発生したサイトのみに送信される
Lax
- ユーザーが
Cookieのオリジンのサイトに移動したときにもCookieが送信される- 例えば、外部サイトからリンクを辿った場合
None
Cookieを発生元サイトへリクエストとサイト間のリクエストの両方で送信されるが、安全なコンテキストでのみ送信される⇨
SameSite=NoneならSecure属性も設定する必要がある⇨
SameSite=Noneが設定されていない場合、Laxとして扱われる
Cookieの接頭辞
Cookieの設計では、Cookieが安全なオリジンに設定されているかどうか、どこに設定されたのかをサーバーが確認することができないようになっている- サブドメイン上にある脆弱性のあるアプリケーションが
Domain属性を使用してCookieを設定すると、他の全てのサブドメインでCookieにアクセスできるようにすることができる - この仕組みはセッション固定攻撃で悪用される可能性がある ⇨ 対策方法： セッションの固定化
しかし、多層制御として、
Cookieの接頭辞を使うことが可能で、以下の２つが利用可能__Host-Set-Cookieヘッダーが受け入れられるのはSecure属性で指定- 安全なオリジンから送信
Domain属性を含んでいないPath属性が/に設定されている
場合のみ
__Secure-Set-Cookieディレクティブが受け入れられるのはSecureである- 安全なオリジンから送信されている
場合のみ（
__Host-接頭辞よりも弱い）
上記の制約に適合していない
Cookieは、送られてもブラウザーが拒否する- アプリケーションサーバーは、ユーザーが認証されているか、あるいはCSRFトークンが正しいかどうかを判断するときに、特定の
Cookie名をチェックするだけなので、これはセッションの固定化に対する防御手段として効果的に機能する
JavascriptでのDocument.cookiesを使用したアクセス
Document.cookieプロパティを使用して新しいCookieを作成することができ、HttpOnlyフラグが設定されていない限り、既存のCookieにJavascriptからアクセスすることもできる- しかし、Javascriptで生成されたCookieはHttpOnlyフラグを含められない
- セキュリティの影響に注意すること。XSSによって盗まれる可能性がある。
セキュリティー
- 全てのCookieの値がエンドユーザーから見え、変更できる
- アプリケーションによっては、サーバー側で検索される不透明な識別子を使用するか、JSONウェブトークンのような代替の認証／機密性メカニズムを調べたほうが良いかも
Cookieへの攻撃を緩和する方法には以下のようなものがあるHttpOnly属性を使用して、JavascriptからCookieの値にアクセスするのを防ぐ- 認証などの機密情報のための
Cookieは、持続時間を短く、SameSite属性をStrctまたはLaxに設定する
トラッキングとプライバシー
サードパーティーのCookie
Cookieはドメインやスキーム（httpやhttpsなど）に関連づけられる（Set-CookieのDomain属性が設定された場合は、サブドメインにも関連づけられる）Cookieのドメインとスキームが現在のページと一致している場合、そのCookieはこのページと同じサイトからのものとみなされ、ファーストパーティーCookieと呼ばれる（Webページをホスティングしているサーバーが設定する）- ドメインとスキームが異なる場合、そのCookieは同じサイトのものとはみなされず、サードパーティーCookieと呼ばれる（他のドメインのサーバーに保存されている画像やその他のコンポーネント（例えば、広告バナーなど）など）
Cookieに関する規制
Cookieの使用を対象とした法規制には、以下のようなものがある。- これらの規制は、これらの管轄区域（注意事項あり）のユーザーがアクセスする全世界のウェブ上のあらゆるサイトに適用されるため、世界的な広がりを持っている
- これらの規制の要件には、次のようなものがある
日本のCookie規制について
Cookie規制はなぜ強まるのか？取り巻く状況の変化を解説！ | Priv Lab
ブラウザに情報を格納する他の方法
- 別のアプローチとして、
Web Storage APIがある SessionStorageとLocalStorageはセッションCookieと持続的Cookieに対応しているが、ストレージの容量制限がCookieより大きく、サーバーに送信されることがない- より構造化された大量のデータは、indexedDB API またはその上に構築されたライブラリを使用して保存することができる。
- ゾンビCookieと呼ばれる、Cookieが削除された後に再作成されるようにするための他の技術が作成されている
- これらの技術は、ユーザーのプライバシーとユーザー制御の原則に違反し、データプライバシー規則に違反する可能性がある
参考
HTTP Cookies - MDN
Using HTTP cookies - HTTP | MDN
Cookies, the GDPR, and the ePrivacy Directive
Cookies, the GDPR, and the ePrivacy Directive - GDPR.eu
