目的
- Cookieの仕様を知る。
結果
Cookie
- 以下の3つの用途で使用される
- セッション管理
- サーバーが覚えておくべきもの(ログイン、ショッピングカートなど)
- パーソナライズ
- ユーザー設定、テーマ、その他の設定
- トラッキング
- ユーザーの行動の記録
- セッション管理
- クライアントへデータを保存する手段として
Cookie
が使われていたが、現在では、ストレージAPIを使用することが推奨されている。 - Cookieは全てのリクエストで送信されるので、性能を悪化させる必要がある。
- ⇨
Web Storage API
とIndexedDB
がある。
- ⇨
- サーバーはレスポンスで
Set-Cookie
ヘッダーを送信することができる。 - 有効期限や期間を設定でき、それが切れると、その後は
Cookie
が送信されなくなる - 特定のドメインやパスへの追加の制約を設定できる
Cookie
をどこに送信するかを制限できる
Set-CookieヘッダーとCookieヘッダー
Cookieの持続時間の定義
- 2通りの方法で定義することができる
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
の接頭辞を使うことが可能で、以下の2つが利用可能__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