2012年4月18日水曜日

HTTP cooki クッキー by Wikipedia

HTTP cookie クッキー by Wikipedia

HTTP cookie
出典: フリー百科事典『ウィキペディア（Wikipedia）』
移動： 案内, 検索
HTTP
Persistence ·Compression ·
HTTPS
ヘッダーフィールド
Cookie ·ETag ·Location ·
Referer ·X-Forwarded-For
ステータスコード
301 Moved permanently
302 Found
303 See Other
401 Unauthorized
403 Forbidden
404 Not Found
406 Not Acceptable
413 Request Entity Too Large
500 Internal Server Error
503 Service Unavailable
表・話・編・歴
HTTP cookie（エイチティーティーピークッキー、単にCookieとも表記される）は、RFC 6265などで定義されたHTTPにおけるWebサーバとウェブブラウザ間で状態を管理するプロトコル、またそこで用いられるWebブラウザに保存された情報のことを指す。ユーザ識別やセッション管理を実現する目的などに利用される。

目次

[非表示]

概要 [編集]

HTTPは元来ハイパーテキストにおいて単にファイル転送を行うために開発されたため、同じURLへのアクセスならその状況によらず同一の資源[1]を提供することが前提となっている。動的なコンテンツ生成の仕組みとしてフォームが導入されているが、これは要求に直接対応する応答だけに影響をおよぼす。言い換えるとHTTPでは、同じ瞬間に同じ内容の要求を行っていれば、そのクライアントが以前にどのような通信を行っていても区別されない。HTTPはその意味で現在においてもステートレスなプロトコルである。
その一方でWorld Wide Webが普及するにつれ、状況によって異なる内容のページを提供したい[2]というニーズが生まれた。そのようなニーズをHTTPのみで満たすには、IPアドレスによって区別する、状態を表現したユニークなURLを生成するなどの方法がある。しかし、プライベートネットワークからのアクセスを区別できない、本来二度起きない状態が同じURLにアクセスすることで何度も発生する、セキュリティの問題などいずれも容易に解決できない欠点を抱えていた。
そこで、1994年にNetscape Communications CorporationによってCookie[3]が提案・実装された。Cookieでは次のようにサーバとクライアント間の状態を管理する。
  1. WebサーバがWebブラウザにその状態を区別する識別子をHTTPヘッダに含める形で渡す。
  2. ブラウザは次にそのサーバと通信する際に、与えられた識別子をHTTPヘッダに含めて送信する。
  3. サーバはその識別子を元にコンテンツの内容をユーザに合わせてカスタマイズし、ブラウザに渡す。必要があれば新たな識別子もHTTPヘッダに含める。
以降2、3の繰り返し。
この仕組みによって、ステートレスなプロトコルであるHTTP上でステートフルなサービスを実現する。ここで注意すべき点は、一度設定されたCookieは、条件を満たす限り何度でも要求に組み込まれるという点である。HTMLページの要求だけでなく、画像を含むすべての要求が対象となる。
その後Cookieは1997年にRFC 2109で初めて標準化され、2000年のRFC 2965、2011年のRFC 6265で更新された。2007年現在ほとんどのWebサーバ、Webブラウザで利用可能である。

仕様間の違い [編集]

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

用途 [編集]

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年問題で不具合を起こす場合があることから[6]、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情報を知る方法のひとつは盗聴である。盗聴を防ぐ手段としてTLSがある。ただしここで、cookieは有効範囲内のすべての要求に対して自動的に付加されることに注意する必要がある。SSLでcookie情報を暗号化しているつもりでも、有効範囲の設定によっては、SSLを利用しない要求にもcookieが付加される可能性がある。情報処理推進機構は2003年8月に、この点に関する注意喚起[7]を行った。
クロスサイトスクリプティングも、cookie情報を不正に得る手段として使われる場合がある。Cookieには有効範囲が設定されているが、その有効範囲内にクロスサイトスクリプティング脆弱性を持つページがある場合、JavaScript等を併用して、他のサーバにcookie情報を（URLの一部に組み込むなどして）送信させることが可能になる。

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

Cookieを使うと、そのユーザからの他の要求と関連付けることができる。
この手法は、Web広告業者がよく利用する。バナー広告は、業者のサーバへのリンクを介して画像を取得する形式が一般的である。前述のとおりcookieはHTMLに限らず、画像にも設定することができる。HTTPではリンク元のURL情報も送信することが一般的なので、結果として広告業者は、同社を利用するすべてのサイトを対象としてそのユーザのアクセス履歴を把握することが可能になる。ユーザのアクセス履歴を追跡するという意味からトラッキング・クッキー（Tracking Cookie）と呼ばれたり、メインのHTMLではなく画像の提供元が設定するという意味からサードパーティ・クッキー（Third-party Cookie）と呼ばれたりする。
これをプライバシーの侵害と考える人も、そう考えない人もいる。このようなcookieを設定したくないユーザのために、クライアント向けセキュリティ対策ソフトの多くは、トラッキング・クッキーを検出・除去する機能を備えている[8][9]。しかし、すべてのユーザにその影響が正しく理解されているとは限らず、コンピュータウイルスと誤解して初心者が驚くといった状況も散見される。

類似のトラッキング技術 [編集]

ウェブサイト作成者はcookieを用いなくても、IPアドレス・ユーザーエージェント・ウェブビーコン・HTTPリファラなどを利用してトラッキングをすることが可能である。
またAdobe Flashで使われるLocal Shared Object（Flash cookieとも呼ばれる）、HTML5やSilverlightの保存領域を利用してcookieと同様のトラッキングをすることが可能である。ユーザには非常に気づかれにくい上に、cookieが拒否あるいは削除されてもそれらの情報から容易に生成・復元することもできる。これらを総称してZombie cookieやSupercookieなどと呼ばれる[10]。問題になり始めた2011年現在では一般的なウェブブラウザやセキュリティソフトウェアの多くはこれに対処できておらず、除去や防止のためにはサードパーティ製ブラウザアドオンなどが必要である。

脚注 [編集]

  1. ^ ここで言う資源とは、HTML文書や画像、音声、などのコンテンツ全般を指す。
  2. ^ ウィキペディアを例に挙げると、同じURLでもログインしていない場合はページの一番上が「ログインまたはアカウント作成」、している場合は「(ユーザ名) 自分の会話 個人設定 ウォッチリスト 自分の投稿記録 ログアウト」と表示が変化する。
  3. ^ Netscape Communications Corporation. “PERSISTENT CLIENT STATE HTTP COOKIES” (英語). 2011年9月29日閲覧。
  4. ^ Dan Winship. “2009-08-05-Dan-Winship.txt” (英語). 2011年9月29日閲覧。
  5. ^ Dan Winship. “2009-08-11-Dan-Winship.txt” (英語). 2011年9月29日閲覧。
  6. ^ Microsoft. “[IIS]2038 年 1 月 19 日以降の有効期限のクッキーにおける ASP 200 エラー” (日本語). 2008年6月16日閲覧。
  7. ^ 情報処理推進機構. “経路のセキュリティと同時にセキュアなセッション管理を” (日本語). 2008年5月24日閲覧。
  8. ^ Symantec Corporation. “システムの完全スキャンを実行すると Tracking Cookie のリスクが表示される” (日本語). 2008年6月15日閲覧。
  9. ^ Trend Micro Incorporated. “スパイウェア検索をすると「COOKIE_････」が多量に検出されるのですが、大丈夫ですか？” (日本語). 2008年6月15日閲覧。
  10. ^ “アドネットワークは、常にあなたを監視している”. japan.internet.com. (2011年10月25日). http://japan.internet.com/wmnews/20111025/5.html 2011年10月26日閲覧。

関連項目 [編集]

外部リンク [編集]

投稿者 時刻:

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)