15. Security Considerations (セキュリティに関する考慮事項)

15 セキュリティに関する考慮事項

この節は、本文書で記述されている HTTP/1.1 のセキュリティ上の限界について、アプリケーション開発者、情報提供者、および利用者に知らせることを目的としている。ここでの議論には、明らかになった問題に対する決定的な解決策は含まれていないが、セキュリティリスクを低減するためのいくつかの提案は行っている。

15.1 Personal Information (個人情報)

HTTP クライアントはしばしば大量の個人情報 (例えば利用者の氏名、所在地、メールアドレス、パスワード、暗号鍵など) を扱う立場にあり、これらの情報が HTTP プロトコルを通じて他の情報源へ意図せず漏洩することを防ぐよう、非常に注意すべきである (SHOULD)。このような情報の配布を利用者が制御できる便利なインターフェイスを提供すること、および設計者と実装者がこの領域で特に注意することを、我々は強く推奨する。歴史が示すように、この領域での誤りは深刻なセキュリティ上および/またはプライバシー上の問題をしばしば引き起こし、実装者の会社に対して極めて不利な評判を生み出してきた。

15.1.1 Abuse of Server Log Information (サーバーログ情報の悪用)

サーバーは、利用者のリクエストに関する個人データを保存できる立場にあり、そのデータは利用者の閲覧パターンや関心のある主題を特定しうるものである。この情報は明らかに機密性を有しており、一部の国ではその取り扱いが法律によって制約される場合がある。HTTP プロトコルを用いてデータを提供する人々は、公開された結果から特定可能な個人の許可なく、そのような資料が配布されないことを保証する責任がある。

15.1.2 Transfer of Sensitive Information (機密情報の転送)

他の汎用データ転送プロトコルと同様、HTTP は転送するデータの内容を規制できず、また、任意のリクエストの文脈において特定の情報片がどの程度機密であるかを事前に判断する方法も存在しない。したがって、アプリケーションは、その情報の提供者に対して可能な限り多くの制御を提供すべきである (SHOULD)。この文脈で特に言及に値するヘッダフィールドが 4 つある。Server、Via、Referer、および From である。

サーバーの具体的なソフトウェアバージョンを明かすと、セキュリティホールを含むことが知られているソフトウェアに対する攻撃に対して、サーバーマシンがより脆弱になる可能性がある。実装者は Server ヘッダフィールドを構成可能なオプションにすべきである (SHOULD)。

ネットワークファイアウォールを通過するポータルとして機能するプロキシは、ファイアウォールの背後のホストを識別するヘッダ情報の転送に関して、特別な予防措置を講ずべきである (SHOULD)。特に、ファイアウォールの背後で生成された Via フィールドは、削除するか、無害化したバージョンに置き換えるべきである (SHOULD)。

Referer ヘッダは、閲覧パターンを調査したり逆リンクをたどったりすることを可能にする。これは非常に有用な場合があるが、利用者の詳細が Referer に含まれる情報から分離されていないと、その力は悪用されうる。個人情報が削除されている場合でも、Referer ヘッダは、公開が不適切であるような非公開文書の URI を示している可能性がある。

From フィールドで送信される情報は、利用者のプライバシー上の利益や利用者のサイトのセキュリティポリシーと衝突する可能性がある。したがって、利用者がこのフィールドの内容を無効化、有効化、および変更できない限り、送信すべきではない (SHOULD NOT)。利用者は、利用者設定またはアプリケーションのデフォルト設定の中で、このフィールドの内容を設定できなければならない (MUST)。

我々は、From および Referer 情報の送信を利用者が有効化または無効化するための、便利なトグルインターフェイスを提供することを提案する。ただし必須とはしない。

User-Agent (14.43 節) または Server (14.38 節) のヘッダフィールドは、特定のクライアントまたはサーバーが悪用される可能性のある特定のセキュリティホールを抱えていることを判断するために使われることがある。残念ながら、同じ情報は、HTTP が現在より良いメカニズムを持たない他の価値ある目的にもしばしば使われている。

15.1.3 Encoding Sensitive Information in URI's (URI における機密情報のエンコード)

リンクの出所が非公開情報である場合、あるいは本来は非公開の情報源を明かす場合があるため、Referer フィールドを送信するかどうかを利用者が選択できることを強く推奨する。例えば、ブラウザクライアントは、公然と閲覧する/匿名で閲覧するためのトグルスイッチを持ち、それぞれ Referer および From 情報の送信を有効化/無効化することができる。

参照元のページがセキュアなプロトコルで転送された場合、クライアントは (非セキュアな) HTTP リクエストに Referer ヘッダフィールドを含めるべきではない (SHOULD NOT)。

HTTP プロトコルを使用するサービスの作者は、機密データの送信に GET ベースのフォームを使用すべきではない (SHOULD NOT)。これは、そのデータが Request-URI にエンコードされる原因になるためである。多くの既存のサーバー、プロキシ、およびユーザーエージェントは、リクエスト URI を第三者に見られる可能性のある何らかの場所に記録する。サーバーは代わりに POST ベースのフォーム送信を使用できる。

15.1.4 Privacy Issues Connected to Accept Headers (Accept ヘッダに関連するプライバシー問題)

Accept リクエストヘッダは、アクセスされるすべてのサーバーに対して利用者に関する情報を明かす可能性がある。特に Accept-Language ヘッダは、利用者が私的な性質のものと考える情報を明かす可能性がある。特定の言語の理解度は、特定の民族集団への帰属と強く相関することが多いためである。すべてのリクエストで送信される Accept-Language ヘッダの内容を構成するオプションを提供するユーザーエージェントには、その構成プロセスに、伴われるプライバシーの損失を利用者に気づかせるメッセージを含めることを強く推奨する。

プライバシーの損失を限定する一つの方法は、ユーザーエージェントがデフォルトで Accept-Language ヘッダの送信を省略し、サーバーが生成した Vary レスポンスヘッダフィールドを調べることによって、その送信がサービスの品質を向上させうると検出した場合に、そのサーバーへ Accept-Language ヘッダの送信を開始するかどうかを利用者に尋ねる、というものである。

すべてのリクエストで送信される、入念に利用者向けにカスタマイズされた accept ヘッダフィールドは、特にそれらが品質値 (quality values) を含む場合、サーバーによって比較的信頼でき、長期間有効な利用者識別子として使われうる。そのような利用者識別子は、コンテンツ提供者にクリック軌跡の追跡を可能にし、また、協力し合うコンテンツ提供者に、個々の利用者のサーバーをまたいだクリック軌跡やフォーム送信を突き合わせることを可能にする。プロキシの背後にいない多くの利用者にとっては、ユーザーエージェントを実行しているホストのネットワークアドレスも、長期間有効な利用者識別子として機能することに注意されたい。プライバシーを強化するためにプロキシが使われる環境では、ユーザーエージェントは、エンドユーザーに対して accept ヘッダの構成オプションを提供する際に慎重であるべきである。極端なプライバシー対策として、プロキシは中継するリクエストの accept ヘッダをフィルタリングすることもできる。高度なヘッダ構成可能性を提供する汎用ユーザーエージェントは、伴われうるプライバシーの損失について利用者に警告すべきである (SHOULD)。

15.2 Attacks Based On File and Path Names (ファイル名とパス名に基づく攻撃)

HTTP オリジンサーバーの実装は、HTTP リクエストによって返される文書を、サーバー管理者が意図したものだけに制限するよう注意すべきである (SHOULD)。HTTP サーバーが HTTP URI を直接ファイルシステム呼び出しに変換する場合、サーバーは、HTTP クライアントに配信することが意図されていないファイルを提供しないよう、特に注意しなければならない (MUST)。例えば、UNIX、Microsoft Windows、およびその他のオペレーティングシステムでは、".." が現在のディレクトリより一つ上のディレクトリ階層を示すパス構成要素として使われる。そのようなシステムでは、HTTP サーバーは、Request-URI 中のそのような構成が、HTTP サーバーを介してアクセス可能であることが意図されたリソース以外へのアクセスを許すことになる場合、その構成を許可してはならない (MUST)。同様に、サーバー内部での参照のみを意図したファイル (アクセス制御ファイル、構成ファイル、スクリプトコードなど) は、機密情報を含む可能性があるため、不適切な取得から保護しなければならない (MUST)。経験は、そのような HTTP サーバー実装におけるわずかなバグがセキュリティリスクに転じてきたことを示している。

15.3 DNS Spoofing (DNS なりすまし)

HTTP を使用するクライアントはドメインネームサービスに大きく依存しており、したがって一般に、IP アドレスと DNS 名を意図的に誤って対応付けることに基づくセキュリティ攻撃を受けやすい。クライアントは、IP 番号と DNS 名の対応付けが引き続き有効であると仮定する際に慎重になる必要がある。

特に、HTTP クライアントは、以前のホスト名検索の結果をキャッシュするのではなく、IP 番号と DNS 名の対応付けの確認を自らの名前解決機構に委ねるべきである (SHOULD)。多くのプラットフォームは、適切な場合にホスト名検索をローカルにキャッシュすることがすでに可能であり、そのように構成すべきである (SHOULD)。ただし、これらの検索結果をキャッシュすることが適切なのは、ネームサーバーが報告する TTL (Time To Live) 情報が、キャッシュされた情報が引き続き有用であり続ける見込みが高いことを示す場合に限られる。

HTTP クライアントが性能向上を達成するためにホスト名検索の結果をキャッシュする場合、DNS が報告する TTL 情報を遵守しなければならない (MUST)。

HTTP クライアントがこの規則を遵守しない場合、以前にアクセスしたサーバーの IP アドレスが変化したときに、なりすましを受ける可能性がある。ネットワークの再番号付けはますます一般的になると予想されるため [24]、この形態の攻撃の可能性は増大する。したがって、この要件を遵守することは、この潜在的なセキュリティ脆弱性を低減する。

この要件はまた、同じ DNS 名を使用する複製サーバーに対するクライアントの負荷分散動作を改善し、その戦略を使用するサイトへのアクセスで利用者が失敗を経験する可能性を低減する。

15.4 Location Headers and Spoofing (Location ヘッダとなりすまし)

単一のサーバーが互いに信頼し合わない複数の組織をサポートしている場合、そのサーバーは、それらの組織の制御下で生成されたレスポンスにおける Location および Content-Location ヘッダの値を検査し、それらが自分に権限のないリソースを無効化しようとしていないことを確認しなければならない (MUST)。

15.5 Content-Disposition Issues (Content-Disposition の問題)

HTTP においてしばしば実装される Content-Disposition ヘッダ (19.5.1 節を参照) の由来である RFC 1806 [35] には、きわめて深刻なセキュリティ上の考慮事項が数多くある。Content-Disposition は HTTP 標準の一部ではないが、広く実装されているため、我々は実装者のためにその使用法とリスクをここに記録する。詳細は RFC 2183 [49] (RFC 1806 を更新するもの) を参照されたい。

15.6 Authentication Credentials and Idle Clients (認証資格情報とアイドル状態のクライアント)

既存の HTTP クライアントとユーザーエージェントは通常、認証情報を無期限に保持する。HTTP/1.1 は、サーバーがクライアントに対してこれらのキャッシュされた資格情報を破棄するよう指示する方法を提供していない。これは、HTTP へのさらなる拡張を必要とする重大な欠陥である。資格情報のキャッシュがアプリケーションのセキュリティモデルに干渉しうる状況には、以下が含まれるが、これらに限定されない。

  - クライアントが長期間アイドル状態にあり、その後サーバーがクライアントに対して資格情報の再入力を利用者に促させたいと考える場合。

  - アプリケーションがセッション終了の指示 (ページ上の `logout` ボタンや `commit` ボタンなど) を含み、その後にアプリケーションのサーバー側が、クライアントが資格情報を保持し続ける理由はもはやないと「認識する」場合。

これは現在、別途検討中である。この問題の一部に対する回避策はいくつかあり、我々はスクリーンセーバーのパスワード保護、アイドルタイムアウト、およびこの問題に内在するセキュリティ問題を緩和するその他の方法の使用を推奨する。特に、資格情報をキャッシュするユーザーエージェントには、利用者の制御下でキャッシュされた資格情報を破棄するための、容易にアクセスできるメカニズムを提供することを推奨する。

15.7 Proxies and Caching (プロキシとキャッシュ)

HTTP プロキシはその性質上、中間者 (man-in-the-middle) であり、中間者攻撃の機会を提供する。プロキシが動作するシステムが侵害されると、深刻なセキュリティおよびプライバシーの問題を引き起こしうる。プロキシは、セキュリティ関連情報、個々の利用者と組織に関する個人情報、および利用者とコンテンツ提供者に帰属する専有情報にアクセスできる。侵害されたプロキシ、またはセキュリティとプライバシーへの配慮なしに実装もしくは構成されたプロキシは、広範な潜在的攻撃の遂行に使われる可能性がある。

プロキシ運用者は、機密情報を含むか転送するあらゆるシステムを保護するのと同じように、プロキシが動作するシステムを保護すべきである。特に、プロキシで収集されるログ情報は、高度に機密性の高い個人情報、および/または組織に関する情報を含むことがよくある。ログ情報は慎重に保護し、適切な使用ガイドラインを策定して遵守すべきである (15.1.1 節)。

キャッシュするプロキシは、追加の潜在的な脆弱性をもたらす。キャッシュの内容は悪意ある悪用にとって魅力的な標的だからである。キャッシュの内容は HTTP リクエストの完了後も存続するため、キャッシュへの攻撃は、利用者がその情報はネットワークから削除されたと信じたずっと後に、情報を明かすことがある。したがって、キャッシュの内容は機密情報として保護すべきである。

プロキシの実装者は、自らの設計およびコーディング上の決定、ならびにプロキシ運用者に提供する構成オプション (特にデフォルト構成) がもたらすプライバシーとセキュリティへの影響を考慮すべきである。

プロキシの利用者は、自分がプロキシを運営する人々以上に信頼に値するわけではないことを認識する必要がある。HTTP 自体はこの問題を解決できない。

適切な場合における暗号技術の賢明な使用は、広範なセキュリティおよびプライバシー攻撃から保護するのに十分な場合がある。そのような暗号技術は HTTP/1.1 仕様の範囲外である。

15.7.1 Denial of Service Attacks on Proxies (プロキシに対するサービス妨害攻撃)

それらは存在する。防御するのは困難である。研究は続いている。用心されたい。