11. セキュリティに関する考察 (Security Considerations)
このセクションは、HTTP メッセージ構文と解析に関連する既知のセキュリティ考慮事項について、開発者、情報プロバイダー、およびユーザーに通知することを目的としています。HTTP セマンティクス、コンテンツ、およびルーティングに関するセキュリティ考慮事項は、[HTTP] で扱われています。
11.1. レスポンス分割 (Response Splitting)
レスポンス分割 (別名 CRLF インジェクション) は、Web 使用に対するさまざまな攻撃で使用される一般的な手法であり、HTTP メッセージフレーミングの行ベースの性質と、持続的接続でのリクエストとレスポンスの順序付けられた関連付けを利用します [Klein]。この手法は、リクエストが共有キャッシュを通過する場合に特に有害です。
レスポンス分割は、サーバー (通常はアプリケーションサーバー内) の脆弱性を利用します。攻撃者は、リクエストのパラメータ内にエンコードされたデータを送信でき、そのデータは後でデコードされ、レスポンスのレスポンスヘッダーフィールドのいずれかでエコーされます。デコードされたデータがレスポンスが終了し、後続のレスポンスが開始したように見えるように細工されている場合、レスポンスは分割され、見かけ上の第 2 のレスポンス内のコンテンツは攻撃者によって制御されます。攻撃者は、同じ持続的接続で他のリクエストを行い、受信者 (中継装置を含む) をだまして、分割の後半が第 2 のリクエストに対する権威ある回答であると信じさせることができます。
例えば、リクエストターゲット内のパラメータがアプリケーションサーバーによって読み取られ、リダイレクト内で再利用され、同じパラメータがレスポンスの Location ヘッダーフィールドでエコーされる場合があります。パラメータがアプリケーションによってデコードされ、レスポンスフィールドに配置されるときに適切にエンコードされない場合、攻撃者はエンコードされた CRLF オクテットと他のコンテンツを送信でき、アプリケーションの単一のレスポンスを 2 つ以上のレスポンスのように見せることができます。
レスポンス分割に対する一般的な防御は、エンコードされた CR および LF のように見えるデータのリクエストをフィルタリングすることです (例: "%0D" および "%0A")。ただし、これは、アプリケーションサーバーが URI デコードのみを実行し、文字セットトランスコーディング、XML エンティティ翻訳、base64 デコード、sprintf 再フォーマットなどのより不明瞭なデータ変換を実行していないことを前提としています。より効果的な緩和策は、サーバーのコアプロトコルライブラリ以外がヘッダーセクション内で CR または LF を送信することを防ぐことです。つまり、悪いオクテットをフィルタリングする API にヘッダーフィールドの出力を制限し、アプリケーションサーバーがプロトコルストリームに直接書き込むことを許可しないことです。
11.2. リクエストスマグリング (Request Smuggling)
リクエストスマグリング ([Linhart]) は、さまざまな受信者間のプロトコル解析の違いを利用して、見かけ上無害なリクエスト内に追加のリクエスト (そうでなければブロックまたはポリシーによって無効化される可能性があるもの) を隠す手法です。レスポンス分割と同様に、リクエストスマグリングは HTTP 使用に対するさまざまな攻撃につながる可能性があります。
本仕様書は、曖昧なメッセージフレーミングの処理に関して、特に第 6.3 節のメッセージフレーミングに関して、リクエスト解析に新しい要件を導入し、リクエストスマグリングの有効性を低減しました。
11.3. メッセージの完全性 (Message Integrity)
HTTP は、メッセージの完全性を確保するための特定のメカニズムを定義していません。代わりに、基礎となるトランスポートプロトコルのエラー検出能力と、完全性を検出するための長さまたはチャンク区切りフレーミングの使用に依存しています。歴史的に、単一の完全性メカニズムの欠如は、ほとんどの HTTP 通信の非公式な性質によって正当化されてきました。ただし、情報アクセスメカニズムとしての HTTP の普及により、メッセージの完全性の検証が重要な環境での使用が増加しています。
"https" スキームで提供されるメカニズム (認証された暗号化など) は、メッセージの変更に対する保護を提供します。ただし、接続の終了を使用してメッセージを切り捨てることができないようにするには注意が必要です (第 9.8 節を参照)。ユーザーエージェントは、不完全なメッセージの受け入れを拒否するか、特別に処理する場合があります。例えば、医療履歴や薬物相互作用情報を表示するために使用されているブラウザは、そのような情報がプロトコルによって不完全、期限切れ、または転送中に破損していることが検出された場合、ユーザーに通知する必要があります。そのようなメカニズムは、ユーザーエージェント拡張機能またはレスポンス内のメッセージ完全性メタデータの存在を介して選択的に有効にされる場合があります。
"http" スキームは、メッセージの偶発的または悪意のある変更に対する保護を提供しません。
"https" スキームが使用されている場合でも、プロトコルへの拡張を使用して、中継装置による望ましくないメッセージの変更のリスクを軽減する場合があります。完全性は、拡張可能なメタデータフィールドを介してメッセージに選択的に追加されるメッセージ認証コードまたはデジタル署名を使用することで保証される場合があります。
11.4. メッセージの機密性 (Message Confidentiality)
HTTP は、それが望まれる場合、メッセージの機密性を提供するために基礎となるトランスポートプロトコルに依存しています。HTTP は、URI スキームの選択またはユーザーエージェント構成内で識別されるそのようなトランスポートの選択とともに、多くの形式の暗号化接続上で使用できるように、トランスポートプロトコルから独立するように特別に設計されています。
"https" スキームは、[HTTP] の第 4.2.2 節で説明されているように、機密接続を必要とするリソースを識別するために使用できます。