HTTP cookie

出典: フリー百科事典『ウィキペディア(Wikipedia)』

HTTP cookie(エイチティーティーピークッキー、単にCookieとも表記される)は、RFC 2965などで定義されたHTTPにおけるWebサーバウェブブラウザ間で状態を管理するプロトコル、またそこで用いられるWebブラウザに保存された情報のことを指す。ユーザ識別やセッション管理を実現する目的などに利用される。

目次

[編集] 概要

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

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

そこで、1994年にNetscape Communications CorporationによってCookieが提案・実装された。Cookieでは次のようにサーバとクライアント間の状態を管理する。

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

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

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

[編集] 用途

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

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

[編集]

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

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

[編集] 例:MediaWikiにおけるログイン情報

例として、MediaWikiにおけるcookieの使用をあげる。

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

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

[編集] JavaScriptによるcookieの操作

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

[編集] ブラウザの環境設定によるcookieの操作

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

[編集] cookieの適用範囲と有効期限

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

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

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

この節は執筆の途中です この節は執筆中です。加筆、訂正して下さる協力者を求めています

[編集] セッションハイジャック

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

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

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

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

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

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

[編集] トラッキング・クッキー

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

この手法は、Web広告業者がよく利用する。バナー広告は、業者のサーバへのリンクを介して画像を取得する形式が一般的である。前述のとおりcookieはHTMLに限らず、画像にも設定することができる。HTTPではリンク元のURL情報も送信することが一般的なので、結果として広告業者は、同社を利用するすべてのサイトを対象としてそのユーザのアクセス履歴を把握することが可能になる。ユーザのアクセス履歴を追跡するという意味からトラッキング・クッキー(Tracking Cookie)と呼ばれたり、メインのHTMLではなく画像の提供元が設定するという意味からサードパーティ・クッキー(Third-party Cookie)と呼ばれたりする。

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

[編集] 脚注

  1. ^ ここで言う資源とは、HTML文書や画像、音声、などのコンテンツ全般を指す。
  2. ^ ウィキペディアを例に挙げると、同じURLでもログインしていない場合はページの一番上が「ログインまたはアカウント作成」、している場合は「(ユーザ名) マイ・トーク オプション ウォッチリスト 自分の投稿記録 ログアウト」と表示が変化する。
  3. ^ Microsoft. "[IIS]2038 年 1 月 19 日以降の有効期限のクッキーにおける ASP 200 エラー" (日本語). 2008-06-16 閲覧。
  4. ^ 情報処理推進機構. "経路のセキュリティと同時にセキュアなセッション管理を" (日本語). 2008-05-24 閲覧。
  5. ^ Symantec Corporation. "システムの完全スキャンを実行すると Tracking Cookie のリスクが表示される" (日本語). 2008-06-15 閲覧。
  6. ^ Trend Micro Incorporated. "スパイウェア検索をすると「COOKIE_・・・・」が多量に検出されるのですが、大丈夫ですか?" (日本語). 2008-06-15 閲覧。

[編集] 関連項目

[編集] 外部リンク