【入門編】HTTPリクエストスマグリングの発生原理 – HTTPプロトコル・通信規格実践ガイド

「箱の中身は誰が決める？」HTTPリクエストスマグリングの深淵へようこそ

こんにちは！ネットワークの世界へようこそ。
普段、何気なくブラウザでWebサイトを見ているとき、裏側では「HTTP」という名の郵便屋さんが、休むことなく荷物を運んでいます。

今日は、そんな郵便配達の仕組みを悪用して、「HTTPリクエストスマグリング」という少し恐ろしい、けれど非常に興味深い攻撃手法についてお話しします。

「スマグリング（密輸）」という言葉の通り、本来送るはずのない荷物を、正規の荷物のふりをしてこっそり忍び込ませるテクニックです。なぜこんなことが起きてしまうのか、一緒に紐解いていきましょう！

—

HTTPリクエストスマグリングを理解するために、あるオフィスビルを想像してみてください。

通常、受け付け係は「この荷物は〇〇バイトの大きさだから、ここまでが1つの荷物だね」と確認し、バックエンドに渡します。しかし、「荷物の境界線」の判断基準が二人で異なっていたらどうなるでしょうか？

これが、HTTPリクエストスマグリングの入り口です。

—

HTTPの世界では、荷物のサイズを伝えるために主に2つのヘッダー（伝票のようなもの）を使います。

1. Content-Length（CL）： 「この荷物は全部で何バイトあるか」を数字で教えるもの。
2. Transfer-Encoding（TE）： 「荷物をいくつかに分割して送るから、最後がどこか自分で判断してね」と伝えるもの。

問題は、「両方のヘッダーが同時に届いたとき、どちらを優先するか」というルールが、受け付け係と仕分け係で食い違っているときに発生します。

例えば、悪意のある攻撃者はこんなリクエストを送ります。

POST / HTTP/1.1
Host: example.com
Content-Length: 45
Transfer-Encoding: chunked

0 # ここで「荷物は終わり」と伝える

GET /admin HTTP/1.1 # これが密輸された「次の荷物」
Host: example.com

結果として、バックエンドは「管理画面へのリクエスト（GET /admin）」を、全く別のユーザーの正当なリクエストの一部として処理してしまうのです。これが「スマグリング」の正体です。

—

「そんなの、ルールを統一すればいいじゃないか」と思いますよね。その通りです！しかし、歴史的な背景がこれを難しくしています。

HTTPの歴史は長く、古い規格から新しい規格へと少しずつ進化してきました。異なるメーカーの機器や古いシステムが混在する現代のネットワークでは、「どれを優先すべきか」の解釈が、機器の設計思想によって微妙に異なることがあるのです。

特に、複数のリクエストを1つのコネクション（回線）で効率よくやり取りする仕組みが標準的になった今、この「境界線の見極めミス」は、そのまま深刻なセキュリティホールに直結してしまいます。

—

この攻撃を防ぐためには、私たちが管理するネットワーク機器やサーバーの設定を「厳格」にすることが大切です。

ヘッダーの重複を許さない： `Content-Length`と`Transfer-Encoding`が両方含まれるリクエストを、ゲートウェイ（入り口）で即座に拒否する設定を行う。
HTTP/2以降への完全移行： HTTP/1.1の曖昧さを排除した新しいプロトコルでは、荷物の区切りがより明確に定義されています。可能であれば、最新の規格へインフラをアップデートしましょう。
正規化（Normalization）： ゲートウェイでリクエストを一度解釈し、バックエンドに渡す際に「正しい形」に書き直してから転送する。

—

HTTPリクエストスマグリングは、単なるコードのバグではなく、「二つのシステム間のコミュニケーションのズレ」を突く高度な攻撃です。

私たちが守るべきなのは、単なる箱（サーバー）そのものではなく、その箱の間を流れる「通信のルール」そのものなのかもしれません。

初めてこの概念を知ると少し難しく感じるかもしれませんが、まずは「郵便配達員と仕分け係の認識合わせ」という感覚を大切にしてみてください。日々のデバッグやネットワーク監視の中で、「あれ、この機器はここをどう解釈しているんだろう？」と一歩立ち止まって考えることが、世界最強のエンジニアへの第一歩です。

皆さんのネットワークが、今日も安全で軽快にパケットを運べますように！