こんにちは！ネットワークの世界へようこそ。インフラ・プロトコルスペシャリストの私です。
日頃からWebサイトを見たり、アプリでメッセージを送受信したりするとき、私たちは当たり前のように「HTTP」という通信のルールを使っていますよね。前世代の「HTTP/1.1」に比べて、今の主役である「HTTP/2」は、何枚もの手紙を1つの封筒にまとめて同時に送るような「マルチプレクシング（多重化）」という凄技を使えるようになり、Webの表示速度が劇的に速くなりました。
でも、便利になった裏側には、新しいセキュリティの落とし穴が潜んでいるんです。今回は、HTTP/2のちょっとマニアック、だけど現場では絶対に知っておかなきゃいけない「偽のヘッダー攻撃」と、それに対する「堅牢な防御策」について、身近な例えを交えながら一緒に紐解いていきましょう！
一歩ずつ理解していけば全然難しくありません。さあ、パケットの旅に出発です！
—
1. 郵便配達で例える「HTTP/2のヘッダー」とセキュリティ
まずは、HTTPの「ヘッダー」がどんな役割をしているか、おなじみの郵便配達に例えてみましょう。
私たちがネットで何かを注文するとき、ブラウザ（あなた）はサーバー（お店）に向けて「このページを見せてくださいね」という手紙を送ります。この手紙には、本文だけでなく、「宛先はどこか」「どんなブラウザを使っているか」「ログインしている合言葉（Cookie）は何か」といった、いわば宛名書きや申し送り事項がたくさん書かれています。これが「ヘッダー」です。
HTTP/2では、このヘッダーを小さくコンパクトに折りたたんで送る「HPACK（エイチパック）」という圧縮技術が使われています。毎回同じような宛名書きを全部書くのは面倒だから、「前と同じ宛先ね」とコード番号で省略するようなイメージです。
ここに魔が差す悪意ある攻撃者が現れます…
悪意ある攻撃者は、この仕組みの隙を突こうとします。
例えば、わざとルール違反の巨大な荷物を送りつけたり、存在しない変な宛名（架空のヘッダーフィールド）を何百万通も送り込んだりして、お店の受付（Webサーバー）をパンクさせようとするのです。これが、今回お話しする「偽のヘッダー攻撃（ヘッダーインジェクションや過剰なリソース消費攻撃）」の正体です。
サーバーが「うわっ、なんだこれ！？」と処理に困っている間に、正当なお客さんの手紙が届かなくなってしまう。これがDoS攻撃（サービス妨害攻撃）と呼ばれるトラブルの現場で起きています。
—
2. 攻撃の正体：HTTP/2が抱える「HPACK」の罠
HTTP/2のヘッダー圧縮（HPACK）は、サーバーとブラウザの間で「これまでどんな言葉を使ったか」の辞書を共有しながら会話します。
ここに潜む危険な脆弱性のひとつが、「HPACKボム（HPACK Bomb）」と呼ばれるものです。
攻撃者は、ほんの数バイト（小さなお手紙）の中に、「このコード番号の意味は、実は1GBの文字列ですよ」というようなずる賢い圧縮データを仕込んでサーバーに送ります。
サーバー側は、それを律儀に元の大きなデータに引き伸ばそう（展開しよう）とします。するとどうなるでしょう？
サーバーのメモリ（作業机の上）が一瞬で巨大なデータで埋め尽くされ、プツンとフリーズしてしまうのです。身の回りで例えるなら、手のひらサイズの小さな段ボール箱を開けたら、中から無限に発泡スチロールがあふれ出てきて部屋が埋め尽くされてしまうような恐怖ですね。
—
3. 実務で備える！堅牢なセキュリティ対策と設定例
現場のネットワークエンジニアやインフラ担当者として、私たちはこうした攻撃からWebサーバーを守る義務があります。
最新のWebサーバー（NginxやApacheなど）やリバースプロキシ（CloudflareやAWSのALBなど）は、デフォルトでもかなり強力に守ってくれますが、実務では「しきい値（リミット）を適切にチューニングする」ことが極めて重要です。
ここでは、実務でよく使われる代表的なWebサーバーである Nginx を例に、具体的なセキュリティ設定のパラメーターを見てみましょう。
NginxにおけるHTTP/2ヘッダー制限の設定例
以下の設定をNginxの設定ファイル（`nginx.conf` など）に記述することで、不正に巨大なヘッダーやメモリを食いつぶす攻撃を防ぐことができます。
http {
# ==========================================
# HTTP/2 セキュリティ＆リソース制限設定
# ==========================================
# 1. 受け付けるヘッダーの最大サイズを制限する
# （大きすぎるヘッダーを送りつけてメモリを圧迫する攻撃を防ぎます）
large_client_header_buffers 4 16k; # 1つのバッファを16KB、合計4つまで許容
client_header_buffer_size 1k; # 通常のリクエストは1KB以内で十分収まる想定
# 2. HTTP/2特有のストリーム制御パラメータ
# ※Nginxのバージョンやモジュールに依存しますが、
# 過剰なリクエストストリームの同時オープンを防ぐ設定を行います。
# ユーザー（1つの接続）が同時に開けるストリーム数を制限
http2_max_concurrent_streams 128;
# HPACKで展開されたあとのヘッダー全体の最大サイズを制限（HPACKボム対策に極めて重要）
# （例：展開後に最大で 64KB を超えるヘッダーは強制切断する）
http2_max_header_size 64k;
}
💡 コードの解説
- `client_header_buffer_size 1k;`: 通常の正しいリクエストであれば、ヘッダーの最初の部分は1KB以内に収まります。ここを厳しく絞ることで、怪しい巨大な入力を早い段階で弾くことができます。
- `http2_max_header_size 64k;`: これがHPACKボム対策の防波堤です。圧縮されたデータがどれだけ小さくても、解凍したあとにこのサイズを超えていたら「怪しい！」と判断して通信を遮断します。
—
4. トラブルシューティング：現場で異常を検知したら？
もしあなたが運用しているWebサイトで、「なんだか最近、CPU使用率が跳ね上がってサーバーが重いぞ…？」と感じたら、それはHTTP/2の脆弱性を突いた攻撃を受けているサインかもしれません。
そんなときは、以下のステップで調査を進めましょう。
1. アクセスログの確認
- 通常とは異なる、やたらと長大なURLや、不自然に特殊文字が並んだリクエストヘッダーが大量に届いていないか確認します。
2. パケットキャプチャ（Wiresharkなど）での解析
- 暗号化（TLS）されている場合は直接見えませんが、ターミナル上で `curl` コマンドを使い、詳細な通信のやり取りをデバッグモードで確認してみます。
# HTTP/2でサーバーに接続し、ヘッダーのやり取りを詳細にデバッグ確認するコマンド
curl -Iv –http2 https://your-domain.example.com
3. WAF（Webアプリケーションファイアウォール）の導入
- アプリケーションの手前にWAF（AWS WAFやCloudflareなど）を挟むことで、HTTP/2の規格から外れた不正なフレーム構造や、怪しいパケットのパターンを自動で検知・ブロックしてくれます。自前だけで守るのが難しい現代のインフラでは、非常に心強い味方です。
—
まとめ
いかがでしたでしょうか？
HTTP/2の「マルチプレクシング」や「HPACKによるヘッダー圧縮」は、私たちのWeb体験を爆速にしてくれる素晴らしい技術です。しかし、その便利さの裏側には、悪意ある攻撃者が悪用できる隙も存在します。
大切なのは、
- 「大きな荷物や変な宛名の手紙は受け取らない（サイズ制限）」
- 「解凍したら部屋が埋め尽くされるような圧縮マジックには引っかからない（展開制限）」
という、現実世界のセキュリティ対策と同じ感覚をインフラ設計に持っておくことです。
難しそうに見えるネットワークの仕組みも、身近な例えに置き換えればスッと頭に入ってきますよね。これからも一緒に、安全で快適なネットワークの世界を楽しく学んでいきましょう！次の記事もお楽しみに！
コメント