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

10.1. サーバー権限

HTTP/2は、サーバーが特定のレスポンスを提供する権限があるかどうかを判断するために、HTTP/1.1の権限の定義に依存しています([HTTP]のセクション17.1を参照)。これは、"https"スキームのローカル名前解決と、"https"スキームの認証されたサーバーIDに依存しています([HTTP]のセクション4.2.2で定義)。権限を確立するために使用される代替サービス([ALT-SVC])は、かなりの追加の複雑さを導入する可能性があります。

10.2. クロスプロトコル攻撃

TLSでは、HTTP/2はApplication-Layer Protocol Negotiation (ALPN)拡張[TLS-ALPN]を使用してプロトコルの使用を交渉します。これにより、サーバーがHTTP/2をサポートしているという肯定的な信号が作成され、HTTP/2のクロスプロトコル攻撃への露出が減少します。

ただし、平文の場合、またはTLSでALPNが使用されていない場合、HTTP/2クライアント接続プリアンブル(セクション3.4)は他のプロトコルと混同される可能性があります。HTTP/2接続プリアンブルは、他のプロトコルの有効な開始となる可能性が低いシーケンスを選択することで、この可能性を最小限に抑えるように設計されています。

HTTP/2エンドポイントにアクセス可能な任意のプロトコルを使用して、有効なHTTP/2接続であるかのように見えるものを確立できます。このため、サーバー側エンドポイントが受信した接続プリアンブルは、プロトコルがクロスプロトコル攻撃を形成するために有効である必要があります。

クライアント接続プリアンブル(セクション3.4)は、プロトコルが混同されないことを保証するのに十分ではありませんが、ある程度の保護を提供します。HTTP/2クライアント実装は、HTTPセマンティクスを適用する前に追加のチェックを実行する必要がある場合もあります。特に、クライアントは初期応答がクライアントが送信したメッセージに対する正当な応答であることを確認する必要があります。

サーバーは、クライアントが別のサーバーに送信したかったターゲットサーバーにリクエストを送信することで、クライアントを攻撃する可能性があります。受信サーバーがHTTP/2以外のHTTPスキームをサポートしている場合、サーバーは別のサーバーに送信されたリクエストを読み取ってエコーすることができます。攻撃者は、クライアントが受信する応答を傍受および変更し、クライアントが応答内の情報を、それが属していないリクエストへの応答と関連付けるようにすることができます。

10.3. 中間者カプセル化攻撃

HTTP/2フィールドエンコーディングは、HTTP/1.1で有効なフィールド名と値ではない、またはHTTP/1.1で表現できないフィールド名と値の表現を可能にします。無効なフィールド名または値を含むリクエストまたはレスポンスは、フィールド名と値に対して不十分な検証を実行する実装を脆弱にします。攻撃者は、無効なメッセージが有効に見えるように、中間者を使用してリクエストまたはレスポンスをカプセル化できる可能性があります。

リクエストとレスポンスを完全に検証しないHTTP/2からHTTP/1.1へのトランスレータは、悪意のあるクライアントがフィールド値を密輸したり、誤解を招くフィールド名を持つフィールドを作成したりすることを許可する可能性があります。

10.4. プッシュされたレスポンスのキャッシュ可能性

プッシュされたレスポンスには、クライアントからの明示的なリクエストがありません。リクエストはPUSH_PROMISEフレーム内でサーバーによって提供されます。

プッシュされたレスポンスをキャッシュすることは問題がある可能性があります。接続を確立するために使用される情報に応じて、プッシュされたレスポンスは、接続を共有しているが意図せずリソースをリクエストした新しいクライアントに誤って利用可能になる可能性があります。

たとえば、認証にTLSを使用する場合、悪意のあるクライアントは、同じ接続を使用している認証されたユーザーの機密情報に関するプッシュされたレスポンスを受信する可能性があります。

サーバーは、プッシュされるリクエスト内でキャッシュ可能な値のみを含める必要があります([HTTP]のセクション9.2.3を参照)。プッシュされたリクエストにはリクエストコンテンツの値は含まれません。プッシュされたレスポンスは、no-cacheまたはprivateキャッシュレスポンスディレクティブを含むCache-Controlヘッダーフィールドを含めることで、キャッシュ不可としてマークされます([HTTP-CACHING]のセクション5.2.2.4を参照)。

同じプッシュされたレスポンスが、キャッシュ可能なレスポンスとキャッシュ不可能なレスポンスの両方に提供できる場合、クライアントはキャッシュ可能なレスポンスを使用してプッシュされたレスポンスを誤ってキャッシュする可能性があります。

したがって、サーバーは、クライアントがレスポンスをキャッシュしていることを示す明示的な信号がない限り、プッシュされたストリームのHEADERSフレームに"no-cache"の値を持つCache-Controlヘッダーフィールドを含めるべきです(SHOULD)。

10.5. サービス拒否に関する考慮事項

HTTP/2の使用は、いくつかの新しいサービス拒否(DoS)の機会を導入します。

10.5.1. フィールドセクションサイズの制限

多数のフィールドまたは長いフィールド名または値を含むフィールドセクションは、実装が過度の量のメモリ、CPU時間、またはその両方を消費する原因となる可能性があります。

実装は、受け入れるフィールド行の総数とサイズ、および送信する総数とサイズに制限を課すべきです(SHOULD)。これにより、フィールドセクションを構成するフレームの総サイズが制限されます。サーバーはフィールド行のホワイトリストを維持したい場合があり、クライアントはフィールド行を拒否したい場合がありますが、両方とも相互運用性を妨げる可能性のある制限をログに記録し、考慮すべきです(SHOULD)。

10.5.2. CONNECTの問題

CONNECTメソッドは、信頼できない宛先への接続を作成するために使用できます。CONNECTのTCP接続は制御の対象ではなく、エンドポイントや他のデバイスへの接続を試みて、接続の洪水を作成する可能性があります。実装は、CONNECTターゲットとして許可される宛先に制限を設定すべきであり(SHOULD)、これらの制限をログに記録すべきです(SHOULD)。

10.5.3. 圧縮の使用

HTTP/2でのフィールドブロックの圧縮は、攻撃者がサービス拒否を引き起こすために使用できるアルゴリズムと状態に依存しています。

攻撃者は、大量のデコーダーリソースを必要とするフィールドセクションを作成するために、慎重に作成されたフィールドを含むリクエストを送信できます。これは、大量のハフマン符号化された文字列を使用するか、動的テーブルへの多くの更新を行うことで実行できます。1つを終了した直後に新しいフィールドセクションを開始すること(例えば、空のDATAフレームの後にHEADERSフレームが続く)も、利用可能なデコーダーリソースを制限するために使用できます。

同様の攻撃を送信して、フィールドセクション圧縮状態を積極的に使用し、大量のエンコーダーリソースを必要とするレスポンスを作成することもできます。

実装は、解凍するフィールドのサイズに制限を設定すべきです(SHOULD)。

10.5.4. フロー制御の使用

HTTP/2のフロー制御により、敵対者はピアが送信できるデータ量を制限できます。ウィンドウ更新またはフロー制御ウィンドウ管理の実装により、ストリームが利用可能なウィンドウを取得できなくなり、ストリームが進行できなくなる可能性があります。

10.5.5. 設定の使用

SETTINGSフレームは、ピアが追加の処理時間を費やすように使用できます。これは、意味のない設定の変更、設定を変更せずにSETTINGSフレームを送信すること、または頻繁に設定を変更することで行うことができます。

値を制限する他のSETTINGSパラメーターは、SETTINGS_HEADER_TABLE_SIZEパラメーターに非常に小さい値を設定してHPACK動的テーブルを無効にするなど、リソースを消費するために使用される可能性があります。

エンドポイントは、これらの動作を検出し、ENHANCE_YOUR_CALMタイプの接続エラー(セクション5.4.1)として扱うべきです(SHOULD)。

10.5.6. 優先度の使用

優先度は、ピアが過度のリソースを費やすようにするために使用される可能性があります。優先度ツリーへの頻繁な変更または優先度ツリーの不当な複雑さは、どちらも過度のCPU消費をもたらす可能性があります。

10.5.7. TLSなしでのHTTP/2の使用

HTTP/2は、TLSを使用せずに展開できます。このモードは、HTTP/1.1と同様に特定の攻撃に対して同じ脆弱性を持っています。この動作モードを使用する実装は、HTTP/1.1に適用可能な保護を適用すべきです(SHOULD)。

実装はまた、多くのHTTP/2機能がTLSなしでは攻撃に対してより脆弱である可能性があることを認識する必要があります。特に、TLSによって提供される機密性保護と整合性保護がないことは、データの暗号化または整合性が危険にさらされることを意味します。

10.6. 圧縮の使用

圧縮により、攻撃者が制御するデータと、攻撃者が送信サイズを観察できる秘密データと組み合わされた場合、攻撃者が暗号化された通信の秘密コンテンツを回復することができる可能性があります。

HTTP/2は複数の場所で圧縮を提供します。フィールドブロックはHPACK[COMPRESSION]を使用し、DATAフレームのコンテンツはコンテンツコーディングを使用できます([HTTP]のセクション8.4.1を参照)。

HPACKは、秘密の開示の悪用をより困難にするように設計されています。ただし、実装の選択またはアプリケーション保護の間のトレードオフは、いくつかの場合に実現できるものの、不完全です。攻撃は、複数のリクエストにわたるフィールド圧縮状態の再利用を悪用できます。実装とアプリケーションは、保護を改善するために、リクエスト間で使用される圧縮状態の量を制限することを選択できますが、メッセージサイズの増加を犠牲にします。

DATAフレームのコンテンツの圧縮は、DATAフレームのコンテンツが複数のリクエストにわたって攻撃者が制御するデータと混合される可能性が低いため、一般的により安全と考えられています。ただし、圧縮コンテンツコーディングは、異なるオリジンからの情報を結合します。異なるオリジン識別子を使用することで、異なるソースからの情報を区別しますが([HTTP]のセクション11.5を参照)、圧縮はこれらのセパレータを削除できます([BREACH]で説明されているように)。

コンテンツコーディングの圧縮を無効化または制限することは、一般的にこれらの攻撃を軽減するのに十分と考えられていますが、すべての攻撃を防ぐには不十分である可能性があります。

10.7. パディングの使用

パディングは、フレームおよびメッセージコンテンツの正確なサイズを不明瞭にするために使用できます。パディングは、トラフィック分析を使用してメッセージに関する情報を推測することに依存する攻撃を軽減するために使用できます。これは、圧縮されたメッセージの長さがそれらが含むコンテンツに関する情報を明らかにする可能性があるHTTPにとって特に重要です。

パディングの使用例は、メッセージの正確なサイズを不明瞭にするために、フレーム間で変化するペイロードサイズを持つ多数のHEADERSおよびDATAフレームを送信することです。パディングの使用は、いくつかの攻撃を減らすことができます(例えば、[BREACH])。

一般的に、トラフィック分析攻撃の存在は、すべてのフィールドまたはフレームに対して固定サイズへのパディングが保護を提供するのに不十分であることを意味します。効率的であり、ある程度の保護を提供するために、パディングはランダムに選択されるべきです(SHOULD)。

パディングは、メッセージサイズを不明瞭にするための完璧な保護ではありません。攻撃者は、メッセージのサイズに関する統計的特性を使用できる可能性があり、これにより、攻撃者は、パディングされているかどうかにかかわらず、メッセージの長さを使用して、ある程度の確率でコンテンツに関する情報を推測できる可能性があります。

10.8. プライバシーに関する考慮事項

HTTP/2のいくつかの特性により、観察者が一連のリクエストを相関させる機会が提供されます。これには、設定の値、フィールドブロックの圧縮コンテキスト、フロー制御ウィンドウの管理、および到着するメッセージのタイミングが含まれます。

特に、ユーザーIDに関する情報を含むHTTPフィールドは、異なるサーバーを使用している場合でも、他の通信と相関させることができます。

HTTP/2は、ユーザーのプライバシーを保護するための特定のメカニズムを提供しません。

---

第10章完了!

参考文献

• [HTTP] RFC 9110
• [HTTP-CACHING] RFC 9111
• [TLS-ALPN] RFC 7301
• [ALT-SVC] RFC 7838
• [COMPRESSION] RFC 7541
• [BREACH] "BREACH: Reviving the CRIME Attack"