HTTP/2・HTTP/3の深淵：HPACK/QPACK圧縮攻撃が突く「メモリの綻び」
HTTP/1.1の時代、私たちは「ヘッダーが重い」と嘆き、それを解決するためにHTTP/2のHPACK（Header Compression）を歓迎した。だが、セキュリティの世界において「効率化」とは常に「攻撃対象領域の拡大」と同義だ。
最近のインシデントハンドリングで改めて痛感するのは、プロトコル層の仕様を悪用した「リソース枯渇（DoS）」攻撃がいかに洗練されているかということだ。特にHTTP/2のHPACK（RFC 7541）およびHTTP/3のQPACK（RFC 9204）は、ステートフルな圧縮アルゴリズムであるがゆえに、サーバーのメモリ管理を容易に破綻させる。
今回は、単なる「設定ガイド」ではなく、なぜこれらが脆弱性となるのか、その低レイヤの力学と防御の勘所を解き明かす。
—
1. 圧縮攻撃の正体：ステートフルな「メモリの罠」
HPACKは、一度送ったヘッダーを「動的テーブル」にキャッシュし、インデックス番号で参照することでトラフィックを削減する。この設計が何を意味するか？ 攻撃者は、「サーバーに巨大な動的テーブルを強制的に構築させる」ことが可能だということだ。
攻撃者は、巧妙に細工されたヘッダーを連続して送りつける。これによりサーバーのメモリ上に巨大なハフマン符号化データが展開され、テーブル更新のためのCPUサイクルとメモリ領域が激しく消費される。これが「Rapid Reset（CVE-2023-44487）」のような攻撃の根底にあるメカニズムだ。
低レイヤでの挙動
- テーブルサイズの上限突破: RFCではデフォルトで4KBの動的テーブルが定義されているが、実装側がこの上限を動的に変更する指示（`SETTINGS_HEADER_TABLE_SIZE`）を適切にハンドリングしていない場合、サーバーは際限なくメモリを確保し続ける。
- インデックスの断片化: 大量のリクエストが同時にインデックスを更新しようとすると、メモリコントローラーがロックの競合に陥り、レスポンス時間が指数関数的に悪化する。
—
2. 実践的防御：リソース制限の「ガードレイル」設計
攻撃者は、プロトコルの仕様ギリギリのラインを突いてくる。だからこそ、サーバー設定では「安全なデフォルト」を疑い、厳格な境界を引く必要がある。
Nginxでの設定例
リバースプロキシとしてNginxを利用している場合、以下のパラメータが防衛の要となる。
http {
# 1. 動的テーブルのサイズ制限：デフォルトの4KBに固定し、攻撃者からの変更を拒否する
http2_max_header_size 16k; # ヘッダー全体の最大サイズ
# 2. サーバーが保持する動的テーブルのサイズ制限
# この値を小さくすることで、メモリ消費を強制的に抑える
http2_header_table_size 4k;
# 3. リクエストの同時並行性制限：一度に処理するストリームを制限し、Rapid Reset攻撃を緩和
http2_max_concurrent_streams 128;
# 4. タイムアウト設定：ヘッダーの読み込みに時間をかけさせる攻撃を防ぐ
client_header_timeout 5s;
}
アーキテクトへの助言：
単に値を小さくすれば良いというものではない。正当なクライアントの利便性を損なわないよう、`nginx_vts_exporter` 等のメトリクスツールで「ヘッダー処理時間」と「メモリ割り当て量」をベースライン化し、異常値を検知した瞬間にWAF層で当該セッションを遮断する自動応答を構築しておくべきだ。
—
3. 次世代の脅威：QPACKと耐量子暗号を見据えた監査
HTTP/3（QUIC）で採用されたQPACKは、HTTP/2の問題を克服するために「ストリームの順序性を保証しない」設計になっている。これは非同期処理を可能にするが、同時に「どのヘッダーがどの順序で解凍されるかを予測不能にする」という、新たな監査の難しさを生んでいる。
今後の防御戦略
1. プロトコル正規化（Normalization）:
WAFやロードバランサー層で一度パケットを分解・再構成し、ヘッダーの重複や異常な圧縮比率を持つセッションを排除する。
2. 耐量子暗号（PQC）への移行:
今後、HTTP/3の基盤であるQUICにおいて、TLS 1.3のハンドシェイクに量子耐性を持つアルゴリズム（Kyber等）が導入される。この際、計算コストの増大により、暗号化処理を狙ったDoS攻撃が再燃する可能性が高い。今のうちから、暗号化処理に特化したオフロードエンジン（ハードウェアアクセラレータ）の選定と、その負荷監視体制を整えておくべきだ。
—
最後に：防御は「疑うこと」から始まる
私がこれまで見てきた大規模インシデントの9割は、プロトコルの「標準機能」を過信した結果によるものだ。HPACKもQPACKも、便利であるがゆえに「サーバーが勝手にやってくれる」という甘えを誘発する。
エンジニアとして、常にパケットの断片を想像してほしい。そのヘッダー一つが、あなたのサーバーのメモリ上でどう展開され、どの程度のCPUサイクルを消費するのか。その想像力こそが、AI全盛の時代においても最強の防御壁となる。
最新のCVEを追うことも重要だが、自分の足元のプロトコルスタックがどのようなメモリ管理を行っているか、一度ソースコード（または実装のドキュメント）を深く掘り下げてみることを強く推奨する。それが、真の「プロフェッショナル」の仕事だ。
コメント