HTTP リクエストの密輸

HTTPリクエストスマグリング（HRS）は、HTTPプロキシサーバーチェーン内のHTTPサーバー実装間のヘッダーの解釈の不一致を利用するHTTPプロトコルのセキュリティエクスプロイトです。^{[1] [2]}これは2005年にLinhartらによって初めて文書化されました。^[3]Content-LengthTransfer-Encoding

Transfer-Encoding ヘッダーは、 HTTP リクエストの本文を解釈する方法に関する指示を定義することで機能します。この攻撃に共通かつ必要な指示は、チャンク転送エンコーディングです。^[4] Transfer-Encoding ヘッダーが存在する場合、Content-Length ヘッダーは省略されるはずです。^[4]同様に機能しますが構文が異なり、Content-Length ヘッダーは、ヘッダー自体の値として本文のサイズをバイト単位で指定します。^{[5]これらのヘッダーの両方が悪意のある HTTP リクエストに含まれていると、}フロントエンド サーバーまたはバックエンド サーバーのいずれかがリクエストを誤って解釈することで、サーバーへの悪意のある HTTP クエリを防ぐためのセキュリティ機能がバイパスされ、脆弱性が発生します。 ^[6] HTTP リクエストのスマグリングは、一般的に CL.TE、TE.CL、または TE.TE の形をとりますが、HRS を使用したより複雑な攻撃も存在します。^[6]

このタイプの HTTP リクエスト スマグリングでは、フロントエンドは Content-Length ヘッダーを使用してリクエストを処理し、バックエンドは Transfer-Encoding ヘッダーを使用してリクエストを処理します。^[2]攻撃は、リクエストの最初の部分で長さがゼロのチャンクを宣言して実行されます。^[6]これを見たフロントエンド サーバーは、リクエストの最初の部分のみを読み取り、意図せずに 2 番目の部分をバックエンド サーバーに渡します。^[6]バックエンド サーバーに渡されると、次のリクエストとして扱われて処理され、攻撃者の隠されたリクエストが実行されます。^[6]

このタイプの HTTP リクエスト スマグリングでは、フロントエンドは Transfer-Encoding ヘッダーを使用してリクエストを処理し、バックエンドは Content-Length ヘッダーを使用してリクエストを処理します。^[2]この攻撃では、ハッカーは悪意のあるリクエストを格納する最初のチャンクの有効な長さを宣言し、次に長さが 0 の 2 番目のチャンクを宣言します。^[6]フロントエンド サーバーは、長さが 0 の 2 番目のチャンクを確認すると、リクエストが完了したと判断し、バックエンド サーバーに渡します。^[6]ただし、バックエンド サーバーは Content-Length ヘッダーを使用してリクエストを処理するため、最初のチャンクに残っている悪意のあるリクエストは、シーケンス内の次のリクエストの先頭として扱われて実行されるまで処理されません。^[2]

このタイプの HTTP リクエスト密輸では、フロントエンドとバックエンドの両方が Transfer-Encoding ヘッダーを使用してリクエストを処理しますが、ヘッダーは、サーバーのうちの 1 つがそれを無視し、もう 1 つのサーバーがそれを無視しないような方法で難読化できます (たとえば、非標準の空白のフォーマットや重複したヘッダーなど)。^[2]ヘッダーの難読化は、Transfer-Encoding: xchunked などの誤った文字を追加したり、'Transfer-Encoding' と ': chunked' の間に通常とは異なる改行文字を追加したりする形を取る場合があります。^[6]フロントエンドまたはバックエンド サーバーの 1 つがこれらの難読化された HTTP リクエストを引き続き処理する場合、攻撃の残りの部分は CL.TE または TE.CL 攻撃の仕組みと同様になります。^[6]

これらの攻撃に対する最善の予防策は、フロントエンド サーバーとバックエンド サーバーが HTTP リクエストを同じように解釈することです。ただし、ロード バランサーは異なるソフトウェアを使用して異なるプラットフォームで実行されるバックエンド サーバーをサポートするため、通常はこのオプションは使用できません。^[6]この攻撃のほとんどの亜種^{[指定]は、リクエストの長さを決定するために異なる方法を使用する}HTTP/2を使用することで防止できます。攻撃を回避するもう 1 つの方法は、フロントエンド サーバーが HTTP リクエストをバックエンドに渡す前に正規化し、同じ方法で解釈されるようにすることです。^[2] Web アプリケーション ファイアウォールを構成することも、HRS 攻撃を防ぐ優れた方法です。多くのファイアウォールには、攻撃の試みを識別し、疑わしい受信リクエストをブロックまたはサニタイズするテクノロジが搭載されているためです。^[6]

Grenfeldtら（2021）は、ほとんどのフロントエンドWebサーバー（プロキシサーバーなど）が、バックエンドWebサーバーに対するすべての既知のHRS攻撃を実際に阻止するための解析機能を提供していることを発見しました。^[7] Huangら（2022）は、フロントエンドプログラムまたはWebサーバーからのHRS攻撃を防ぐ適切な解析機能を実装するためにFlaskを使用する方法を提案しました。 ^[8]