HTTPリクエストスマグリング

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

このタイプでは、フロントエンドがTransfer-Encodingヘッダを使用してリクエストを処理し、バックエンドがContent-Lengthヘッダを使用して処理する^[2]。この攻撃では、攻撃者は悪意のあるリクエストを含む最初のチャンクの有効な長さを宣言し、その後に長さ0の第2のチャンクを宣言する^[5]。フロントエンドサーバは長さ0の第2のチャンクを見ると、リクエストが完了したと判断してバックエンドサーバに転送する^[5]。しかし、バックエンドサーバはContent-Lengthヘッダを使用して処理するため、最初のチャンクに残された悪意のあるリクエストは、次の一連のリクエストの開始点として扱われるまで未処理のまま残り、その後に実行される^[2]。

このタイプでは、フロントエンドとバックエンドの両方がTransfer-Encodingヘッダを使用してリクエストを処理するが、一報のサーバのみがヘッダを無視するように、非標準の空白形式や重複ヘッダなどを用いてヘッダを難読化する^[2]。難読化の手法としては、「Transfer-Encoding: xchunked」のように不正な文字を追加したり、「Transfer-Encoding」と「: chunked」の間に異常な改行文字を入れたりする形がある^[5]。フロントエンドまたはバックエンドのいずれかのサーバが依然としてこれらの難読化されたリクエストを処理する場合、攻撃の残りの部分はCL.TEまたはTE.CL攻撃と同様の仕組みとなる^[5]。

最も確実な対策は、フロントエンドとバックエンドのサーバがHTTPリクエストを全く同じ方法で解釈することである。しかし、ロードバランサは異なるソフトウェアやプラットフォームで動作するバックエンドサーバをサポートしているため、これは通常、選択肢にはならない^[5]。この攻撃のほとんどの変種は、リクエストの長さを決定するために異なる手法を用いるHTTP/2を使用することで防ぐことができる。別の回避策としては、フロントエンドサーバがバックエンドに渡す前にHTTPリクエストを正規化し、確実に同じ解釈がなされるようにすることである^[2]。Webアプリケーションファイアウォール（WAF）の設定も有効であり、多くのWAFは攻撃の試みを特定し、疑わしいリクエストをブロックまたはサニタイズする技術を備えている^[5]。

Grenfeldtら（2021年）の研究によれば、ほとんどのフロントエンドWebサーバ（プロキシサーバなど）は、バックエンドサーバに対する既知のHRS攻撃を実際に阻止するためのパース機能を提供していることがわかった^[6]。Huangら（2022年）は、Flaskを使用して適切なパース機能を実装し、フロントエンドプログラムやWebサーバからのHRS攻撃を防ぐ手法を提案した^[7]。