Network Working Group
Request for Comments: 2964
BCP: 44
Category: Best Current Practice

                K. Moore
 University of Tennessee
                N. Freed
                Innosoft
            October 2000

HTTP 状態管理の使い方

この文書の位置付け

この文書は、インターネットコミュニティにおけるインターネット標準化過程プロトコルを規定し、改良のために議論と提案を求めるものである。 このプロトコルの標準化状態と状況については、"Internet Official ProtocolStandards" (STD 1) の最新版を参照していただきたい。 この文書の配布に制限は無い。

著作権表示

Copyright © The Internet Society (2000). All Rights Reserved.

IESG による注

IESG では、以下のメカニズムではドットを含まないようなホスト名を扱う時には .local トップレベルドメイン (TLD) を内部的に使用しているが、その拡張的手法は将来登録されるかもしれない実際の .local TLD では作動しないであろう、という事を注記する。

概要

"HTTP 状態管理メカニズム" (RFC-2965)、及びその前のもの (RFC-2109) にて記述されたメカニズムは多くの様々な目的のために使用する事ができる。 しかしながら、それらは重要なユーザのプライバシーやセキュリティに関わりを持つためにそのプロトコルの現在の、また潜在的な使われ方のいくつかについては、議論を呼んでいる。 この文書は、(a) IETF によって推奨されていない、(b) 有害であり、やめるように考えられている、というようなハイパーテキスト転送プロトコル (HTTP) 状態管理プロトコルの特有の使い方を識別する。 またこの文書では、HTTP 状態管理プロトコルの仕様書によってはカバーされない追加的なプライバシーについての考察も詳述する。

1. 導入

HTTP 状態管理メカニズムは有用であるが、議論を呼んでいる。 多数の HTTP アプリケーションが URL 中にその状態をエンコードする事なく、HTTP 処理間で状態を保つ能力から利益を得ている、という点で有用である。 しかしこのメカニズムはそのために設計されたものではないし、十分に適したものではないという事象を達成するために使われている、という点で議論を呼んでいる。 これらの使い方のうちいくつかは、特にユーザが訪れた Web サイトのような第三者に機密性の高い情報を潜在的に漏洩する事によって、それらがweb ユーザのプライバシーを侵す恐れがあるために多量の公な批判を受けている。 たとえそれらがユーザのプライバシーを侵さなくても不適切である HTTP 状態管理の使い方は他にもある。

それ故にこの文書は IETF によって推奨されない、また有害であるが故にやめるように考えられている RFC-2965 中に詳述される HTTP 状態管理プロトコルの使い方を識別する。

この文書は時折大文字にて現れる用語を使う。 "MUST", "MUST NOT","SHOULD", "SHOULD NOT", "MAY" の各用語が大文字で現れた場合、それらはこの仕様書の特定の必要条件を示すために使われている。 "MUST", "SHOULD","MAY" の各用語の意味についての議論は [RFC-1123] 中に現れている。また"MUST NOT" と "SHOULD NOT" の各用語はこの使用法の論理的拡張である。

2. HTTP 状態管理の使い方

HTTP 状態管理の目的は、HTTP に基づいたサービスが複数の HTTP 処理を通じて持続するような状態を持つ "セッション" を生成できるようにする事である。 単一のセッションが複数のサーバホストにおける処理を含む事ができきる。 特定のユーザのためのセッションデータがクライアントホスト間で(例えば、ネットワーク中のファイルシステム経由で) 共有されている場合には、複数のクライアントホストもまた単一のセッションに含まれうる。 言い換えれば、"セッション" は "ユーザ" と "サービス" の間では状態を維持するが、特定のホスト間では維持しない。

同じような機能は、状態管理拡張を使わなくとも、"裸の{bare}" HTTP プロトコルや、動的に生成される HTML を使う事で達成できると認識する事が重要である。 例えば、状態情報は HTTP リダイレクトの、または動的に生成される HTML の中に現れる一つ以上の URL 中にセッション識別子を埋め込む事によって、サービスからユーザへと転送する事ができるし、またそのようなURL が GET や POST リクエスト中に現れた時には、ユーザからサービスへと返す事もできる。 HTML のフォームもまた、サービスからユーザやそれ以降へと、ユーザにそこで起こる事を気付かせる事なく、状態情報を渡すために使う事ができる。

しかし、HTTP 状態管理機能は通常の HTTP や HTML を超える機能性的増大を提供している。 実際には、この追加的機能性には以下を含む。

1. それらのセッションに関連する状態情報を漏らす事なく、状態を持つセッションの間でアクセスされたリソースの、ユーザ間で URL を交換するための能力。 (例、"ここがあなたが欲しかったサンダルについての FooCoop の web カタログの入口の URL ですよ。")
2. "キャッシュ破壊{cache-busting}" 無しに、セッション状態を維持する能力。 つまり、セッション状態と URL を分離する事で web キャッシュは名付けられたリソースの単一のコピーのみを保持する事ができるようになる。 もし状態がセッションを特定する URL によって維持されていたら、キャッシュはおそらくそのリソースの内容が同一のコピーをいくつも保持しなければならないだろう。
3. セッション状態を保持するための他の技法と比較されるような、最小のサーバ設定と最小のプロトコルオーバーヘッドとのセッションを実装するための能力。
4. ユーザが特定の "ホームページ" や "ポータル" を通って入場したかどうかに関わらず、ユーザがサービスにアクセスする時にはいつでもユーザとセッション情報を関連付けるための能力。
5. 安定した保存空間に状態情報を保存するための能力。 それによって"セッション" はクライアントの発動、システムの再起動、あるいはクライアントやシステムがクラッシュした場合でも維持されうる。

2.1. 推奨される使い方

HTTP 状態管理を使う事は、もし以下のようなあれば、複数の HTTP 処理を通じて状態をユーザとサービスの間で維持する事を望む場合にはいつでも適切である。

1. ユーザはセッション状態が維持されている事に気付いており、それに同意している
2. ユーザはそのセッションに関連する状態をいつでも消すという機能を持つ
3. そのサービスのユーザの使用を追跡するためにその能力を通じて獲得した情報は、ユーザの明示的同意無しに他のパーティには明らかにされない
4. セッション情報自身には、盗聴者が他の方法では利用できないような機密性の高い情報を含む事はできないし、機密性の高い情報を獲得するために使う事もできない。

クッキーは通常平文にて送られ、それ故に盗聴者は簡単に利用可能なので、最後の点は重要である。

推奨される使い方の例としては "ショッピングカート" があるだろう。 ショッピングカートの存在は明らかにユーザに知られているが、ユーザは明白に自身のショッピングカートを (空にする事を要求するか、それらの品目を購入する事によって) "空にする" 事ができ、それによって共有される状態は破棄される事となり、サービスはユーザの同意無しに第三者にユーザの買物や閲覧の習慣を明らかにしないであろうという事を断言する。

ユーザやユーザのクライアントがセッション状態を保持するためのリクエストを引きうける事に失敗した場合、実際上は HTTP 状態管理プロトコルによってサービス提供者がサービスを提供する事を拒否したり、あるいはサービスの水準を下げたりする事ができる。 法律上禁止でなければ、サーバはそれらの状況の元で、サービスを提供する事を拒否したり、サービスの水準を下げたりする事ができる。 純粋に現実的な考慮として、HTTP 状態管理を利用するように設計されたサービスはクライアントがそれを提供しなければ適切に機能しないようにできる。 そのようなサーバは、そのような条件を上品に扱うべきであり、何故完全な水準のサービスが利用できないかを説明すべきである。

2.2. 問題のある使い方

以下のような HTTP 状態管理の使い方は、不適当でありこの仕様書には反するものと考える。

2.2.1. 第三者への情報の漏洩

HTTP 状態管理は、ユーザの明示的同意無しに、ユーザやサービスを除く他のパーティにユーザ、あるいはユーザの閲覧の習慣についての情報を漏らすために使われてはならない。 状態管理メカニズム自身がユーザについての情報をまとめるために使われる識別子を提供するものであるので、そのような使い方は、たとえユーザの名前や他の外面的に割り当てられている識別子が他のパーティに晒されていなくても禁止されている。

そのような慣習はユーザに HTTP 状態管理メカニズムを敬遠させてしまうので、HTTP 状態管理の有効性は減少されていき、そしてそれ故に web の操作において有害であるとみなされるのである。

2.2.2. 認証メカニズムとしての使い方

HTTP 状態管理プロトコルを認証メカニズムとして使う事は概して不適切である。 HTTP 状態管理はそのような使い方を念頭において設計されていないし、認証証明書を保護するためのもの{safeguards} がプロトコルの仕様にも広く展開されている HTTP クライアントやサーバにも欠如している。 ほとんどのHTTP セッションは暗号化されておらず、それ故に "クッキー" は受動的盗聴者に晒される可能性がある。 更に、HTTP クライアントやサーバは一般的に晒される事に対してほとんど、あるいは全く保護を為さない平文にて "クッキー" を保存する。 それ故に HTTP 状態管理は、たとえ HTTP セッションが暗号化されていたとしても、認証されていないパーティに晒される事から情報を守るための認証メカニズムとして使われるべきではない。

認証のために HTTP 状態管理を使う事に対する禁止事項は、サービスによって提供される情報を守るために使うものも、サービスの関心事を任されるユーザについての潜在的に機密性の高い情報を守るために使うものも含む。 例えば、以前にユーザに関連付けられているクッキーを単に見せるクライアントへ、ユーザの名前や住所、電話番号、請求書情報を晒すのは不適当であろう。

同様に、もし認証されていないリクエストが望ましくない副作用をユーザにもたらす可能性がある場合に、ユーザがそのような副作用の可能性に気付いており、かつそのような使い方に明示的に同意しているので無ければ、HTTP状態管理は認証ユーザのリクエストに使われるべきではない。 例えば、完全にユーザの保存する "クッキー" に基づいて、ユーザが商品を一回の "クリック" で注文出来るサービスは、クッキーが第三者に晒されるという事態において、クレジットカードの料金について反論する事や、望まぬ商品を返す事を要求する事によってユーザに迷惑をかける事ができるであろう。

ユーザを識別するための HTTP 状態管理の使い方の中には比較的無害であるものがあり、例えば、そのように晒される唯一の情報がサービスに所有されていれば、サービスはそのような情報が晒される事からの害にはほとんど苦しまなくてもよいであろう。

3. HTTP 状態管理のためのユーザインターフェイスの考察

HTTP 状態管理は、ユーザの認識や同意無しに、ユーザの閲覧の習慣についての情報を第三者に晒すというその可能性のために非常に議論を呼んでいる。 そのように晒す事は可能である一方で、これはプロトコル自身の不備というよりも、むしろユーザの関心を保護するための HTTP クライアント実装 (やいくつかの HTTP に基づくサービスの提供者) の欠陥である。

上に示した通り、HTTP 状態管理を使う以外にセッション状態を維持するための他の方法があり、それ故にユーザの閲覧の習慣を追跡しうる事において他の方法がある。 なるほど、どのように HTTP プロトコル、あるいは HTTP クライアントは実際にサービスからもしサービスがそうする事を選んだ場合に他のパーティへのユーザの "クリック追跡" を明らかにさせないようにする事ができるのかを想像する事は難しい。 それ故に不適切に晒される事から情報を守る事はサービスが責任をもたなければならない。 HTTP クライアント実装は本来そのような保護を提供できないが、HTTP 状態管理がそのような情報が晒されるメカニズムとして使われる事をより難しくさせるような対応策を実装できる。

晒す事が HTTP 状態管理の使い方を容易にさせるか、それともいくつかの他の意図を容易にさせるかにかかわらず、HTTP クライアントが一般的に情報の追跡に不適切に晒される事に対してより強い保護を提供すべきという事には議論の余地がある。 しかし、他のメカニズムに関する問題はこの文書の範囲を超える。

3.1. HTTP クライアントに要求される能力

HTTP 状態管理を使う事に同意するユーザの気持ちは、サービスがその情報を適切に使うかどうか、また他のパーティからに晒す事を制限するかどうかをユーザが信用するかどうかによって、あるサービスから他のものへと変わるであろう。 それ故にユーザは、サービス毎に、クライアントが HTTP 状態管理を使うためのサービスの要求をサポートするかどうか制御できるべきである。 特に、以下に注意せよ。

1. クライアントは、ユーザによって明示的に使用可能となっていなければ HTTP 状態管理の要求に反応してはならない。
2. クライアントは、クライアントがサーバにどんな状態情報をも提供する前に、ユーザが状態情報を保持するためのサーバからのあらゆる個々の要求を再検討でき、承認あるいは拒否できる有効なインターフェイスを提供すべきである。
3. クライアントは、クライアントがサーバにどんな状態情報をも提供する前に、サーバからのあらゆる個々の要求へのレスポンス中すぐに、サービス毎に、ユーザがクライアントに特定のサービスからの状態情報を保持するための全ての要求を無視する事を指示できる有効なインターフェイスを提供すべきである。
4. クライアントは、たとえユーザが以前に状態情報を保持するためにサービスの要求を承認していたとしても、ユーザがサービスへのあらゆる状態情報の将来における転送を使用停止にでき、またそのサービスのために保存されたあらゆる状態情報を破棄できる有効なインターフェイスを提供すべきである。
5. クライアントは、ユーザが与えられたサービスのための状態管理情報を保持しない以前の要求を終了できる有効なインターフェイスを提供すべきである。

3.2. ドメイン一致アルゴリズムの限界

RFC-2965 の section 2 中のドメイン一致アルゴリズムは、クライアントが二つのドメインが同じサービスの一部かどうかを "推測" できるための帰納法として意図されている。 どのようなドメイン名が使われ得るかに付いての規則はほとんど無いし、ドメイン名の構造、またそれらがどのように選ばれているかはあるトップレベルドメインから他のものによって異なる (例 クライアントはドメインのどの部分がサービスに割り当てられているかを見分ける事はできない) 。 それ故に、特定のサービスに所属するドメインと、他のパーティに所属するドメインとを区別するために当てにできる (ドメイン一致アルゴリズムを含む) 列比較アルゴリズム{string comparison algorithm}は無い。

上述されたように、各々のサービスは最終的にユーザの情報は不適切に第三者に漏洩されないという事を保証するという責任を持つ。 念入りなドメイン名の選択による、あるいはドメイン名を第三者によって維持されるホストに割り当てる事による状態管理を通しての第三者への情報の漏洩は、少なくとも他の手段によって同じ情報を漏洩する事と同じくらい不適切である。

4. セキュリティについての考察

この文章全体が、セキュリティについての考察のためのものである。

5. 筆者のアドレス

 Keith Moore
 University of Tennessee Computer Science Department
 1122 Volunteer Blvd, Suite 203
 Knoxville TN, 37996-3450

 EMail: moore@cs.utk.edu


 Ned Freed
 Innosoft International, Inc.
 1050 Lakes Drive
 West Covina, CA 81790

 EMail: ned.freed@innosoft.com

6. 参照文献

RFC 1123

Braden, R., Requirements for Internet Hosts -- Application and Support, STD 3, RFC 1123, October 1989.

RFC 2965

Kristol, D. and L. Montulli, HTTP State Management Mechanism, RFC 2965, October 2000.

RFC 2109

Kristol, D. and L. Montulli, HTTP State Management Mechanism, RFC 2109, February 1997.

7. 著作権表示全文

Copyright © The Internet Society (2000). All Rights Reserved.

この文章とその翻訳は、複製し他人に配布する事ができ、またその実装についてのコメント、その他の方法を用いた説明、その補助となるような派生的作業はそれらの中に上の著作権表示とこの段落を含む事によって、その全て又は一部を、いかなる制約も受けずに、作成、複製、発表、及び配布する事ができる。 しかしながら、インターネット標準化プロセスにて定義されている著作権のための手続きに従わなければならないような場合の中でインターネット標準を開発するという目的に必要である、あるいは英語以外の言語に翻訳する必要があるという場合を除いて、この文章自体を、その著作権表示や、インターネット学会あるいは他のインターネット団体への参照を削除するような、いかなる変更もできない。

上で認めた制限された許諾は永続的なものであり、インターネット学会及びその継承者や譲渡者によって取り消される事は無い。

この文書とここに含まれた情報は、"そのまま {AS IS}" である事を基に提供され、インターネット学会、及び IETF は、この中の情報の使用が、商用利用及び特定用途においていかなる権利もいかなる暗黙的保障も侵害していないという保障への制限を含め、明示的に又は暗黙的に、全ての保障を放棄する。

謝辞

RFC Editer 機構の資金は、現在インターネット学会から提供されている。