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

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

10.1. Server Authority (サーバーの権威性)​

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

10.2. Cross-Protocol Attacks (クロスプロトコル攻撃)​

TLSでは、HTTP/2はアプリケーション層プロトコルネゴシエーション（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. Intermediary Encapsulation Attacks (中間体カプセル化攻撃)​

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

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

10.4. Cacheability of Pushed Responses (プッシュされたレスポンスのキャッシュ可能性)​

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

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

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

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

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

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

10.5. Denial-of-Service Considerations (サービス拒否に関する考慮事項)​

HTTP/2の使用は、いくつかの新しいサービス拒否（DoS）の機会をもたらします。

10.5.1. Limits on Field Section Size (フィールドセクションサイズの制限)​

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

実装は、受け入れるフィールド行の総数とサイズ、および送信する総数とサイズに制限を課すべきであり（SHOULD）、それによってフィールドセクションを構成するフレームの総サイズを制限します。サーバーはフィールド行のホワイトリストを維持することを望むかもしれませんし、クライアントはフィールド行を拒否することを望むかもしれませんが、両者とも相互運用性を妨げる可能性のある制限を記録し、考慮すべきです（SHOULD）。

10.5.2. CONNECT Issues (CONNECT問題)​

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

10.5.3. Use of Compression (圧縮の使用)​

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

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

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

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

10.5.4. Use of Flow Control (フロー制御の使用)​

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

10.5.5. Use of Settings (設定の使用)​

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

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

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

10.5.6. Use of Priorities (優先度の使用)​

優先度は、ピアに過剰なリソースを消費させるために使用される可能性があります。優先度ツリーの頻繁な変更または不合理な複雑さの両方が、過剰なCPU消費をもたらす可能性があります。

10.5.7. Use of HTTP/2 Without TLS (TLSなしのHTTP/2の使用)​

HTTP/2は、TLSを使用せずにデプロイできます。このモードは、HTTP/1.1と同じ特定の攻撃に対する脆弱性を持っています。この操作モードを使用する実装は、HTTP/1.1に適用可能な保護を適用すべきです（SHOULD）。

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

10.6. Use of Compression (圧縮の使用)​

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

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

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

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

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

10.7. Use of Padding (パディングの使用)​

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

パディングを使用する例の1つは、メッセージの正確なサイズを隠すために、フレーム間でペイロードサイズが変化する多数のHEADERSおよびDATAフレームを送信することです。パディングを使用すると、一部の攻撃（例えば[BREACH]）を軽減できます。

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

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

10.8. Privacy Considerations (プライバシーに関する考慮事項)​

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

特に、ユーザーアイデンティティに関する情報を含むHTTPフィールドは、異なるサーバーを使用している場合でも、他の通信と相関する可能性があります。

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

第10章完了！

References​

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