HTTP cookie

HTTP cookie（エイチティーティーピークッキー）は、マジッククッキーの一種。単にクッキー（cookie）とも表記される。

RFC 6265などで定義されたHTTPにおけるウェブサーバとウェブブラウザ間で状態を管理する通信プロトコル、またそこで用いられるウェブブラウザに保存された情報のことを指す。ユーザ識別やセッション管理を実現する目的などに利用される。

概要

HTTPは元来ハイパーテキストにおいて単にファイル転送を行うために開発されたため、同じURLへのアクセスならその状況によらず同一の資源を提供することが前提となっている。動的なコンテンツ生成の仕組みとしてフォームが導入されているが、これは要求に直接対応する応答だけに影響をおよぼす。言い換えるとHTTPでは、同じ瞬間に同じ内容の要求を行っていれば、そのクライアントが以前にどのような通信を行っていても区別されない。HTTPはその意味で現在においてもステートレスなプロトコルである。

その一方でWorld Wide Webが普及するにつれ、状況によって異なる内容のページを提供したいというニーズが生まれた。そのようなニーズをHTTPのみで満たすには、IPアドレスによって区別する、状態を表現したユニークなURLを生成するなどの方法がある。しかし、プライベートネットワークからのアクセスを区別できない、本来二度起きない状態が同じURLにアクセスすることで何度も発生する、セキュリティの問題などいずれも容易に解決できない欠点を抱えていた。

そこで、1994年にネットスケープコミュニケーションズ社によってクッキー が提案・実装された。クッキーでは次のようにサーバとクライアント間の状態を管理する。

1. ウェブサーバがウェブブラウザにその状態を区別する識別子をHTTPヘッダに含める形で渡す。
2. ブラウザは次にそのサーバと通信する際に、与えられた識別子をHTTPヘッダに含めて送信する。
3. サーバはその識別子を元にコンテンツの内容をユーザに合わせてカスタマイズし、ブラウザに渡す。必要があれば新たな識別子もHTTPヘッダに含める。

以降2、3の繰り返し。

この仕組みによって、ステートレスなプロトコルであるHTTP上でステートフルなサービスを実現する。ここで注意すべき点は、一度設定されたクッキーは、条件を満たす限り何度でも要求に組み込まれるという点である。HTMLページの要求だけでなく、画像を含むすべての要求が対象となる。

その後クッキーは1997年にRFC 2109で初めて標準化され、2000年のRFC 2965、2011年のRFC 6265で更新された。2007年現在ほとんどのウェブサーバ、ウェブブラウザで利用可能である。

仕様間の違い

前述の通り、HTTP Cookie には幾つか仕様があるが、IETFの標準化した RFC 2109 や RFC 2965 は、ネットスケープ仕様とExpires属性からMax-Age属性への変更等互換性がないため、実際のウェブサイトではほとんど使われていない。一方で、Expires属性等で用いられる日付形式は仕様外の記述が氾濫しているうえ、セキュリティ上の理由からhttponly属性やsecure属性等が事実上追加されており、長らく文書の存在しない状態が続いていたが、RFC 6265 はこれらの問題を解消することを意図して制定されている。

2016年頃から、RFC 6265の改訂作業が行われている。クッキープレフィックス（__Secure-と__Host-）、SameSite属性の追加などが行われる予定で、すでにウェブブラウザでの実装も並行して進められている。

用途

クッキーの最も代表的な用途は、ショッピングサイトにおけるカートやログイン状態の管理である。また、IPアドレスによらないクライアントの識別を可能にするため、ウェブサイト運営者やインターネット広告配信業者などがユーザの詳細なアクセス履歴を取得する用途にも使われる。

クッキーは毎回送られるものであり、またHTTPヘッダの一部なのでASCII文字列になっている必要がある。そのためクッキーでデータを直接扱うよりも、セッションIDを実装する手段として使うことが多い。この場合、実際のデータは、セッションIDをキーとしてサーバが保持することになる。

例

例えば特定のページの表示回数を、ウェブページ上に表示したいときには、おおむね次のようなやりとりが行われる。

1. ブラウザがサーバに閲覧を要求する。ここにはクッキーの情報はない。
2. サーバはブラウザに対し「1」回目というクッキー情報と、「1回目」と表示するようなデータを送信する。
3. ブラウザがサーバに閲覧を要求する。このときブラウザは、そのサーバから受け取ったクッキーを探して、「1」のクッキー情報をサーバに送信する。
4. サーバは「1」というクッキー情報に基づき、ブラウザに対し「2」回目というクッキー情報と、「2回目」と表示するようなデータを送信する。

例：MediaWikiにおけるログイン情報

例として、MediaWikiにおけるクッキーの使用をあげる。

MediaWikiソフトウェアでは、ログイン情報をクッキーで実現している。その方法はおおむね次のようである。

1. ログインページからユーザ名とパスワードをサーバに送信する。この時点でクッキーは使われていない。
2. サーバは、ユーザ名とパスワードを確認し、ユーザーにカスタマイズされた「ログイン成功」のページを送信するとともに、ユーザー名とパスワードを（そのままではないが）クッキーとして送信する。
3. 次の閲覧からはブラウザがページ閲覧要求とともに先のクッキーを送信する。サーバはクッキー情報によってユーザにカスタマイズされたページを送信する。
4. ログアウトをクリックすると、「ログアウト」のページとともに、空のクッキー情報を送信する。ブラウザは、先のクッキー情報を空のクッキー情報で上書きする。これにより最初のクッキー情報は消去される。

クライアント側スクリプトによるクッキーの操作

クッキーは、HTML DOMの一部としてアクセスできる。JavaScriptをはじめとする、クライアント側のスクリプトは、クッキーを操作することができる。ただし後述のようにクッキーには有効範囲が設定されており、そのURLにおいて有効なクッキーだけがアクセス対象となる。

ブラウザの環境設定によるクッキーの操作

現在使われているウェブブラウザのほとんどはクッキーの送受信が可能であり、初期状態でクッキーを送受信する設定になっている。しかし、クッキーの送受信をするしない、またそのクッキーの内容は、ウェブ閲覧者の自由に置かれるべきものであるので、ブラウザの初期設定でそれらを操作できるようになっている。すなわち、クッキーの送受信を停止する、クッキーの内容を確認する、クッキーを消去するといった機能がウェブブラウザに備わっている。

クッキーの適用範囲と有効期限

クッキーを設定する際、どの要求に対してクッキー情報を送り返すのか、URLの範囲を指定する。規定値は、クッキーを設定したサーバに対するすべての要求であり、対象を広げることも狭めることもできる。ただし広げる場合でも、トップレベルドメインより狭い範囲でなければならない。

またクッキーの有効期限は、通常はブラウザを終了するまでだが、指定した期限まではブラウザを再度起動しても保持されるように設定することができる。有効期限の情報も、サーバからブラウザにクッキー情報を送信する段階で付加される。 無期限という設定は出来ない。遥か未来を指定することで半永久的に有効にすることも可能だが、ブラウザやサーバが2038年問題で不具合を起こす場合があることから、2038年1月19日3時14分07秒(UTC)以降の時間を期限とすることはあまりない。

セキュリティ、プライバシーの問題

セッションハイジャック

クッキーでセッション管理を行う場合、もし第三者がセッションIDを知ることができれば、そのIDを名乗ることで本来のユーザになりすますことができる。このような「なりすまし」行為をセッションハイジャックと呼ぶ。

例として、以下のような通信を行うシステムがあるとする。

1. トップページでユーザIDとパスワードの入力を求める。
2. 認証に成功するとサーバはセッションIDを割り当て、クッキーとしてクライアントに通知する。
3. クライアントは以降の要求にクッキーとしてセッションIDを付加する。サーバは対応するセッション情報にアクセスし、どのユーザであるか識別する。

もし第三者がセッションIDを知ることができれば、そのセッションが有効な間だけとはいえ、1～2を飛ばして3から開始することができる。すなわち、パスワードを知らなくても「なりすまし」が可能となる。

第三者のクッキー情報を知る方法のひとつは盗聴である。盗聴を防ぐ手段としてTLSがある。ただしここで、クッキーは有効範囲内のすべての要求に対して自動的に付加されることに注意する必要がある。SSLでクッキー情報を暗号化しているつもりでも、有効範囲の設定によっては、SSLを利用しない要求にもクッキーが付加される可能性がある。情報処理推進機構は2003年8月に、この点に関する注意喚起を行った。

クロスサイトスクリプティングも、クッキー情報を不正に得る手段として使われる場合がある。クッキーには有効範囲が設定されているが、その有効範囲内にクロスサイトスクリプティング脆弱性を持つページがある場合、JavaScript等を併用して、他のサーバにクッキー情報を（URLの一部に組み込むなどして）送信させることが可能になる。

トラッキング・クッキー

クッキーを使うと、そのユーザからの他の要求と関連付けることができる。

この手法は、アドネットワーク（Google AdSenseなど）を利用するウェブ広告業者がよく用いる。インターネット広告の配信において、バナー広告は、業者のサーバ（サードパーティー）へのリンクを介して画像を取得する形式が一般的である。前述のとおりクッキーはHTMLに限らず、画像にも設定することができる。HTTPではリンク元のURL情報も送信することが一般的なので、結果として広告業者は、同社を利用するすべてのサイトを対象としてそのユーザのアクセス履歴を把握することが可能になる。詳細はCookieとスパイウェアの関係も参照。ユーザのアクセス履歴を追跡するという意味からトラッキング・クッキーと呼ばれたり、メインのHTMLではなく画像の提供元が設定するという意味からサードパーティー・クッキーと呼ばれたりする。これらは、行動ターゲティング広告やコンテンツ連動型広告および検索連動型広告などに活用され、時にフィルターバブルの原因ともなっているが、今後Federated Learning of Cohortsに移行する動きがある。

これをプライバシーの侵害と考える人も、そう考えない人もいる。このようなクッキーを設定したくないユーザのために、クライアント向けセキュリティ対策ソフトの多くは、トラッキング・クッキーを検出・除去する機能を備えている。しかし、すべてのユーザにその影響が正しく理解されているとは限らず、コンピュータウイルスと誤解して初心者が驚くといった状況も散見される。

類似のトラッキング技術

ウェブサイト作成者はクッキーを用いなくても、サードパーティーのGoogle Analytics等を使うことでIPアドレス・ユーザーエージェント・ウェブビーコン・HTTPリファラなどを利用してアクセス解析をおこないウェブ トラッキングをすることが可能である。JavaScriptおよびHTML5（WebGL、canvas要素、Webフォントなど）を用いたその他の手法についてはフィンガープリントも参照。

またAdobe Flashで使われるLocal Shared Object（フラッシュ・クッキーとも呼ばれる）やSilverlightの保存領域、HTML5（インストール済みのWebフォントなど）、Faviconなどを利用してクッキーと同様のトラッキングをすることが可能である。ユーザには非常に気づかれにくい上に、クッキーが拒否あるいは削除されてもそれらの情報から容易に生成・復元することもできる。これらを総称してZombie cookie（ゾンビ・クッキー）やSupercookie（スーパー・クッキー）などと呼ばれる。

問題になり始めた2011年現在では一般的なウェブブラウザやセキュリティソフトウェアの多くはこれに対処できておらず、防止や除去のためにはサードパーティー製ブラウザアドオンの使用とJavaScriptの制御や無効化、ウェブブラウザのプライバシーモードやCCleanerを用いたキャッシュおよび閲覧履歴の完全な削除などの対策が必要である。なお、Tor BrowserやOnion Browserに関しては、いまのところウェブトラッキングやキャンバス・フィンガープリンティングなどの回避に有効である。

関連項目

• ダイナミックHTML
• Enterprise JavaBeans
• セッション (コンピュータ)
• HTTP Strict Transport Security

• Hypertext Transfer Protocol
• クロスサイト・クッキング

外部リンク

• RFC 2965 - HTTP State Management Mechanism
• RFC 6265 - HTTP State Management Mechanism
• Cookies: HTTP State Management Mechanism （日本語訳）