こんにちは！世界最高峰のネットワークアーキテクトにして、皆さんの熱い視線を一身に浴びる技術メディアの主筆ライター、私です！
今日もネットワークの奥深い世界へ、一緒に冒険に出かけましょう。
「HTTPって、普段何気なく使っているけど、奥が深いですよね〜」
ウェブサイトを見たり、SNSを更新したり、オンラインショッピングをしたり。私たちがインターネットでしていることのほとんどは、HTTP（HyperText Transfer Protocol）というプロトコルのおかげで成り立っています。
でも、このHTTP、ただ情報をやり取りしているだけじゃないんです。時には、まるでスパイ映画のように、秘密裏に情報が”すり抜け”てしまうような、ちょっと怖い話もあるんですよ。
それが今回ご紹介する「HTTPリクエストスマグリング（Request Smuggling）」という脆弱性です。
「うわ、なんか難しそう…」「スマグリングって、密輸のこと？」
大丈夫！安心してください。小難しい専門用語は極力避け、まるで郵便配達の仕組みを紐解くように、一歩ずつ、丁寧に解説していきますからね。ネットワークの初心者さんでも、きっと「なるほど！」と膝を打つような解説をお届けします。
さあ、一緒にHTTPのちょっとした「隙間」を覗きに行きましょう！
—
## HTTP/1.1の進化と「荷物の扱い方」の変化
HTTPは、皆さんの想像以上に長い歴史を持っています。最初はとってもシンプルだったんです。
# HTTP/0.9：超シンプルな「お手紙」時代
HTTPの最初のバージョンであるHTTP/0.9は、まさに「シンプルなお手紙」でした。
「このファイルちょうだい！」とだけ書いて送ったら、そのファイルがそのまま返ってくる。それだけ。
まるで、郵便屋さんが「〇〇さんの家に手紙を届けて！」と言われたら、その手紙だけを届けてハイおしまい、という感じですね。一度荷物を届けたら、また次の依頼があるまでじっと待つ、そんな素朴な時代でした。
# HTTP/1.1：効率重視の「宅配便」時代へ
ところが、インターネットの利用が爆発的に増えると、こんなシンプルなやり方では追いつかなくなります。
そこで登場したのが、皆さんが今も最もよく使っているHTTP/1.1です。
HTTP/1.1では、まるで「宅配便」のように、もっと効率的にたくさんの荷物（リクエスト）を扱うことができるようになりました。
- 接続の再利用（Persistent Connection）: 一度開いた接続を、複数のリクエストで使い回せるようになりました。
- 例えるなら、宅配便のお兄さんが、一度お客さんの家に来たら、ついでに他の荷物も受け取ったり、別の届け物も済ませたりするイメージです。一回一回「ピンポーン、失礼しまーす！」なんてやってたら大変ですよね。
- パイプライン処理: 最初のレスポンスを待たずに、次のリクエストを送れるようになりました。
- これはまさに、宅配便のお兄さんが「荷物Aをどうぞ！…あ、ついでに荷物Bもお願いします！」と、次々に依頼を受け付けられるようになった感じです。
これらの進化によって、ウェブサイトの表示は格段に速く、快適になりました。
しかし、効率を追求した結果、「どこからどこまでが一つの荷物（リクエスト）なのか？」という、荷物の区切りを正確に判断することが非常に重要になったんです。そして、この「荷物の区切り」の判断ミスが、今回のお話の主役である「リクエストスマグリング」を引き起こすことになります。
—
## 「荷物の長さ」を伝える二つの方法：Content-Length vs. Transfer-Encoding
皆さんが誰かに荷物を送るとき、どんな情報を伝えますか？
「これは〇〇さんに送る荷物です」という宛先情報と、「中身はこれこれです」という荷物本体。
HTTPリクエストも同じで、ヘッダー（宛先情報）とボディ（荷物本体）に分かれています。
そして、荷物本体（ボディ）の「長さ」を伝える方法が、HTTP/1.1には主に二つあります。ここがスマグリングの肝になるところなので、じっくり見ていきましょうね。
# 方法1: 「Content-Length」ヘッダーで正確なサイズを伝える
一つ目の方法は、`Content-Length`というヘッダーを使うものです。
これは、郵便局で荷物の重さを測って、「この小包は正確に1234グラムです！」と伝票に書き込むようなイメージです。
- 特徴: 送るボディのデータが、ぴったり何バイト（文字数やデータの量）なのかを数値で指定します。
- 荷物の終わり: このバイト数だけ読み込んだら、それが一つのリクエストの終わりだと判断します。
POST /submit HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 19 <-- ここ！「ボディは19バイトですよ」と教えています
name=Alice&age=30 <-- これがボディ。19文字ですね
これは分かりやすいですよね。郵便局員さんも、伝票の「19グラム」を見て、その重さの荷物だけを扱います。
# 方法2: 「Transfer-Encoding: chunked」で小分け配送を伝える
もう一つの方法は、`Transfer-Encoding: chunked`というヘッダーを使うものです。
これは、大きな荷物を送るときに、「今回は分割して送りますね！途中で小分けにした荷物のサイズをその都度お知らせしますから、最後の箱が来たら終わりと判断してくださいね」と伝える宅配便のようなイメージです。
- 特徴: ボディ全体がどれくらいの長さになるか事前に分からない場合や、大きなデータを少しずつ送りたい場合に便利です。データを「チャンク（塊）」に小分けにして送り、各チャンクの先頭にそのチャンクのサイズを付けて送ります。
- 荷物の終わり: 最後に「0\r\n\r\n」という、サイズがゼロのチャンク（「もう終わりですよ」という目印）が来たら、それが一つのリクエストの終わりだと判断します。
POST /submit HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked <-- ここ！「小分けにして送りますよ」と教えています
b <-- 16進数で11バイト（「b」は16進数で11）
name=Alice&age= <-- 11バイトのデータ
8 <-- 16進数で8バイト
30 <-- 8バイトのデータ
0 <-- もう終わりですよの目印
<-- 最後の空行
これはちょっと複雑に見えますが、宅配便の「荷札に『この箱は〇〇kg』と書いて、全部の箱が届いたら終わり」というのと似ています。最後に「これでおしまい！」という目印があれば、配達員さんはそこで作業を終えられますよね。
# 共存する二つのヘッダー、そして「解釈の不一致」
さて、ここからが本題です。
HTTP/1.1の仕様では、`Content-Length`と`Transfer-Encoding: chunked`が同時に存在する場合、`Transfer-Encoding: chunked`が優先されると決められています。これは「特別な指定がある場合は、そちらを優先する」という、いわばルールブックです。
しかし、世の中のすべてのWebサーバーやプロキシ（中継サーバー）が、このルールブックを完璧に守っているとは限りません。
一部のシステムは「Content-Lengthが書いてあるなら、それを信じよう」と判断し、また別のシステムは「Transfer-Encoding: chunkedがあるから、こちらを優先しよう」と判断する可能性があります。
この「解釈の不一致」こそが、リクエストスマグリングの根本的な原因なんです！
—
## なぜスマグリングが起きるのか？「中継役」の存在と判断ミス
私たちの普段のインターネット利用では、皆さんが使っているブラウザと、目的のWebサーバーの間に、いくつもの「中継役」が存在することがほとんどです。
これらをまとめてプロキシサーバーとか、ロードバランサー、WAF（Web Application Firewall）などと呼びます。
例えるなら、皆さんが書いた郵便物（リクエスト）は、直接目的の相手（Webサーバー）に届くのではなく、いくつかの郵便局（プロキシ）を経由して届けられるようなものです。
1. 皆さんのブラウザ → 2. 社内のプロキシ/WAF → 3. ロードバランサー → 4. Webサーバー
このように、いくつもの「中継役」がいる中で、「荷物の長さ」の解釈がバラバラになるとどうなるでしょうか？
# 郵便局A（フロントエンド）と郵便局B（バックエンド）の誤解
考えてみてください。
- 郵便局A（フロントエンドのプロキシ）: 「よし、この荷物には`Content-Length`が書いてあるな。じゃあ、その長さだけ読んで、次の荷物に移ろう。」
- 郵便局B（バックエンドのWebサーバー）: 「あれ、この荷物には`Transfer-Encoding: chunked`が書いてあるぞ。ってことは、チャンクの終わりを示す`0\r\n\r\n`が来るまで読み続けよう。」
同じ一つの荷物を扱っているのに、郵便局Aと郵便局Bで、「どこまでが一つの荷物だと判断するか」が変わってしまうんです！
これがまさに、リクエストスマグリングが発生するメカニズムの核心です。
郵便局Aは「ここで荷物終わり！」と思ったけど、実はまだ続きがあって、その続きの部分が次の荷物と混ざってしまう…そんなイメージですね。
—
## スマグリングの仕組みを具体的に見てみよう！
では、実際にどんなリクエストを送ると、スマグリングが起きるのか、具体的な例を見てみましょう。
悪意のある攻撃者は、この解釈の不一致を悪用して、「見せかけのリクエスト」と「隠されたリクエスト」を巧妙に一つのHTTPリクエストの中に混ぜ込みます。
# 攻撃用のリクエスト例
攻撃者は、次のようなリクエストを送ります。
POST /search HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100 // (A) フロントエンドが読む長さ。実際には短い
Transfer-Encoding: chunked // (B) バックエンドが読む長さ。これを優先する
// ここからボディ
5c // 16進数で92バイト。チャンクの長さ。バックエンドはこれを読む
GET /admin HTTP/1.1 // 隠されたリクエストの開始
Host: example.com
Content-Length: 10 // 隠されたリクエストのダミーのContent-Length
GET /other HTTP/1.1 // 隠されたリクエストの続き（次のリクエストと混ざる部分）
Host: example.com
Foo: bar
0 // チャンクの終わり。バックエンドはここで区切る
# 何が起きるのか？
このリクエストが、フロントエンドのプロキシとバックエンドのWebサーバーを通過する際、それぞれの解釈の違いによって次のようなことが起こります。
1. フロントエンド（プロキシ）の解釈:
- `Content-Length: 100` を読みます。（多くの場合、仕様に従わず、先に書いてあるContent-Lengthを見てしまう）
- ボディの先頭から100バイトだけを読み込み、「これで一つのリクエストの終わりだな」と判断します。
- その100バイトのリクエストを、バックエンドのWebサーバーへ転送します。
2. バックエンド（Webサーバー）の解釈:
- フロントエンドから転送されてきたリクエストを受け取ります。
- `Transfer-Encoding: chunked` ヘッダーを見つけます。
- 仕様に従い、`Transfer-Encoding: chunked` を優先し、チャンクの終わりを示す `0\r\n\r\n` が来るまでボディを読み続けます。
- すると、バックエンドは、ボディ全体を一つの大きなリクエストとして解釈します。
結果、どうなるか？
フロントエンドは「ここまでが最初の荷物！」と思ったけれど、バックエンドは「あれ、まだ続きがあるぞ、`0`まで読まないと」と読み進めます。
そして、バックエンドが読み終わった後、フロントエンドは既に「次のリクエスト」を処理しようとしています。
その「次のリクエスト」の先頭に、悪意のあるリクエストの「混入された部分」がくっついてしまうんです！
もし、次のユーザーが `/index.html` にアクセスしようとしていたら、そのリクエストの前に、攻撃者が仕込んだ `GET /other HTTP/1.1` の部分がくっついてしまい、`GET /other HTTP/1.1 GET /index.html HTTP/1.1` のような、意図しないリクエストとして処理されてしまう可能性があります。
—
## スマグリングで何ができるの？（脆弱性の影響）
リクエストスマグリングが成功すると、攻撃者は以下のような様々な攻撃を行うことが可能になります。
- 他のユーザーのリクエストの改ざん・横取り: 他のユーザーのリクエストに攻撃者の用意したヘッダーやボディを混入させ、意図しない挙動を引き起こしたり、本来見えないはずの情報を見たりすることができます。
- セッションハイジャック: 他のユーザーのセッションIDを盗み取り、そのユーザーになりすましてサービスを利用することが可能になる場合があります。
- キャッシュポイズニング: プロキシサーバーのキャッシュに、攻撃者の意図する不正なコンテンツを保存させ、他のユーザーがそのキャッシュにアクセスした際に、不正なコンテンツを表示させることができます。
- 認証回避: 管理者ページなど、本来アクセス制限されているページに、巧妙なリクエストを送り込むことでアクセスできてしまう可能性があります。
まるで、郵便局員が「この荷物で終わり！」と判断した後に、こっそり自分の手紙を紛れ込ませて、次の人の郵便物と一緒に送りつけてしまうようなものです。しかも、送られた相手は、それが一つの荷物だと信じて処理してしまう…恐ろしいですよね。
—
## どうすれば防げるの？（対策）
このHTTPリクエストスマグリングという脆弱性、怖い話ではありますが、ちゃんと対策することができます！
# 1. プロキシとWebサーバーの解釈を統一する（最も重要！）
これが最も根本的な対策です。フロントエンド（プロキシ、ロードバランサーなど）とバックエンド（Webサーバー）の両方が、HTTPの仕様に厳密に従い、リクエストの終端を同じ方法で判断するように設定を統一することが重要です。
- `Content-Length`と`Transfer-Encoding`が両方ある場合、必ず`Transfer-Encoding: chunked`を優先するように設定を見直しましょう。
- あるいは、プロキシ側で`Transfer-Encoding`ヘッダーを削除または正規化するなどの対応も有効です。
# 2. 最新のWebサーバー/プロキシソフトウェアを使用する
多くのWebサーバーやプロキシソフトウェアは、この脆弱性に対応するための修正が施されています。常に最新の安定バージョンを使用し、セキュリティパッチを適用することが大切です。
# 3. WAF（Web Application Firewall）を導入する
WAFは、悪意のあるリクエストパターンを検知し、ブロックする役割を担います。リクエストスマグリングに繋がるような、不正な形式のリクエストを検知して遮断することで、攻撃を防ぐことができます。
# 4. HTTP/2やHTTP/3への移行を検討する
根本的な解決策として、HTTP/2やHTTP/3への移行も挙げられます。これらの新しいHTTPバージョンでは、リクエストのパース（解析）方法が根本的に変更されており、リクエストスマグリングのような脆弱性は発生しにくくなっています。
これは、郵便の仕組み自体を「封筒の中に何枚手紙が入ってるか」ではなく、「封筒の数で一区切り」と変えてしまうようなもので、荷物の区切り方がより明確になるため、解釈の不一致が起こりにくくなるんです。
—
## まとめ：「知る」ことが、あなたのネットワークを守る第一歩！
今回は、HTTPのちょっとダークな側面、「リクエストスマグリング」について、郵便配達の例えを交えながら、その仕組みと対策を解説しました。
- HTTP/1.1で効率化されたがゆえに、「荷物の区切り」の判断が重要になったこと。
- `Content-Length`と`Transfer-Encoding: chunked`という二つの「荷物の長さの伝え方」があること。
- フロントエンドとバックエンドの「解釈の不一致」が、攻撃を可能にする原因であること。
- 攻撃が成功すると、他のユーザーの情報が盗まれたり、Webサイトが改ざんされたりする可能性があること。
- そして、設定の統一や最新バージョンへのアップデート、新しいHTTPバージョンへの移行が対策となること。
ネットワークの世界は、普段見えないところで様々な仕組みが動いています。そして、その仕組みを深く知ることで、初めて見えてくる「隙間」や「脆さ」が存在します。
今回の話が、皆さんがネットワークの仕組みをもっと深く理解し、よりセキュアなシステムを設計・運用するための一助となれば、これほど嬉しいことはありません。
これからも、皆さんの「知りたい！」に応えるべく、パケットが駆け巡るリアルな現場の知見を、人間味あふれる文脈でお届けしていきますので、どうぞお楽しみに！
それでは、また次回の記事でお会いしましょう！
コメント