HTTP/2 Desync次世代リクエストスミッシング攻撃

HTTP/2のバイナリフレーミングが新たなスミッシングベクターを導入し、従来の防御を回避する方法を解説します。H2Cスミッシングやヘッダー名の悪用など、HTTP/1.1の保護が効かない攻撃手法について詳しく見ていきます。

はじめに：HTTP/2セキュリティの誤った期待

HTTPリクエストスミッシングは2005年からウェブアプリケーションに影響を与えており、サーバーのリクエスト境界の解釈の不一致を悪用しています。HTTP/2の登場により、バイナリフレーミングプロトコルが導入され、多くはこれらの脆弱性が解消されると期待されました。HTTP/2は各データフレームに明示的な長さフィールドを持ち、HTTP/1.1のContent-LengthやTransfer-Encodingの曖昧さを排除しています。

しかし、この楽観的な見方は早計でした。HTTP/2のダウングレード—フロントエンドサーバーがクライアントとHTTP/2で通信しつつ、リクエストをHTTP/1.1に書き換えてバックエンドに送る—は、HTTPリクエストスミッシングを含むさまざまな攻撃を可能にします。このプロトコル変換は、HTTP/2のセキュリティ保証が失われる危険なギャップを生み出し、高度な攻撃者がプロトコル間の継ぎ目を悪用できる状況を作り出しています。

この記事では、HTTP/2時代におけるリクエストスミッシングの進化を追い、H2Cスミッシング、CRLFインジェクション、ヘッダー操作を利用した攻撃手法について解説します。

HTTP/2リクエストスミッシングの基本理解

なぜHTTP/2は免疫とされていたのか

HTTP/2のリクエストはプレーンテキストではなくバイナリ形式に変換されて送信されます。リクエストは「フレーム」として表現され、各フレームには明示的な長さフィールドがあり、サーバーは何バイト読むべきかを知ります。この仕組みにより、HTTP/1.1のContent-LengthとTransfer-Encodingの曖昧さが排除され、脆弱性が減少します。

HTTPリクエストスミッシングはHTTP/1.1のプロトコル自体の脆弱性ではなく、リクエストの終了方法（Content-LengthとTransfer-Encoding）の指定の違いに起因するものであり、HTTP/2の単一で曖昧さのない長さメカニズムは理論上これらの攻撃を防ぐはずです。

ダウングレード問題

実際には、純粋なHTTP/2環境はまだ稀です。HTTP/2は広く使われていますが、エンタープライズ環境では新しいプロトコルの導入が比較的最近であるため、HTTP/1.1のみを使用するレガシーなバックエンドサーバーも存在します。これにより、HTTP/2フロントエンドとHTTP/1.1バックエンドの混在環境が生まれます。

HTTP/2の仕様では、Transfer-Encodingヘッダーを含むリクエストは削除またはブロックすべきと推奨していますが、フロントエンドサーバーがこれを無視し、ヘッダーをそのまま通すと、リクエストはHTTP/1.1にダウングレードされ、チャンクエンコーディングをサポートするバックエンドに渡されます。これがリクエストスミッシングの脆弱性を再び生む原因です。

攻撃ベクター：H2.CLとH2.TEのDesync

HTTP/2 to Content-Length (H2.CL) 攻撃

H2.CL攻撃では、フロントエンドのHTTP/2サーバーが存在しないはずのContent-Lengthヘッダーを渡します。リクエストがHTTP/1.1にダウングレードされると、バックエンドサーバーはこのヘッダーをリクエスト境界の判断に使い、スミッシングの機会を生み出します。

攻撃者はJavaScriptのインクルードをリダイレクトさせ、悪意のあるスクリプトを実行してユーザーアカウントを乗っ取り、パスワードやクレジットカード情報を盗むことが可能です。この攻撃をループさせることで、サイトの全アクティブユーザーを徐々に侵害できます。Netflixもこの脆弱性を経験し、ZuulプロキシからNettyに至る経路でCVE-2021-21295として記録され、最大20,000ドルの報奨金が支払われました。

HTTP/2 to Transfer-Encoding (H2.TE) 攻撃

RFCでは、コネクション固有のヘッダー（例：Transfer-Encoding）を含むメッセージは不正とみなすべきとしています。しかし、Amazon Web ServicesのApplication Load Balancerはこれを無視し、Transfer-Encodingを含むリクエストを受け入れ、ほぼすべてのウェブサイトに対してH2.TEのDesync攻撃を可能にしました。

これらの攻撃は、主要なクラウドプロバイダーでさえHTTP/2の実装ミスを引き起こし、何百万ものウェブサイトを脆弱にしています。

H2Cスミッシング：クリアテキスト接続アップグレード攻撃

H2Cスミッシングとは

H2Cスミッシングは、近年発見された最も革新的なHTTP/2攻撃技術の一つです。2020年9月にBishop Foxの研究者によって公開され、HTTP/2のクリアテキスト（H2C）を悪用し、フロントエンドがH2Cに対応していない場合にバックエンドシステムへのトンネルを作り、フロントエンドの書き換えルールを回避し、内部HTTPヘッダーを悪用します。

HTTP/1.1からHTTP/2（h2c）へのアップグレードは、エッジプロキシのアクセス制御をバイパスすることが可能です。この技術は2020年のPortSwiggerのセキュリティ投票で最優秀ウェブハッキング技術に選ばれました。

攻撃の仕組み

この攻撃は、HTTP接続をHTTP/1.1からHTTP/2にアップグレードできる仕組みを悪用します。h2cスミッシングはTLS経由でHTTP/1.1のアップグレードリクエストを送信し、直接バックエンドに到達させることで、プロキシ制御を回避します。TLS経由のh2cアップグレードは仕様違反ですが、多くのサーバーはこれを受け入れます。

h2cSmugglerは、HTTP/2クリアテキスト通信をh2c対応バックエンドに確立し、不正なプロキシルールやアクセス制御を回避します。

実世界への影響

H2Cスミッシングの影響調査により、多くのクラウドプロバイダーで認証やルーティング、WAFの回避が確認されました。最初の調査では免疫とされたクラウドも、より徹底的に技術を適用すると脆弱性が見つかっています。

このリクエストスミッシングにより、HTTP/2の多重化を利用して無制限にリクエストを送信可能です。内部ヘッダーの改ざん、制限された管理エンドポイントへのアクセス、HostヘッダーのSSRFなど、多彩な攻撃が可能です。

HTTP/2 HeadersのCRLFインジェクション

バイナリプロトコルの抜け穴

HTTP/2のバイナリ性は、HTTP/1.1を悩ませるCRLF（キャリッジリターン・ラインフィード）インジェクション攻撃を防ぐはずです。しかし、HTTP/2のバイナリ性のため、保護を回避しようとする複数の方法があります。ヘッダーにCRLFを挿入し、ヘッダーのスミッシングを行う攻撃が主要なベクターです。

HTTP/2仕様では、ヘッダーフィールドの値にASCII NUL（0x00）、LF（0x0a）、CR（0x0d）を含めてはならないと定めています。これらの文字が値に含まれると、そのリクエストは不正とみなされ、処理または破棄されるべきです。しかし、多くのサーバーはこれを厳格に守っていません。

悪用手法

Transfer-Encodingを任意のヘッダー値にCRLFシーケンスとともに挿入します（例：Foo: bar\r\nTransfer-Encoding: chunked）。このとき、リクエスト内に同じヘッダーが二重に存在する必要があります。

フロントエンドがこのHTTP/2リクエストをHTTP/1.1にダウングレードすると、CRLF文字を文字通り解釈し、新たなヘッダー行を生成します。これにより、バックエンドはセキュリティ制御を回避したTransfer-Encodingヘッダーを認識します。

HTTP/2からHTTP/1.1へのリクエストスミッシングを狙う場合、CRLFインジェクションはしばしば必要です。HTTP/1.1はテキストベースですが、HTTP/2はバイナリプロトコルであり、区切り文字も異なります。フロントエンドがHTTP/2リクエストをHTTP/1.1に変換する際、特定のバイナリ文字を改行と誤認識し、追加のヘッダーを注入できるのです。

レスポンスキューの毒化とセッションハイジャック

レスポンスの非同期化の理解

最も深刻な非同期攻撃の一つは、レスポンスキューの毒化です。非同期が発生すると、機密情報の漏洩やユーザ間のセッション汚染、持続的な侵害につながる可能性があります。

レスポンスキューの毒化は、追加のリクエストを最初のリクエスト後に隠し持つことで行われます。最初のリクエストが非同期を引き起こし、その後の正規ユーザのリクエストが攻撃者の制御下にあるプレフィックスに付加されるのです。攻撃者はセッションCookieや認証トークンを奪取できます。

実践的なセッション窃盗

レスポンスの非同期と従来のHTTP/1.1リクエストスミッシング技術を組み合わせることで、攻撃者は正規ユーザのリクエストを捕捉し、アカウント乗っ取りや機密情報へのアクセスを可能にします。攻撃は、巧妙に仕組まれたリクエストを送信し、非同期を引き起こし、その後のリクエストを攻撃者のコントロール下に置くことで進行します。

クライアント側の非同期化：新たなフロンティア

サーバ間だけでなくクライアントも

最近の非同期攻撃研究の重要な進展は、クライアント側の非同期（CSD）攻撃の発見です。これは、被害者のWebブラウザを騙して、脆弱なウェブサイトとの接続を非同期化させる攻撃です。これは、フロントエンドとバックエンド間の接続非同期化とは異なります。

この進化により、ユーザ接続を分離する設計のアーキテクチャも脆弱になり得ることが示されました。攻撃は、共有サーバーインフラではなく、クライアント自身の接続を標的としています。

高度な技術：ヘッダー名の悪用とエンコーディングトリック

脆弱なヘッダー検証の悪用

Cloudflareは、100番目のヘッダー以降に弱い検証を適用し、その後アップストリームサーバーにリクエストを転送しています。クライアントのHTTPサーバーがタブやスペースで終わるHTTPヘッダーを受け入れ解析できる場合、HTTP/1.1のリクエスト/レスポンスの非同期化を引き起こす可能性があります。

コロンや改行、A-Z文字は依然禁止されていますが、スペースやタブは攻撃に利用可能です。keep-alive接続でHTTPの非同期化を狙う場合、「transfer-encoding : chunked」（コロンの前にスペースあり）のような書き方が使われます。

新たな攻撃バリアント

研究は、Content-Lengthのゼロ長ヘッダーを悪用した0.CL攻撃、Expectヘッダーの操作、HTTP/2とHTTP/1.1、WebSocketアップグレードの連携など、新たな非同期技術を次々に明らかにしています。これらは未だ十分に研究されておらず、セキュリティ専門家による新たな攻撃手法の発見が続いています。

最近の脆弱性と実例

重要なCVE

複数の深刻な脆弱性が継続的な脅威を示しています：

CVE-2023-25690はApache HTTP Serverのmod_proxyリライトルールにおいてリクエスト分割とスミッシングを可能にし、バージョン2.4.56で修正されました。CVE-2023-25950はHAProxy 2.⁷⁄₂.6のHTXパーサのパイプラインリクエストの誤処理を指摘しています。CVE-2022-41721はGoのMaxBytesHandlerの残留ボディバイトをHTTP/2フレームとして誤解釈し、クロスプロトコルスミッシングを可能にしました。

Apache HTTP Serverのバージョン2.4.63までには、TLSアップグレード中にHTTPの非同期化やセッション乗っ取りを引き起こす脆弱性が存在し、CVE-2025-49812はTLSアップグレード機能の悪用を示しています。これにより、暗号化された接続も脆弱になり得ることが示されました。

バグバウンティへの影響

2024年にはTE.0やファンキーなチャンクの脆弱性に対する耐性が重要視され、2025年にはExpectや0.CL攻撃に対する免疫が確認され、報奨金は35万ドル超に達しました。これらの高額報酬は、HTTP/2の非同期化脆弱性の深刻さを反映しています。

検出とテストツール

専門的なテスト手法

TRACEリクエストは、スミッシング脆弱性の分析に非常に役立ちます。レスポンスは、バックエンドが受信している内容を正確に示し、プロキシによるヘッダーの変更や追加、HTTP/2からHTTP/1.1へのダウングレードなど、多くの非同期脆弱性の原因を把握できます。

これらの脆弱性を特定するツールには、

Burp Request Smuggler（v1.26以降）はH2.TE/H2.CLや隠しALPNサポートを自動テストします。拡張機能の設定で「HTTP/2 probing」を有効にしてください。
h2cSmugglerはBishop FoxによるPythonのPoCで、クリアテキストアップグレード攻撃を自動化します。
http2smuglは、エンジニアやDevOps、セキュリティチームが無料でHTTP/2リクエストスミッシングの脆弱性を検査できるツールです。バグバウンティ調査やさらなる脆弱性発見にも役立ちます。

防止策と緩和戦略

最優先の防御策：エンドツーエンドのHTTP/2

HTTPリクエストスミッシングを防ぐには、HTTP/2をエンドツーエンドで使用し、ダウングレードを無効にします。HTTP/2はリクエストの長さを決定する堅牢な仕組みを持ち、エンドツーエンドで運用すれば、リクエストスミッシングに対して本質的に保護されます。

HTTP/2のエンドツーエンド接続を確保し、ダウングレードを拒否してください。特にダウングレードをサポートするサーバーを運用している場合は、リクエストのサイズを過剰に指定したヘッダーを拒否する設定を行いましょう。

ダウングレードが避けられない場合

HTTPダウングレードを避けられない場合は、書き換えられたリクエストをHTTP/1.1仕様に沿って検証します。追加の対策としては、

Content-LengthとTransfer-Encodingの両方を含む曖昧なリクエストを拒否（フロントエンド・バックエンド両方で）
フロントエンドとバックエンド間のコネクションの再利用を避け、非同期リクエストの持続を防止
WAFを導入し、リクエストスミッシングの試行を検知・ブロック
フロントエンドとバックエンドで同じサーバーを使用し、パースや解釈の違いをなくす

H2C特有の緩和策

H2Cスミッシングの対策はシンプルです—エッジでUpgradeヘッダーを除去またはハードコードします（WebSocketを除く）。

多層防御の戦略を維持し、アーキテクチャ内のスミッシングヘッダーの重要性を低減させ、疑わしいリクエストを検知・拒否できる体制を整えましょう。

CRLFインジェクションの防止

ヘッダーに特定のシーケンス（例：CRLF）を含むリクエストをブロックすることも有効です。サーバーは、HTTP/2仕様のヘッダー値に対するCRLF禁止を厳格に適用すべきです。

今後の展望と新たなトレンド

HTTP/1.1の持続性

HTTP/1.1は、そのメッセージ境界が複数の方法で表現できるため、リクエストスミッシングに特に脆弱です。RFCは厳格なルールを定めていますが、実際には異なる解釈や実装の差異により、多くのサーバーが微妙に異なるリクエストを受け入れています。これにより、互換性を保つために、多少の不正なリクエストも許容されるケースがあります。

HTTPリクエストスミッシングは、多くの現代アプリケーションがレガシーなHTTP/1.1スタックに依存しているため、依然として広く存在します。パッチ適用も困難な場合が多く、サーバー環境間のHTTPプロトコルのサポートの不一致も一因です。

研究の継続

デシンク攻撃を含むスミッシング攻撃は、現代ウェブの主要な脅威であり、HTTP/1.1とHTTP/2の両方において重要です。研究者は、プロトコル間の相互作用を引き続き調査し、新たな攻撃ベクターの出現に備えています。

結論

HTTP/2のデシンク攻撃は、リクエストスミッシングの進化形であり、プロトコル間のギャップを突いています。HTTP/2のバイナリフレーミングは、従来のスミッシング攻撃を可能にした曖昧さを排除する設計ですが、バックエンド通信のためにリクエストをHTTP/1.1にダウングレードする慣行がこれらの脆弱性を再導入しています。

組織は、HTTP/2をエッジだけで採用するだけでは不十分であることを認識し、エンドツーエンドのHTTP/2運用、厳格なヘッダー検証、プロトコルアップグレードの慎重な取り扱い、そして新たな攻撃手法に対する継続的な警戒が必要です。ウェブインフラの進化に伴い、異なるプロトコルバージョン間の相互作用は、攻撃者にとって魅力的なターゲットとなり続けるでしょう。セキュリティチームは、可能な限りダウングレードを排除し、堅牢なヘッダー検証を実施し、この分野の最新研究に追随すべきです。

重要ポイント:

HTTP/2のダウングレードは、純粋なHTTP/2では防げるリクエストスミッシングの脆弱性を再導入します
H2Cスミッシングは、クリアテキストアップグレードを悪用し、エッジプロキシ制御を回避します
CRLFインジェクションはHTTP/2ヘッダーにおいて追加ヘッダーをスミッシングし、フロントエンドの検証を突破します
エンドツーエンドのHTTP/2運用が最も効果的な防御策です
研究は継続的に新たな攻撃技術を明らかにしています