9. セキュリティの考慮事項 (Security Considerations)
このセクションは、HTTPセマンティクスおよびインターネット上で情報を転送するためのその使用に関連する既知のセキュリティ問題について、開発者、情報プロバイダー、およびユーザーに通知することを目的としています。メッセージ構文、解析、およびルーティングに関連する考慮事項は[RFC7230]で議論され、HTTPキャッシングに関連する考慮事項は[RFC7234]で議論されています。
以下の考慮事項のリストは網羅的ではありません。HTTPセマンティクスに関連するほとんどのセキュリティ問題は、サーバー側アプリケーション(HTTPインターフェイスの背後にあるコード)の保護、HTTP経由で受信したコンテンツのユーザーエージェント処理の保護、またはHTTPヘッダーフィールドから取得した情報の安全な使用に関するものです。これらの懸念の多くは相互依存しています。クライアントソフトウェアの弱点はサーバーソフトウェアの脆弱性を悪用するために使用される可能性があり、その逆もあります。
9.1. ファイル名とパス名に基づく攻撃 (Attacks Based on File and Path Names)
オリジンサーバーは、ターゲットURIからリソース表現へのマッピングを管理するために、ローカルファイルシステムを頻繁に利用します。ほとんどのファイルシステムは、悪意のあるファイル名またはパス名から保護するように設計されていません。したがって、オリジンサーバーは、ターゲットリソースをファイル、フォルダー、またはディレクトリにマッピングする際に、システムに特別な意味を持つ名前へのアクセスを避ける必要があります。
たとえば、UNIX、Microsoft Windows、およびその他のオペレーティングシステムは、現在のディレクトリの1つ上のディレクトリレベルを示すパスコンポーネントとして".."を使用し、システムデバイスにデータを送信するために特別に名前が付けられたパスまたはファイル名を使用します。他のタイプのストレージシステム内にも同様の命名規則が存在する可能性があります。同様に、ローカルストレージシステムには、無効または予期しない文字を処理する際にセキュリティよりもユーザーフレンドリーさを優先する迷惑な傾向があり、意図しないパターンを引き起こす可能性のある方法でそれらを再構成します。
実装は、同じ文字列を複数回エスケープまたはアンエスケープしないように注意する必要があります。以前にエスケープされた文字列をアンエスケープすると、安全でない文字が生じる可能性があるためです。特に、リクエストターゲットを単純にアンエスケープし、追加のチェックなしにファイルシステムパスとして使用することは安全ではありません。
この仕様のターゲットURIに関する制限は、これらの種類の攻撃を防ぐには十分ではないことに注意してください。それらは実装固有のチェックによって補完される必要があります。
9.2. コマンド、コード、またはクエリインジェクションに基づく攻撃 (Attacks Based on Command, Code, or Query Injection)
オリジンサーバーは、システムサービスの識別、データベースエントリの選択、またはデータソースの選択の手段として、URI内のパラメータを頻繁に使用します。ただし、リクエストで受信したデータは信頼できません。攻撃者は、コマンド呼び出し、言語インタープリター、またはデータベースインターフェイスを介して渡されたときにコマンド、コード、またはクエリとして誤解される可能性のあるデータを含むように、リクエストデータ要素(メソッド、リクエストターゲット、ヘッダーフィールド、またはボディ)のいずれかを構築できます。
たとえば、SQLインジェクションは一般的な攻撃であり、リクエストターゲットまたはヘッダーフィールド(Host、Refererなど)の一部に追加のクエリ言語が挿入されます。受信したデータがSQL SELECT文内で直接使用される場合、クエリ言語は単純な文字列値ではなくデータベースコマンドとして解釈される可能性があります。この種の実装の脆弱性は、防止が容易であるにもかかわらず、非常に一般的です。
一般に、リソース実装は、シェルコマンドまたはクエリの組み立てにおいてリクエストデータの使用を避けるべきです(ought to)。このような使用が必要な場合、データは使用前に適切にエスケープされる必要があります(データを受信するシステムに適したもの)。
9.3. 個人情報の開示 (Disclosure of Personal Information)
クライアントは、ユーザーがリソースとやり取りするために提供する情報(ユーザーの名前、場所、メールアドレス、パスワード、暗号化キーなど)と、ユーザーの閲覧活動に関する情報(履歴、ブックマークなど)の両方を含む、大量の個人情報にアクセスすることがよくあります。実装は、そのような情報の意図しない漏洩を防ぐ必要があります。
9.3.1. アプリケーションデータによる開示 (Disclosure via Application Data)
アプリケーションは、情報の開示をリクエストを完了するために必要なもののみに制限し、ユーザーまたはアプリケーションの内部構造に固有の情報の開示を避けるべきです(ought to)(セクション5.5.3およびセクション7.4.2)。
9.3.2. Refererによる開示 (Disclosure via Referer)
Refererヘッダーフィールドは、クライアントがリクエストターゲットを取得した場所をサーバーに宣伝することを可能にし、これによりユーザーのコンテキストまたは閲覧履歴に関する情報が明らかになる可能性があります。リクエストターゲットが第三者のソースによって提供された場合、ユーザーはその情報を機密にしておきたい場合があります(医療情報からのリンクなど)。したがって、ユーザーエージェントは、Refererフィールドを送信しないか、フィールドのより明示性の低い(原点のみなど)バージョンを送信するオプションをユーザーに提供すべきです(ought to)(セクション5.5.2)。
参照ページが安全なプロトコルで受信された場合、クライアントは(非安全な)HTTPリクエストにRefererヘッダーフィールドを含めるべきではありません(ought not to)。
HTTPプロトコルを使用するサービスの作成者は、個人識別情報、アカウント番号、パスワードなどの機密情報を送信するために、フォームエンコードされたコンテンツを含むGETおよびPOSTリクエストを使用すべきではありません(ought not to)。これにより、そのデータが暗号化されずにリクエストターゲットまたはコンテンツで送信されるためです。サービス設計者は、そのような機密情報を送信するためにメッセージボディを含むPOSTメソッドを使用すべきであり(ought to)、ログ、ブックマークなどで公開される可能性があるため、リクエストターゲットにそのような情報を含めないように注意する必要があります。
9.3.3. User-Agentによる開示 (Disclosure via User-Agent)
User-Agentヘッダーフィールドには、特に他の特性と組み合わせた場合、特にユーザーエージェントがユーザーのシステムまたは拡張機能に関する過度の詳細を送信する場合、特定のデバイスを一意に識別するのに十分な情報が含まれることがよくあります。実装はそのような情報を制限すべきです(ought to)(セクション5.5.3)。
9.4. サーバーログ情報のプライバシー (Privacy of Server Log Information)
サーバーは、時間の経過とともにユーザーのリクエストに関する個人データを保存する立場にあり、それは彼らの読書パターンまたは興味のある主題を識別する可能性があります。特に、仲介者で収集されたログ情報には、多数のサイトにわたるユーザーエージェントのやり取りの履歴が含まれることが多く、それは個々のユーザーまで追跡できます。
HTTPログ情報は本質的に機密性があります。その取り扱いは法律や規制によって制約されることがよくあります。ログ情報は安全に保存される必要があり、その分析には適切なガイドラインに従う必要があります。個々のエントリ内の個人情報の匿名化は役立ちますが、一般に、他のアクセス特性との相関に基づいて実際のログトレースが再識別されるのを防ぐには不十分です。そのため、特定のクライアントに関連付けられたアクセストレースは、匿名化されるか、機密として扱われるべきです(ought to)。
盗難または偶発的な公開のリスクを最小限に抑えるために、ログ情報はできるだけ早く削除されるべきです(ought to)。
9.5. リダイレクト後のフラグメントの開示 (Disclosure of Fragment after Redirects)
URI参照内で使用されるフラグメント識別子はリクエストで送信されませんが、実装者は、それらがユーザーエージェントおよび応答の結果として実行される拡張機能またはスクリプトに表示されることを認識すべきです(ought to)。特に、リダイレクトが発生し、元のリクエストのフラグメント識別子がLocationの新しい参照によって継承される場合(セクション7.1.2)、これはセキュリティ上の影響を及ぼす可能性があります。
9.6. 製品情報の開示 (Disclosure of Product Information)
ServerおよびUser-Agentヘッダーフィールドは、それぞれの送信者のソフトウェアシステムに関する情報を明らかにすることがよくあります。理論的には、これにより攻撃者が既知のセキュリティホールを悪用しやすくなります。実際には、攻撃者は使用されているソフトウェアバージョンに関係なく、すべての潜在的なホールを試す傾向があります。
ネットワークファイアウォールを介したポータルとして機能するプロキシは、ファイアウォールの背後にあるホストを識別する可能性のあるヘッダー情報の転送に関して特別な予防措置を講じるべきです(ought to)。Viaヘッダーフィールドは、仲介者が機密性の高いマシン名を仮名に置き換えることを可能にします。
9.7. ブラウザフィンガープリンティング (Browser Fingerprinting)
ブラウザフィンガープリンティングは、その独自の特性セットを通じて、特定のユーザーエージェントを時間の経過とともに識別するための一連の技術です。これらの特性には、基盤となるトランスポートプロトコルの使用方法、機能能力、スクリプト環境に関連する情報が含まれる可能性がありますが、ここで特に興味深いのは、HTTP経由で通信される可能性のある独自の特性のセットです。フィンガープリンティングは、ユーザーがCookieなどの他の形式のデータに対して持つ可能性のある対応する制御なしに、時間の経過とともにユーザーエージェントの動作を追跡できるようにするため、プライバシーの懸念と見なされます(セクション9.4)。
フィンガープリンティングを可能にするのに十分なユニークな情報をサーバーに明らかにする可能性のあるリクエストヘッダーフィールドが多数あります。Fromヘッダーフィールドは最も明白ですが、Fromはユーザーが自己識別を望む場合にのみ送信されることが期待されます。同様に、Cookieヘッダーフィールドは再識別を可能にするように意図的に設計されているため、フィンガープリンティングの懸念は、ユーザーエージェントによってCookieが無効化または制限されている場合にのみ適用されます。
User-Agentヘッダーフィールドには、他の特性と組み合わせた場合、特にユーザーエージェントがユーザーのシステムまたは拡張機能に関する過度の詳細を送信する場合、特定のデバイスを一意に識別するのに十分な情報が含まれる可能性があります。ただし、ユーザーが最も予期しない独自の情報のソースは、Accept、Accept-Charset、Accept-Encoding、およびAccept-Languageヘッダーフィールドを含むプロアクティブネゴシエーション(セクション3.4.1)です。
フィンガープリンティングの懸念に加えて、Accept-Languageヘッダーフィールドの詳細な使用は、ユーザーが私的な性質であると考える可能性のある情報を明らかにする可能性があります。たとえば、特定の言語セットの理解は、特定の民族グループのメンバーシップと強く相関している可能性があります。このようなプライバシーの損失を制限するアプローチは、ユーザーエージェントがホワイトリストに登録されたサイトを除いてAccept-Languageの送信を省略することです。これは、おそらく言語ネゴシエーションが有用である可能性を示すVaryヘッダーフィールドを検出した後の対話を介して行われます。
プロキシがプライバシーを強化するために使用される環境では、ユーザーエージェントはプロアクティブネゴシエーションヘッダーフィールドの送信において保守的であるべきです(ought to)。高度なヘッダーフィールドの構成可能性を提供する汎用ユーザーエージェントは、詳細が多すぎる場合に生じる可能性のあるプライバシーの損失についてユーザーに通知すべきです(ought to)。極端なプライバシー対策として、プロキシは中継されたリクエストでプロアクティブネゴシエーションヘッダーフィールドをフィルタリングできます。
9.8. バリデータの保持 (Validator Retention)
レスポンスメタデータ(セクション7.2)に含まれるバリデータは、キャッシュされたレスポンスの通常の処理と有効期限切れに必要な期間だけキャッシュによって保持されるべきです(ought to)。バリデータを長期間保持すると、古いバリデータが単一のユーザーの複数のリクエストにわたる活動を相関させるために使用される可能性があるため、プライバシーの問題につながる可能性があります。これは、サーバーがバリデータ値を個々のユーザーと明示的に関連付けていない場合でも同様です。キャッシュとして機能していないユーザーエージェントは、バリデータを長期間保持すべきではありません(ought not to)。