HTTPリクエストスマグリングとは？仕組み・被害例・対策をわかりやすく解説

Webアプリケーションの裏側に潜む「見えない通信の隙間」を攻撃者が突いてくる——そんな脅威が、HTTPリクエストスマグリングです。

近年、大手クラウドサービスやCDNのバグバウンティプログラムで高額報酬案件として注目を集めており、クラウドネイティブな構成が増えた現代のインフラでは、特に注意が必要な脆弱性のひとつです。

この記事では、HTTPリクエストスマグリングの仕組み・実際の被害シナリオ・具体的な防御手順を、現場エンジニアが理解できるレベルで丁寧に解説します。「自社サービスが対象になりえるかどうか」の判断基準も示しますので、ぜひ最後まで読んでいただければと思います。

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

HTTPリクエストスマグリング（HTTP Request Smuggling）は、フロントエンドサーバー（ロードバランサーやリバースプロキシ）とバックエンドサーバーの間で、HTTPリクエストの「境界」の解釈にズレが生じる脆弱性です。

現代のWebシステムは、ほとんどの場合「クライアント → フロントエンド（CDN・LB・リバースプロキシ）→ バックエンド（アプリサーバー）」という多層構成を取っています。この2つのサーバー間でリクエストの長さを異なる方法で解釈させることで、攻撃者は本来送れないはずのリクエストをバックエンドに「密輸（スマグル）」できるようになります。

最初に報告されたのは2005年ですが、2019年にPortSwigger社のJames Kettleが現代的なシステムへの適用手法を体系化したレポートを発表したことで、実用的な攻撃手法として広く認識されるようになりました。

攻撃の仕組み：なぜ「境界の解釈ズレ」が起きるのか

HTTPにはリクエストの長さを示す方法が2つあります。

・Content-Length（CL）: リクエストボディのバイト数を数値で指定
・Transfer-Encoding: chunked（TE）: チャンク（塊）単位でデータを送り、「0」で終端を示す

正常な動作では、フロントとバックエンドが同じ方法でリクエスト境界を判断します。しかし、どちらのヘッダを優先するかの実装が異なると、攻撃者はその「解釈のズレ」を利用できます。

1. CL.TE型（フロントがCL優先、バックエンドがTE優先）

フロントエンドはContent-Lengthを見てリクエスト全体を1つとして処理し、バックエンドに転送します。ところがバックエンドはTransfer-Encodingを優先するため、チャンク境界で区切って処理します。

この結果、攻撃者が仕込んだデータが「次のリクエストの先頭」として解釈され、バックエンドのキューに残り続けます。その後に続く別のユーザーのリクエストに、攻撃者のデータが「前置き」として付加される形になるのです。

2. TE.CL型（フロントがTE優先、バックエンドがCL優先）

フロントエンドはTransfer-Encodingで処理するため、チャンク終端（「0

」）までを1リクエストと見なします。バックエンドはContent-Lengthを使って解釈するため、フロントが転送した「残り部分」が次のリクエストとして処理されてしまいます。

3. TE.TE型（両方TEを優先するが、難読化で片方を無効化）

ヘッダを難読化（スペースの挿入・大文字小文字混在・無効なエンコード値など）することで、片方のサーバーがTE処理を諦め、CLへフォールバックするよう誘導します。

# TE.TEの難読化例（攻撃者が送るリクエストヘッダの概念）
Transfer-Encoding: chunked
Transfer-Encoding : chunked   # スペースでパーサーを混乱させる試み
# 一方のサーバーが後者を無効と判断すればCLへフォールバックする

実際にどんな被害が起きるのか

HTTPリクエストスマグリングが成功した場合、以下のような深刻な被害が発生します。

1. 他ユーザーのリクエストを汚染・盗取

攻撃者のリクエスト断片が、次の一般ユーザーのリクエストに付加されます。その結果、ユーザーのCookieや認証トークン、セッションIDが攻撃者のリクエストに混入し、サーバーのレスポンスとして攻撃者に返ってくることがあります。

2. フロントエンドのセキュリティチェックをバイパス

CDNやWAFなどのフロントエンドは、特定のパスへのアクセス制御・IPブロック・レート制限といった処理を担っています。スマグリングによってバックエンドに「密輸」されたリクエストはこれらの検査をすり抜け、通常なら拒否されるはずのリソースにアクセスできてしまいます。

3. Webキャッシュポイズニングへの発展

スマグリングをキャッシュポイズニングと組み合わせると、被毒したレスポンスをCDNのキャッシュに乗せることで、対象サイトにアクセスする不特定多数のユーザーに悪意あるコンテンツを配信できます。被害規模が一気に拡大する危険なシナリオです。

4. 認証されていないページへのアクセス

認証チェックを担うフロントエンドをバイパスし、バックエンドの管理機能・内部APIに直接到達することで、情報漏洩や不正操作につながります。

具体的な防御手順

1. HTTPのバージョンをHTTP/2に統一する

HTTP/2では、リクエストの境界が明確に定義されており、Transfer-EncodingとContent-Lengthの解釈ズレが構造的に発生しません。フロントエンド〜バックエンド間の通信もHTTP/2またはHTTP/2のセマンティクスを維持したダウングレードで行うことが最も根本的な対策です。

ただし、バックエンドがHTTP/1.1のみ対応している場合、フロントが変換処理をするため、その際に同様のズレが生じうる点は注意が必要です。

2. Transfer-EncodingとContent-Lengthの矛盾を拒否する

両方のヘッダが含まれるリクエストは、RFC 7230の規定上も「悪い入力」です。フロントエンド・バックエンドの両方で、両ヘッダが同時に存在するリクエストを拒否するか、どちらかを優先する一貫した設定を施します。

# Nginx設定例: CLとTEの両方が来た場合に接続を切る
# nginx.confのhttpブロック内に追加
ignore_invalid_headers on;    # デフォルトはon
underscores_in_headers off;   # デフォルトはoff（有効化推奨）

3. フロントエンドとバックエンドの間でHTTPパイプラインを使わない

Keep-Aliveを使ったパイプラインでは、1本のTCPコネクションに複数のリクエストを流せます。これが境界ズレの温床になるため、フロントとバックエンド間は「リクエストごとにコネクションを切る」か、HTTP/2で多重化することが推奨されます。

4. WAFの設定を見直す

WAF（Webアプリケーションファイアウォール）にHTTPリクエストスマグリング検出ルールが含まれているか確認します。主要なWAFプロバイダー（AWS WAF、Cloudflare、ModSecurity等）はこの攻撃への対応ルールを提供していますが、デフォルトでは無効になっているケースがあります。

セキュリティマスターズ.TOKYOの姉妹サイトLinuxMaster.JPでも、Nginxのリバースプロキシ設定に関する記事を掲載しています。Nginxを使っている場合はあわせてご参照ください。

5. 定期的な脆弱性スキャンを実施する

Burp SuiteのProfessionalエディションには、HTTPリクエストスマグリングを自動検出する専用スキャナーが含まれています。外部からのペネトレーションテストを年に1回以上実施し、スマグリング耐性を確認することをお勧めします。

中小企業でも今日からできること

「うちはCDNを使っているだけで自分ではサーバーを管理していない」という場合でも、以下は確認できます。

・CDN・LBの設定確認: CloudflareやAWS CloudFrontなどを使っている場合、管理コンソールでHTTP/2の有効化と「あいまいなリクエスト拒否」設定を確認する
・ミドルウェアのアップデート: Nginx・Apache・HAProxyなどはHTTPリクエストスマグリングへの対応パッチが過去に複数リリースされています。最新版を維持するだけで多くのリスクを回避できます
・レスポンスの監視: 通常と異なるステータスコードやレスポンス内容の急増は、スマグリング攻撃の痕跡である可能性があります。ログ監視アラートを設定しましょう
・SaaSの場合はベンダーに確認: Shopify・kintoneなどを使っている場合は、ベンダーのセキュリティポリシーやインシデント対応ページを確認しておくだけでも有益です

よくある誤解と注意点

【誤解1】「HTTPS通信していれば安全」

TLS暗号化はリクエストの内容を第三者から守りますが、スマグリングはフロントとバックエンドの「内側の通信」で起きます。HTTPS化とは別次元の問題です。

【誤解2】「小さなサイトは狙われない」

攻撃者は自動スキャンツールを使って大量のサイトを短時間でチェックします。規模に関係なく、脆弱な構成であれば標的になりえます。「うちは小さいから」という油断は禁物です。

【誤解3】「WAFを入れれば完璧」

WAFはあくまで多層防御の一要素です。フロントとバックエンドの構成そのものを安全にすること（HTTP/2統一・矛盾ヘッダ拒否）が優先です。WAFに全依存するのは危険です。

【注意】攻撃検証は必ず許可を得た環境で

HTTPリクエストスマグリングの動作確認や検証は、必ず自分が権限を持つ環境・ステージング環境のみで実施してください。第三者のシステムに対して無断でスキャンや検証を行うことは、不正アクセス禁止法に抵触する可能性があります。詳細は法律の専門家にご確認ください。

本記事のまとめ

HTTPリクエストスマグリングは、一見地味に見えて被害が連鎖しやすい攻撃です。「多層構成にしているから安全」という思い込みを捨て、各レイヤーのHTTP処理が一貫しているかどうかを定期的に確認することが重要です。