HTTP Request Smuggling：境界の曖昧さが招く、プロトコルの深淵
ネットワークエンジニアとして長年、パケットの海を泳いできた経験から言わせてもらえば、HTTPほど「単純に見えて、実は深い闇を抱えている」プロトコルはない。
HTTP/1.1の仕様書（RFC 7230）を読み解くたびに思うのだが、現代のWebインフラは、あまりにも「解釈の余地」に頼りすぎている。特に、フロントエンド（リバースプロキシやロードバランサー）とバックエンド（アプリケーションサーバ）の間に生じる「メッセージ境界の解釈不一致」を突く、HTTP Request Smuggling（HRS）は、現代の分散システムにおける最も洗練された、そして最も恐ろしい脆弱性の一つだ。
本稿では、なぜこの現象が起きるのか、そしてパケットレベルで何が起きているのかを、インフラアーキテクトの視点から紐解いていこう。
—
1. 境界判定の二重解釈：CL.TEとTE.CLの恐怖
HTTP/1.1において、パケットの終わりを告げる方法は二つある。`Content-Length` (CL) によるサイズ指定と、`Transfer-Encoding: chunked` (TE) によるチャンク形式だ。
問題は、フロントエンドとバックエンドが「どちらを優先すべきか」で意見が割れた時に発生する。
CL.TEのメカニズム
フロントエンドがCLを使い、バックエンドがTEを使う場合を考えよう。攻撃者は、以下のようなリクエストを投げる。
POST / HTTP/1.1
Host: vulnerable-site.com
Content-Length: 45
Transfer-Encoding: chunked
0
SMUGGLED_REQUEST_START_HERE
- フロントエンド: `Content-Length: 45` を見て、この塊全体を1つのリクエストとしてバックエンドへ転送する。
- バックエンド: `Transfer-Encoding: chunked` を見て、`0` という終端チャンクでリクエストが終わったと判断する。
- 結果: 残された `SMUGGLED_REQUEST_START_HERE` という文字列は、バックエンドのTCPストリーム内にある「次のリクエストの一部」として残留する。
次に誰か別のユーザーがリクエストを送ると、バックエンドは「先ほどの残留文字列」と「新しいリクエスト」を連結して解釈してしまう。これが、他人のセッションを奪取したり、キャッシュを汚染したりするHRSの正体だ。
—
2. パケットレベルの視点：TCPバッファとコネクション再利用
なぜこれが成立するのか？ それはHTTP/1.1のKeep-Aliveという設計思想に起因する。パフォーマンスを最適化するために、TCPコネクションは再利用される。
フロントエンドからバックエンドへのコネクションは、多くの場合、複数のユーザーのリクエストを束ねるマルチプレクサとして機能している。LinuxカーネルのTCPスタックレベルで見れば、ソケットの受信バッファに「処理されなかったデータ」が残り続けることで、次のプロセスがそれを先頭から読み込んでしまうのだ。
もしあなたがインフラアーキテクトなら、以下のカーネルパラメータや接続設定を見直す必要がある。
TCPコネクションの再利用（SO_REUSEADDR）とは別に、
アプリケーションレベルでの接続寿命（Keep-Alive Timeout）を短くし、
可能な限りリクエスト単位でのコンテキスト分離を徹底する。
Nginx側での設定例：バックエンドへの接続を厳格化
upstream backend {
server 127.0.0.1:8080;
keepalive 32;
keepalive_requests 100; # 無制限の接続再利用は避け、定期的リセットを強制
}
—
3. なぜ今、TLSハンドシェイクとRTT削減が仇となるのか？
現代のアーキテクチャでは、TLS終端をフロントエンドで行い、バックエンドへは平文で転送することが多い。ここで「パフォーマンスを優先してHTTP/2やHTTP/3のストリームをHTTP/1.1へ変換（ダウングレード）する」ゲートウェイを挟む場合が最も危険だ。
HTTP/2はバイナリプロトコルであり、ストリームの境界が明確である。しかし、それをHTTP/1.1へ変換する際、`Transfer-Encoding` ヘッダーの変換ロジックに不備があれば、脆弱性は即座に露呈する。
回避策としてのアーキテクチャ：
1. プロトコルの統一: フロントエンドからバックエンドまで、可能な限りHTTP/2以降で貫通させる。
2. ヘッダーの正規化: フロントエンドで `Content-Length` と `Transfer-Encoding` の両方が存在する場合、リクエストを拒否する（WAFのシグネチャによる防御ではなく、プロトコルスタックレベルでの破棄）。
3. コネクションの分離: 疑わしいパケットパターンを検知した場合は、該当するバックエンドへのTCP接続を即座に破棄（FIN/RST）し、バッファを強制フラッシュする。
—
4. エンジニアへの提言：仕様の「行間」を読む
結局のところ、HRSは「プロトコル仕様の行間」を悪用する攻撃だ。RFCを盲信して実装するのではなく、「ネットワークの境界では、常に期待値と異なるデータが届く」というゼロトラストの精神が必要になる。
パケットをキャプチャし、`tcpdump` で `Transfer-Encoding: chunked` が混在するフローを追いかけてみてほしい。
疑わしい通信をキャプチャし、HTTPヘッダーの不一致を抽出するコマンド例
sudo tcpdump -i eth0 -A ‘tcp port 8080’ | grep -E ‘Content-Length|Transfer-Encoding’
このコマンドから見えてくるのは、あなたのシステムが「どう解釈しているか」ではなく、「どう誤解させられているか」だ。
HTTP/1.1はレガシーと言われるが、Webの基盤である以上、我々はこれと心中する覚悟で、その挙動を隅々まで理解しなければならない。パフォーマンスチューニングに血道を上げるのもいいが、まずはその「境界」が、攻撃者によって歪められていないかを確認することから始めてみてほしい。
ネットワークは嘘をつかない。ただ、人間が勝手に誤解しているだけなのだから。
コメント