メインコンテンツまでスキップ

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

このセクションは、HTTP メッセージの構文、解析、およびルーティングに関連する既知のセキュリティ上の考慮事項を、開発者、情報提供者、およびユーザーに知らせることを目的としています。HTTP のセマンティクスとペイロードに関するセキュリティ上の考慮事項は、[RFC7231] で扱われています。

9.1. 権限の確立​

HTTP は、権威あるレスポンスという概念に依存しています。それは、レスポンスメッセージの発信時点におけるターゲットリソースの状態を考慮して、そのリクエストにとって最も適切なレスポンスであると、ターゲット URI 内で識別された権限によって (またはその指示の下で) 判断されたレスポンスです。共有キャッシュなどの非権威のソースからのレスポンスの提供は、パフォーマンスと可用性を向上させるためにしばしば有用ですが、そのソースが信頼できるか、信頼されていないレスポンスを安全に使用できる範囲においてのみ有用です。

残念ながら、権限の確立は困難な場合があります。たとえば、フィッシングはユーザーの権限の認識を狙う攻撃であり、その認識は、ハイパーテキスト内で類似のブランディングを提示することによって、場合によっては authority 構成要素を曖昧にする userinfo の助けを借りて、誤らせることができます (セクション 2.7.1 を参照してください)。ユーザーエージェントは、ユーザーが行動を起こす前にターゲット URI を容易に検査できるようにし、userinfo が存在する場合にそれを際立たせて区別する (または拒否する) ことによって、また、参照元の文書が未知または信頼できないソースからのものである場合に保存された資格情報や cookie を送信しないことによって、フィッシング攻撃の影響を低減できます。

登録名が authority 構成要素で使用される場合、"http" URI スキーム (セクション 2.7.1) は、権威あるレスポンスをどこで見つけられるかを判断するために、ユーザーのローカルな名前解決サービスに依存します。これは、ユーザーのネットワークホストテーブル、キャッシュされた名前、または名前解決ライブラリへの攻撃が、権限の確立に対する攻撃の経路になることを意味します。同様に、ユーザーが Domain Name Service (DNS) に選ぶサーバー、およびそこから解決結果を得るサーバーの階層は、アドレスマッピングの真正性に影響を与える可能性があります。DNS Security Extensions (DNSSEC, [RFC4033]) は、真正性を向上させる 1 つの方法です。

さらに、IP アドレスが取得された後、"http" URI の権限の確立は、Internet Protocol ルーティングへの攻撃に対して脆弱です。

"https" スキーム (セクション 2.7.2) は、ネゴシエートされた TLS 接続が保護されており、クライアントが通信相手のサーバーの身元がターゲット URI の authority 構成要素と一致することを適切に検証することを条件として ([RFC2818] を参照してください)、権限の確立に対するこれらの潜在的な攻撃の多くを防止する (または少なくとも明らかにする) ことを意図しています。そのような検証を正しく実装することは困難な場合があります ([Georgiev] を参照してください)。

9.2. 仲介者のリスク​

その性質上、HTTP 仲介者は中間者であり、したがって中間者攻撃の機会を表します。仲介者が動作するシステムの侵害は、深刻なセキュリティとプライバシーの問題をもたらす可能性があります。仲介者は、セキュリティ関連情報、個々のユーザーと組織に関する個人情報、およびユーザーとコンテンツプロバイダーに属する専有情報にアクセスできる場合があります。侵害された仲介者、またはセキュリティとプライバシーの考慮事項を無視して実装または構成された仲介者は、幅広い潜在的な攻撃の実行に使用される可能性があります。

共有キャッシュを含む仲介者は、[RFC7234] のセクション 8 で説明されているように、キャッシュポイズニング攻撃に対して特に脆弱です。

実装者は、自らの設計とコーディングの決定、およびオペレーターに提供する構成オプション (特にデフォルト構成) のプライバシーとセキュリティへの影響を考慮する必要があります。

ユーザーは、仲介者がそれを運用する人々以上に信頼できるわけではないことに気付く必要があります。HTTP 自体はこの問題を解決できません。

9.3. プロトコル要素の長さによる攻撃​

HTTP は主にテキストの文字区切りフィールドを使用するため、パーサーは、非常に長い (または非常に遅い) データストリームの送信に基づく攻撃、特に実装が事前定義された長さを持たないプロトコル要素を期待している場合に、しばしば脆弱です。

相互運用性を促進するために、request-line (セクション 3.1.1) およびヘッダーフィールド (セクション 3.2) の最小サイズ制限について、具体的な推奨がなされています。これらは最小限の推奨であり、リソースが限られた実装でもサポートできるように選ばれており、ほとんどの実装は実質的により高い制限を選ぶと予想されます。

サーバーは、長すぎる request-target ([RFC7231] のセクション 6.5.12) または大きすぎるリクエストペイロード ([RFC7231] のセクション 6.5.11) を持つメッセージを拒否できます。容量制限に関連する追加のステータスコードは、HTTP への拡張 [RFC6585] によって定義されています。

受信者は、リクエストメソッド、レスポンスのステータス句、ヘッダー field-name、数値、および本文チャンクを含む (ただしこれらに限らない) 他のプロトコル要素を処理する範囲を注意深く制限すべきです。そのような処理を制限しないと、バッファオーバーフロー、算術オーバーフロー、またはサービス拒否攻撃への脆弱性の増大をもたらす可能性があります。

9.4. レスポンス分割​

レスポンス分割 (別名 CRLF インジェクション) は、Web の使用に対するさまざまな攻撃で使用される一般的な技法であり、HTTP メッセージフレーミングの行ベースの性質と、持続的接続におけるリクエストのレスポンスへの順序付けられた関連付け [Klein] を悪用します。この技法は、リクエストが共有キャッシュを通過する場合に特に有害となり得ます。

レスポンス分割は、攻撃者が、リクエストの何らかのパラメータ内にエンコードされたデータを送信し、それが後でデコードされてレスポンスのいずれかのレスポンスヘッダーフィールド内にエコーされるという、サーバー (通常はアプリケーションサーバー内) の脆弱性を悪用します。デコードされたデータが、レスポンスが終了し後続のレスポンスが始まったかのように見えるように細工されている場合、レスポンスは分割され、見かけ上の 2 番目のレスポンス内の内容は攻撃者によって制御されます。攻撃者はその後、同じ持続的接続上で任意の他のリクエストを行い、(仲介者を含む) 受信者を騙して、分割の後半が 2 番目のリクエストへの権威ある回答であると信じ込ませることができます。

たとえば、request-target 内のパラメータがアプリケーションサーバーによって読み取られ、リダイレクト内で再利用される結果、同じパラメータがレスポンスの Location ヘッダーフィールドにエコーされる場合があります。パラメータがアプリケーションによってデコードされ、レスポンスフィールドに配置されるときに適切にエンコードされない場合、攻撃者は、エンコードされた CRLF オクテットおよび他の内容を送信して、アプリケーションの単一のレスポンスを 2 つ以上のレスポンスに見せかけることができます。

レスポンス分割に対する一般的な防御は、エンコードされた CR および LF に見えるデータ (例えば "%0D" および "%0A") を求めてリクエストをフィルタリングすることです。しかしながら、それは、アプリケーションサーバーが文字セットのトランスコーディング、XML エンティティの変換、base64 デコード、sprintf の再フォーマットなど、より不明瞭なデータ変換ではなく、URI デコードのみを行っていることを前提としています。より効果的な緩和策は、サーバーのコアプロトコルライブラリ以外がヘッダーセクション内で CR または LF を送信することを防ぐことです。これは、ヘッダーフィールドの出力を、不正なオクテットをフィルタリングする API に制限し、アプリケーションサーバーがプロトコルストリームに直接書き込むことを許可しないことを意味します。

9.5. リクエスト密輸​

リクエスト密輸 ([Linhart]) は、さまざまな受信者間のプロトコル解析の違いを悪用して、一見無害なリクエスト内に追加のリクエスト (そうでなければポリシーによってブロックまたは無効化される可能性があるもの) を隠す技法です。レスポンス分割と同様に、リクエスト密輸は、HTTP の使用に対するさまざまな攻撃につながる可能性があります。

本仕様は、リクエスト密輸の有効性を低減するために、特にセクション 3.3.3 のメッセージフレーミングに関して、リクエスト解析に対する新しい要件を導入しました。

9.6. メッセージの完全性​

HTTP は、メッセージの完全性を保証するための特定の機構を定義せず、代わりに、基盤となるトランスポートプロトコルのエラー検出能力と、完全性を検出するための長さまたはチャンク区切りのフレーミングの使用に依存しています。内容に適用されるハッシュ関数やデジタル署名など、追加の完全性機構は、拡張可能なメタデータのヘッダーフィールドを介してメッセージに選択的に追加できます。歴史的に、単一の完全性機構の欠如は、ほとんどの HTTP 通信の非公式な性質によって正当化されてきました。しかしながら、情報アクセス機構としての HTTP の普及により、メッセージの完全性の検証が決定的に重要である環境での使用が増加しています。

ユーザーエージェントは、メッセージの完全性の失敗を検出して報告する構成可能な手段を実装することが奨励されており、それにより、完全性が必要とされる環境でそれらの手段を有効にできます。たとえば、病歴や薬物相互作用の情報を表示するために使用されているブラウザーは、そのような情報がプロトコルによって不完全、期限切れ、または転送中に破損したと検出されたときに、ユーザーに示す必要があります。そのような機構は、ユーザーエージェントの拡張、またはレスポンス内のメッセージ完全性メタデータの存在を介して選択的に有効にできます。少なくとも、ユーザーエージェントは、そのような検証が望まれるときに、ユーザーが完全なレスポンスメッセージと不完全なレスポンスメッセージ (セクション 3.4) を区別できるようにする何らかの指標を提供すべきです。

9.7. メッセージの機密性​

HTTP は、それが望まれるときにメッセージの機密性を提供するために、基盤となるトランスポートプロトコルに依存しています。HTTP は、トランスポートプロトコルから独立するように特別に設計されており、そのため、さまざまな形式の暗号化された接続上で使用でき、そのようなトランスポートの選択は、URI スキームの選択またはユーザーエージェントの構成内で示されます。

"https" スキームは、セクション 2.7.2 で説明されているように、機密の接続を必要とするリソースを識別するために使用できます。

9.8. サーバーログ情報のプライバシー​

サーバーは、時間の経過とともにユーザーのリクエストに関する個人データを保存できる立場にあり、それはユーザーの閲覧パターンや関心の対象を識別する可能性があります。特に、仲介者で収集されたログ情報は、多くの場合、個々のユーザーに追跡可能な、多数のサイトにまたがるユーザーエージェントの対話の履歴を含みます。

HTTP のログ情報は本質的に機密であり、その取り扱いはしばしば法律や規制によって制約されます。ログ情報は安全に保存する必要があり、その分析のためには適切なガイドラインに従う必要があります。個々のエントリ内の個人情報の匿名化は助けになりますが、一般に、他のアクセス特性との相関に基づいて実際のログの痕跡が再識別されるのを防ぐには十分ではありません。そのため、特定のクライアントに紐付けられたアクセス痕跡は、そのキーが仮名であっても公開するのは安全ではありません。

盗難または偶発的な公開のリスクを最小限にするために、ログ情報は、セキュリティ、監査、または不正防止のための運用上のニーズを支えるためにその情報がもはや不要になった時点でできるだけ早く、ユーザー識別子、IP アドレス、およびユーザーが提供するクエリパラメータを含む個人を特定できる情報を取り除くべきです。