「通信の効率化」が招く落とし穴：HTTP/2・HTTP/3のヘッダー圧縮攻撃からサーバーを守るには？
こんにちは。セキュリティの現場で日々、巧妙化する攻撃と対峙しているエンジニアです。
今日は、Webサイトを高速化するために導入された「HTTP/2」や「HTTP/3」という技術が、実は「泥棒に家の鍵の形を教えてしまうような弱点」を抱えているという話をします。「なんだか難しそう…」と思うかもしれませんが、大丈夫。身近な例えで、なぜこの攻撃が怖いのか、どうやって防げばいいのかを一緒に紐解いていきましょう。
そもそも「ヘッダー圧縮」って何？
Webサイトを読み込むとき、ブラウザとサーバーは「こんにちは、私はChromeです」「私はこのページを表示します」といった挨拶（ヘッダー情報）を何度もやり取りします。
HTTP/2やHTTP/3では、この挨拶を短縮して通信を速くする「ヘッダー圧縮（HPACK / QPACK）」という仕組みがあります。例えるなら、毎回「お世話になっております、株式会社〇〇の山田です」と言う代わりに、「あ、例の山田です」と短縮して効率を上げているようなものです。
しかし、攻撃者はこの「短縮ルール」を逆手に取ります。
泥棒が「合鍵」を大量生産する仕組み（圧縮攻撃）
この攻撃の恐ろしいところは、サーバーの「記憶力」を悪用することです。
1. 辞書を肥大化させる： 攻撃者は、わざと複雑で無意味なヘッダーを大量に送りつけます。サーバーは「またこの挨拶が来たな、辞書（記憶）に登録しておこう」と律儀に記録します。
2. リソースの枯渇： 攻撃者が何千回とこれを繰り返すと、サーバーのメモリ（記憶領域）がパンパンになり、処理しきれなくなってダウンしてしまいます。
これを「HTTP/2 Rapid Reset攻撃」や「圧縮爆弾（Compression Bomb）」と呼んだりします。家のドアに、偽の鍵を何万個も差し込んで鍵穴を壊してしまう、そんな卑劣な手口です。
どうやって身を守ればいいの？
対策はシンプルです。「一度に受け取る挨拶の量を制限する」こと。
セキュリティの世界では「リソースの制限」こそが最強の防壁です。
1. サーバー側での制限設定（Nginxの例）
例えば、Webサーバーの定番であるNginxでは、以下のように設定を追加することで、異常なサイズのヘッダーを受け付けないようにできます。
設定ファイル (nginx.confなど)
1. 一度に処理するヘッダーの最大サイズを制限する
大きすぎるヘッダーは「怪しい」とみなして遮断します
http2_max_header_size 16k;
2. サーバーが記憶するヘッダーの数を制限する
辞書が無限に膨らむのを防ぐためのガードレールです
http2_max_field_size 4k;
3. 接続ごとのリクエスト数に上限を設ける
一気に大量のリクエストを叩き込まれても耐えられるようにします
limit_conn_status 429;
limit_conn addr 50;
2. インフラ・WAFでの防御
自分でサーバーの設定をいじるのが怖い、あるいはクラウドを使っている場合は、WAF（Web Application Firewall）を活用しましょう。
CloudflareやAWS WAFなどのサービスは、こうしたプロトコルの脆弱性を先回りしてブロックしてくれるルールを持っています。「HTTP/2 Rapid Reset攻撃」のような最新の手口は、個人の努力で防ぐよりも、こうした専門家のゲートキーパーを玄関に置くのが一番の近道です。
「効率」と「リスク」のバランスを知ることが第一歩
新人の皆さんに覚えておいてほしいのは、「便利で速い技術には、必ずその裏側にリスクが隠れている」ということです。
HTTP/2やHTTP/3は素晴らしい技術ですが、デフォルト設定のままでは「誰でも入れる状態の玄関」かもしれません。今回紹介したような設定を見直し、「一度に受け入れる量に上限を設ける」という習慣を持つだけで、あなたのサーバーの防御力は劇的に向上します。
セキュリティは、一度設定して終わりではありません。まずは今動いているサーバーの構成を確認し、もし「制限なし」になっていたら、少しずつ「安全な幅」に設定を絞ってみてください。
一歩ずつ、一緒に強固なシステムを作っていきましょう！応援しています。
コメント