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

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

本節では、HPACKに関するセキュリティ上の懸念の潜在的な領域について説明します:

  • 共有圧縮コンテキストに圧縮される秘密に関する推測を検証するための長さベースのオラクルとしての圧縮の使用。

  • デコーダーの処理またはメモリ容量を使い果たすことから生じるサービス拒否。

7.1. 動的テーブル状態の探索 (Probing Dynamic Table State)​

HPACKは、HTTPのようなプロトコルに固有の冗長性を利用して、ヘッダーフィールドエンコーディングの長さを削減します。これの最終的な目標は、HTTPリクエストまたはレスポンスを送信するために必要なデータ量を削減することです。

ヘッダーフィールドをエンコードするために使用される圧縮コンテキストは、エンコードおよび送信されるヘッダーフィールドを定義でき、エンコードされた後のそれらのフィールドの長さを観察できる攻撃者によって探索される可能性があります。攻撃者が両方を行える場合、動的テーブル状態に関する推測を確認するために、リクエストを適応的に変更できます。推測がより短い長さに圧縮される場合、攻撃者はエンコードされた長さを観察し、推測が正しかったと推測できます。

これは、トランスポート層セキュリティ (TLS) プロトコル ([TLS12]参照) を介しても可能です。TLSはコンテンツに対して機密性保護を提供しますが、そのコンテンツの長さに対しては限られた量の保護しか提供しないためです。

注: パディングスキームは、これらの機能を持つ攻撃者に対して限定的な保護のみを提供し、特定の推測に関連する長さを学習するために必要な推測の数を増やすだけの可能性があります。パディングスキームはまた、送信されるビット数を増やすことによって、圧縮に直接反します。

CRIME [CRIME] のような攻撃は、これらの一般的な攻撃者の機能の存在を実証しました。特定の攻撃は、DEFLATE [DEFLATE] がプレフィックスマッチングに基づいて冗長性を削除するという事実を利用しました。これにより、攻撃者は一度に1文字ずつ推測を確認でき、指数時間攻撃を線形時間攻撃に削減しました。

7.1.1. HPACKとHTTPへの適用性 (Applicability to HPACK and HTTP)​

HPACKは、個々の文字ではなくヘッダーフィールド値全体に推測を一致させることを強制することにより、CRIME [CRIME] をモデルにした攻撃を軽減しますが、完全には防止しません。攻撃者は推測が正しいかどうかのみを学習できるため、ヘッダーフィールド値のブルートフォース推測に還元されます。

したがって、特定のヘッダーフィールド値を回復する実行可能性は、値のエントロピーに依存します。その結果、高いエントロピーを持つ値は正常に回復される可能性は低いです。ただし、低いエントロピーを持つ値は依然として脆弱です。

この性質の攻撃は、相互に信頼できない2つのエンティティが、単一のHTTP/2接続に配置されるリクエストまたはレスポンスを制御する場合に可能です。共有HPACKコンプレッサーが一方のエンティティが動的テーブルにエントリを追加でき、もう一方がそれらのエントリにアクセスできる場合、テーブルの状態を学習できます。

相互に信頼できないエンティティからのリクエストまたはレスポンスを持つことは、中間者が次のいずれかを行う場合に発生します:

  • 複数のクライアントからのリクエストを起点サーバーに向けて単一の接続で送信する、または

  • 複数の起点サーバーからのレスポンスを受け取り、それらをクライアントに向けて共有接続に配置する。

Webブラウザーは、異なるWebオリジン ([ORIGIN]参照) によって同じ接続で行われたリクエストが、相互に信頼できないエンティティによって行われたと仮定する必要もあります。

7.1.2. 軽減策 (Mitigation)​

HPACKのユーザーは、相互に信頼できないエンティティが動的テーブルにエントリを追加し、動的テーブルの状態を観察する能力を制限することにより、動的テーブル探索の可能性を制限する手順を実行できます。

最も効果的な軽減策は、同じオリジンからのアクションの結果ではないリクエストまたはレスポンス間で、接続または圧縮コンテキストの共有を避けることです。

中間者の場合、これは、異なるクライアントからのリクエストと異なる起点サーバーからのレスポンスが、単一のHPACK圧縮コンテキストを共有してはならない (MUST NOT) ことを意味します。

ユーザーエージェントの場合、これは、共通の制御下にあることが知られていない異なるオリジンへのリクエストに対して、圧縮コンテキストを分離しなければならない (MUST) ことを意味します。

7.1.3. 永久にインデックス化されないリテラル (Never-Indexed Literals)​

実装は、機密性の高いヘッダーフィールドを圧縮せず、代わりにその値をリテラルとしてエンコードすることにより、保護することも選択できます。

ヘッダーフィールドのインデックス付き表現の生成を拒否することは、すべてのホップで圧縮が回避される場合にのみ効果的です。永久にインデックス化されないリテラルビット (第6.2.3節参照) を使用して、特定の値が意図的にリテラルとして送信されたことを中間者に通知できます。

中間者は、永久にインデックス化されないリテラル表現を使用するヘッダーフィールドを、それをインデックス化する別の表現で再エンコードしてはなりません (MUST NOT)。HPACKが再エンコードに使用される場合、代わりにインデックスなしのリテラル表現 (第6.2.2節参照) を使用できます。

ヘッダーフィールドに永久にインデックス化されないリテラル表現を使用するかどうかの選択は、いくつかの要因に依存します。HPACKはヘッダーフィールド値全体の推測から保護しないため、短いまたは低エントロピーの値は、敵対者によってより容易に回復されます。したがって、エンコーダーは、低いエントロピーを持つ値をインデックス化しないことを選択する場合があります。

エンコーダーはまた、CookieまたはAuthorizationヘッダーフィールドなど、回復に対して非常に価値があると考えられる、または機密性が高いと考えられるヘッダーフィールドの値をインデックス化しないことを選択する場合があります。

7.2. 静的ハフマン符号化 (Static Huffman Encoding)​

静的ハフマン符号化に対する現在知られている攻撃はありません。ある研究では、静的ハフマン符号化テーブルを使用することが情報漏洩を作成することが示されましたが、この同じ研究は、攻撃者がこの情報漏洩を利用して有意な量の情報を回復できないと結論付けました ([PETAL]参照)。

7.3. メモリ消費 (Memory Consumption)​

攻撃者は、エンドポイントにメモリを使い果たさせようとする可能性があります。HPACKは、エンドポイントによって割り当てられるメモリのピークと安定した量の両方を制限するように設計されています。

圧縮コンテキストによって使用されるメモリ量は、動的テーブルの最大サイズを設定することで制限できます。HTTP/2では、これはSETTINGS_HEADER_TABLE_SIZE設定によって制御されます ([HTTP2]の第6.5.2節参照)。

エンコーダーは、動的テーブルサイズを制御することにより、デコーダーで作成できる状態の量を制限できます。HTTP/2では、これはSETTINGS_HEADER_TABLE_SIZE設定の使用を通じてデコーダーによって報告されます。エンコーダーは、動的テーブルサイズをデコーダーによって報告された値に制限しなければならず (MUST)、それによって確約されるメモリ量を制御します。

デコーダーは、デフォルト値よりも低いSETTINGS_HEADER_TABLE_SIZE値を通知することにより、動的テーブルに確約されるメモリ量を制限できます。HTTP/2では、デフォルト値は4,096オクテットです。これは、デコーダーがSETTINGSフレームでSETTINGS_HEADER_TABLE_SIZE設定を送信してこれを変更しない限り、エンコーダーが動的テーブルにこの量までのメモリを使用できることを意味します。

7.4. 実装の制限 (Implementation Limits)​

実装は、整数および文字列リテラルのサイズに対して受け入れる値の制限を設定する必要があります。同様に、動的テーブルに格納するエントリの数に制限を設定する必要があります。制限を設定しないと、実装が攻撃にさらされる可能性があります。これは、合理的な制限を設定しなかったプロトコル実装で観察されたものと同様です。

に最終更新