HTTP リクエスト・スマグリングとは？

HTTPリクエストスマグリングは、複数のデバイス間でのHTTPリクエスト解析の不整合から生じる脆弱性です。これらの脆弱性は、異なる HTTP ヘッダー（つまり、Transfer-Encoding、Content-Length）の存在により、フロントエンド・デバイス（例：CDN、ロードバランサー、WAF）とバックエンド・デバイス（例：Web サーバー）が HTTP リクエストの終端を異なって解釈する場合に発生します。これにより、セキュリティ・コントロールのバイパス、他のユーザーに対する攻撃（例：XSS）の実行、キャッシュ・ポイズニング、サービス拒否攻撃、またはアプリケーションに応じたその他の攻撃につながる可能性があります。HTTPリクエスト・スマグリングは、CWE-444、HTTPレスポンス・スマグリング、またはHTTPスマグリングとも呼ばれることがあります。

HTTPリクエスト・スマグリングの脆弱性には、プロトコルのバージョン、ヘッダーの順序、環境に応じて多くの種類があります。以下のセクションでは、これらをそれぞれ詳しく説明します。

説明内容：

HTTP リクエストスマグリングにはどのような種類がありますか？
HTTP/1.1 リクエスト・スマグリング
HTTP/2リクエスト・スマグリング
HTTP リクエストスマグリングの影響
FastlyがHTTPリクエスト・スマグリングを防ぐ方法
HTTPリクエストスマグリングを防ぐ方法
概要

HTTP リクエストスマグリングにはどのような種類がありますか？

HTTP/1.1 リクエスト・スマグリング

HTTP/1.1 を使用するリクエストでは、Content-Length または Transfer-Encoding ヘッダーのいずれかを使用して、リクエストの終了を指定できます。フロントエンド・デバイスとバックエンド・デバイスが、リクエストの終了を判断するためにこれら 2 つのヘッダーのうち同じものを使用しない場合、リクエストの終了を異なる方法で解析する可能性があり、その結果、HTTP リクエスト・スマグリングの脆弱性につながるおそれがあります。

以下の例では、認可のバイパスを通じたリクエストスマグリングの影響を示します。このシナリオでは、フロントエンドサーバーが /admin ページへのアクセスを防止していますが、バックエンドでは追加の検証が行われていません。バックエンドでも検証が行われないため、リクエストスマグリングによってこの認可チェックをバイパスできる可能性があります。

CL.TE 脆弱性

CL.TE の脆弱性とは、フロントエンドが Content-Length ヘッダーを使用し、バックエンドが Transfer-Encoding ヘッダーを使用する HTTP リクエスト・スマグリング攻撃を指します。

次の例では、フロントエンドがContent-Lengthヘッダーを使用し、内容全体を単一のリクエストとして読み取り、バックエンドに転送します。ただし、バックエンド・サーバーはTransfer-Encodingヘッダーを使用し、0\r\n\r\n でリクエストの終了を解釈します（これは、Transfer-Encodingがリクエストの終了を示すために使用する、0チャンクの後の2つの改行です）。そのため、バックエンドはこれを2つのリクエストとして解釈します。

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 46
Transfer-Encoding: chunked

1
q=smuggling

0

GET /admin HTTP/1.1
Example: x

ここで、さらに多くのデータが接続を通じて送られてくると（例：リクエストを再度送信する場合）、バックエンド・サーバーは、この密かに送り込まれた2番目のリクエストが終了していなかったため、その先頭にそのデータを追加します。これにより、バックエンド・サーバーには次の内容が2番目のリクエストとして認識されます：

GET /admin HTTP/1.1
Example: xPOST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

Content-Length: 46
Transfer-Encoding: chunked

1
q=smuggling

バックエンドサーバーはこれを /admin に対する GET リクエストとして解釈します。これはフロントエンドサーバーをすり抜けて密輸されたものであり、フロントエンドサーバーは 2 つの POST リクエストしか解釈しませんでした。このリクエストスマグリングの脆弱性により、攻撃者はフロントエンドによる認可チェックを回避できるようになりました。

TE.CLの脆弱性

TE.CLの脆弱性とは、フロントエンドが Transfer-Encoding ヘッダーを使用し、バックエンドが Content-Length ヘッダーを使用するHTTPリクエスト・スマグリング攻撃を指します。

次の例では、フロントエンドは Transfer-Encoding ヘッダーを使用し、内容全体を 1 つのリクエストとして読み取り、それをバックエンドに転送します。バックエンドは Content-Length ヘッダーを使用するため、これを 2 つのリクエストとして解釈します。

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

k0
GET /admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 150

x
0

フロントエンド・サーバーは1つのリクエストを完了していますが、バックエンド・サーバーは、密輸されたリクエスト内の長い Content-Length による追加のコンテンツをまだ待機しています。さらに多くのデータが接続を通じて送られてくると（たとえば、リクエストを再度送信した場合）、バックエンド・サーバーは、それが終了していなかったため、この密輸された2番目のリクエストの先頭にそのデータを追加します。これにより、バックエンド・サーバーは次の内容を2番目のリクエストとして認識します。

GET /admin HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 141

x
0

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
Transfer-Encoding: chunked

k0

ヘッダーの難読化とスマグリング

一部のデバイスは、不正な形式の Transfer-Encoding ヘッダーを無視する可能性がありますが、他のデバイスは、わずかな誤り（例：余分なスペース、重複したヘッダーなど）があってもそれらを処理する場合があります。この場合、一方のデバイスが不正な形式のヘッダーを処理し、もう一方がそれを無視するため、前述の CL.TE または TE.CL の脆弱性のいずれかを悪用しやすくなる可能性があります。

HTTP/2リクエスト・スマグリング

従来のHTTPリクエストスマグリングはHTTP/2によって軽減されるべきですが、特にバックエンドサーバーがHTTP/1.1のみをサポートしている場合は、HTTP/2を使用してリクエストをスマグリングする方法が依然として存在します。

HTTP/2はフレームで送信されるバイナリプロトコルであり、各フレームの前にはフレームの長さが付きます。Content-Length ヘッダーは必須ではなく、Transfer-Encoding ヘッダーはサポートされていません。読みやすさのため、これらのリクエストはHTTP/1.1での表示形式で示しますが、実際に送信されるデータはHTTP/2では異なることにご注意ください。

HTTP/2 ダウングレード

バックエンド・デバイス（例：Web サーバー）がHTTP/1.1のみをサポートしていて、フロントエンド・デバイス（例：CDN）とクライアントがHTTP/2を使用している場合、フロントエンド・デバイスは受信したHTTP/2リクエストをHTTP/1.1に書き換えてからバックエンドに送信します。これはHTTP/2ダウングレードと呼ばれ、この書き換えにおけるエラーを悪用することで、リクエスト・スマグリングの脆弱性が発生します。

H2.CL の脆弱性

HTTP/2 では Content-Length ヘッダーは必須ではなく、これが提供される場合は、メッセージの計算された長さに対して検証されることになっています。デバイスがリクエストを HTTP/1.1 に書き換える場合、変換後の Content-Length ヘッダーには計算した長さを使用する必要があります。ただし、一部のフロントエンド・デバイスでは、ダウングレードの実行時に、代わりに提供された Content-Length ヘッダーを使用する場合があります。これが発生すると、バックエンドはフロントエンドとは異なる Content-Length を使用することになり、その結果、リクエスト・スマグリングの脆弱性が生じます。

H2.TE の脆弱性

Transfer-Encoding ヘッダーは HTTP/2 では使用されないため、ヘッダーを削除するか、Transfer-Encoding ヘッダーを含む HTTP/2 リクエストを拒否することをお勧めします。フロントエンドデバイスがこれを行わず、その後 Transfer-Encoding ヘッダーを付けてリクエストを書き換えると、そのヘッダーをバックエンドに密輸できる可能性があります。これを悪用するには、バックエンドが Transfer-Encoding を Content-Length より優先してサポートしている必要がありますが、その場合は CL.TE HTTP/1.1 の悪用と同じになります。

HTTP リクエストスマグリングの影響

HTTP request smuggling は、複数のリクエストの境界を妨げるため、アプリケーションによっては広範な影響を及ぼします。先ほどの例では認可バイパスを取り上げましたが、他のユーザーに影響を与える追加の例も取り上げます。さらに、Portswigger のチームが詳細に説明しているさらに多くの例もあります。Portswigger は HTTP リクエスト smuggling に関する広範な調査を行っています。

実例：反射型 XSS を悪用する

この例では、フロントエンドサーバーが Content-Length に基づいてリクエストの長さを判断し、バックエンドサーバーが Transfer-Encoding に基づいてそれを判断すると仮定します。また、ペイロードが Referrer ヘッダー内にある場合、Web サーバーは反射型クロスサイトスクリプティング（XSS）に対して脆弱であると仮定します。通常、Referer ヘッダー内の反射型 XSS は、クエリパラメータの場合のようにリンクだけでは悪用できないため、悪用するのが困難です。このシナリオでは、攻撃者は次のリクエストを送信します。

POST /smuggled HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 111
Transfer-Encoding: chunked

1
q=smuggling
0

GET /vulnerable-page HTTP/1.1
Referrer: ”><script>print(1)</script>
Example: x

フロントエンドは Content-Length ヘッダーを使用し、これを単一のリクエストとして解釈して、バックエンドに転送します。バックエンドは Transfer-Encoding を使用し、これを 2 つのリクエストとして解釈します。最初のリクエストは赤で強調表示され、2 番目のリクエストは青で強調表示されます。2 番目のリクエストは不完全であるため、バックエンドはさらにデータが送信されるのを待ちます。この後に別のユーザーが /home へのリクエストを送信すると、Web サーバーのレスポンスは攻撃者が密輸したリクエストからのものとなり、その結果、被害ユーザーへのレスポンスで反射型 XSS ペイロードが配信されます。このシナリオでは、バックエンドは被害ユーザーのリクエストを次のように解釈します。

GET /vulnerable-page HTTP/1.1
Referrer: "><script>print(1)</script>
Example: xGET /home HTTP/1.1
Host: example.com
...rest of victim user's request...

被害を受けたユーザーは /home にリクエストを送信しましたが、代わりに反射型 XSS ペイロードを含む /vulnerable-page へのレスポンスを受信しました。実際には、リクエスト量、接続の再利用などにより、ユーザーがキューに入れられた XSS レスポンスを受信するようにするには多くのリクエストが必要になりますが、XSS ペイロードで接続を汚染するための smuggling リクエストを急速に送信することで、広範囲のユーザーにすぐに影響を及ぼす可能性があります。

FastlyがHTTPリクエスト・スマグリングを防ぐ方法

Fastly は、リクエストを厳格かつ標準準拠で解析することにより、HTTP request smuggling を防止します。これは、いくつかの方法で実現されます：

厳格なプロトコル解析：Fastly は、標準に準拠して、すべての HTTP リクエストを高い厳格性で解析します。これにより、攻撃者がリクエストスマグリングの脆弱性を悪用するために利用する曖昧さが排除されます。
リクエストの正規化：Fastlyは、エッジであいまいなリクエストを拒否するか正規化します。たとえば、Content-Length ヘッダーと Transfer-Encoding ヘッダーの両方を含むリクエストは、悪用可能な状態でオリジンに到達しないように処理されます。
無効なリクエストの拒否：Fastlyは、ボディを含むGETリクエストとHEADリクエストを拒否します。この場合、Fastlyは400 Bad Requestレスポンスを返し、リクエストがオリジンに到達するのを防ぎます。そのように設定されている場合、pass リクエストは、GET および HEAD リクエストのボディをオリジンに送信します。これらのリクエストでボディを有効にする特別な必要がある場合は、サポートチームにお問い合わせいただく必要があります。

HTTPリクエストスマグリングを防ぐ方法

あいまいなリクエストを正規化する
- CL ヘッダーと TE ヘッダーの両方を受信するフロントエンドサーバーは、リクエストの長さを判断する仕組みを 1 つに正規化し、オリジンサーバーが曖昧なリクエストを受信しないように余分なヘッダーを削除する必要があります。
不正な形式のリクエスト（HTTP/2 と HTTP/1.1 の両方）を拒否します
- 不正な形式のヘッダーや重複ヘッダーなどを含むリクエストを拒否すると、サーバーが不正な形式のヘッダーを受け入れることに依存する脆弱性の防止に役立ちます。また、不要な追加ヘッダーがバックエンドに転送されることに依存する HTTP/2 ダウングレード CL および TE の脆弱性も防止できます。
HTTP/1.1ダウングレードで検証する
- HTTP/1.1 にダウングレードするフロントエンドサーバーは、書き換えられたリクエストが不正な形式または曖昧でないことを検証する必要があります。たとえば、書き換え後、フロントエンドサーバーは通常の HTTP/1.1 リクエストに対して行うのと同じ正規化を実行する必要があります。
バックエンド接続の再利用を無効にすることを検討してください。
- 多くのリクエスト・スマグリング攻撃では、フロントエンドとバックエンドが接続を再利用することを利用します。XSSの例ではこれが行われており、リクエストを送信する複数のユーザーがフロントエンドからバックエンドへの接続を共有し、スマグリングによってレスポンスが混在します。接続の再利用を無効にするとこの種の攻撃は防げますが、すべてのスマグリング攻撃を防げるわけではなく、リクエスト・トンネリングのような高度な手法も防げません。これはパフォーマンスにも影響する可能性があり、"partial"な緩和策にすぎません。
可能であれば、HTTP/2 をエンドツーエンドで使用してください
- HTTP/2は、ダウングレードが無効になっている場合、リクエスト・スマグリングに対して本質的に保護されています。可能であれば、これを使用することが最善の緩和策です。

概要

HTTP Request smugglingは、複数のデバイス間でのHTTPリクエスト解析の不整合から生じる脆弱性であり、認可のバイパス、他のユーザーに対する攻撃（XSSなど）の実行、キャッシュポイズニング、サービス拒否攻撃など、深刻な影響を引き起こす可能性があります。HTTP/2とダウングレードの無効化によりリクエストスマグリングを防止できますが、ダウングレードをサポートする必要がある場合は、攻撃対象領域をさらに制限するために、不正な形式のリクエストの拒否、あいまいなリクエストの正規化、HTTPスキーマの検証も検討する必要があります。

HTTP リクエスト・スマグリング攻撃などから安全を守るのに役立つ Fastly のセキュリティ製品の詳細をご覧ください。

Fastly のセキュリティソリューションの詳細

詳細