【入門編】HTTP/2のセキュリティ脆弱性：HPACK圧縮爆弾 – HTTPプロトコル・通信規格実践ガイド

こんにちは！ネットワークの世界へようこそ。インフラ・プロトコルスペシャリストの私です。

日頃からWebサイトを閲覧していると、ページが一瞬で表示されるのが当たり前になっていますよね。「HTTP/2」という次世代の通信規格が裏側で頑張ってくれているおかげで、私たちはストレスなくネットサーフィンを楽しめています。

でも、この便利で高速なHTTP/2には、実はちょっとした「隠し部屋」のような仕組みがあり、そこを突いたちょっぴり怖いサイバー攻撃が存在するのです。その名も「HPACK（エイチパック）圧縮爆弾」。

名前からして何やら物騒ですが、安心してください。今回は、むずかしいパケットの数式や英語の呪文は一切なしで、身近な「郵便配達」の例えを使いながら、この脆弱性の正体と対策を一緒に優しく紐解いていきましょう。一歩ずつ理解していけば全然怖くありませんよ！

—

1. HTTP/2のスピードを支える「HPACK」ってなぁに？

まずは、HTTP/2がどうやって高速化を実現しているのかを軽くおさらいしておきましょう。

Webブラウザがサーバーに「この画像を見せて！」とお願いするとき、必ず「ヘッダー」という付箋のようなお供を一緒に送ります。この付箋には、「私のブラウザはChromeだよ」「言語は日本語だよ」といった細かい情報が書かれています。

HTTP/1.1の時代は、この付箋を毎回ぜーんぶ手書きで貼り直して送っていました。「毎回同じこと書くの面倒くさいなぁ…」ですよね。そこでHTTP/2では、「HPACK」という賢い圧縮の仕組みが導入されました。

郵便配達に例えてみよう！

想像してみてください。あなたは毎日、同じ宛先（サーバー）に手紙を出しています。

普通のやり方： 封筒のたびに「東京都〇〇区……」とフルネームと住所を長々と書き続ける。
HPACKのやり方（短縮コードの活用）： 最初だけ住所をしっかり書いて、配達員さんに「これからは『お客様番号：1番』ね！」と登録してもらう。2日目からは、封筒に「1番」とだけ書けば、配達員さんが「あ、あの人ね！」と脳内手帳（動的テーブル）から住所を引っ張り出して届けてくれる。

すごく効率的で頭のいい方法ですよね。この「短縮コードと脳内手帳」のコンビネーションのおかげで、通信するデータ量をグッと減らし、Webを爆速にしているのです。

—

2. そこで起きる事件：「圧縮爆弾」のトリック

さて、ここからが今回の本題です。この「便利な脳内手帳（動的テーブル）」の仕組みを、悪い奴らが悪用するのが「HPACK圧縮爆弾（別名：HTTP/2 Bomb）」と呼ばれる攻撃です。

彼らは一体どんな手口を使うのでしょうか？再び郵便配達の例えに戻りましょう。

1. 攻撃者の仕込み： 攻撃者は、ものすごく巧妙に作られた「極小の手紙」をサーバーに送ります。パケットの見た目は豆粒のように小さいです。
2. 脳内手帳の書き換え要求： その手紙の中身には、「これからは『コードA』を、この『10万文字の超巨大なゴミデータ』に書き換えて登録して！」という指示がこっそり仕込まれています。
3. 連続攻撃： そして、その「コードA」を何千回、何万回もリクエストのなかに詰め込んでサーバーに送りつけます。

サーバーの身になって考えてみよう

サーバーの郵便受け（メモリ）から見ると、届く手紙自体は「コードA、コードA、コードA……」と書かれた軽いペラペラの紙です。「なんだ、軽い手紙だな」と思って受け取ります。

しかし、サーバーが脳内手帳を開いた瞬間、悲劇が起きます。
「うわっ！『コードA』って、さっき10万文字のゴミデータだって登録させられたんだった！これを何万回も展開（解凍）しなきゃいけないの……！？」

サーバーは、受け取った時は数キロバイトしかなかったデータを、解凍した瞬間に何ギガバイトもの巨大な怪物に膨れ上がらせてしまいます。サーバーのメモリ（作業机）はあっという間にパンクし、処理しきれなくなってフリーズ（ダウン）してしまうのです。これが、HPACK圧縮爆弾の恐ろしい正体です。

—

3. なぜこの攻撃を防がないといけないのか？

インフラエンジニアやWebサーバーの管理者にとって、この攻撃を防ぐことは「サーバーの命を守る盾」を用意するようなものです。

対策を怠ると、たった1台の悪意あるパソコンから送られた小さなパケットのせいで、世界中のまっとうなユーザーがそのWebサイトにアクセスできなくなってしまいます（いわゆるDDoS攻撃の一種です）。

「じゃあ、どうやって防げばいいの？」
安心してください。現代のWebサーバーソフトウェア（NginxやApache、Go言語のHTTP/2ライブラリなど）には、この爆弾を不発弾にするための「安全装置」がちゃんと用意されています。

—

4. 実務で使える！メモリを守るための設定とパラメーター

ここからは、実際に現場のサーバーやプログラムで設定する防御策を見ていきましょう。難しく考えず、「サーバーに『これ以上大きな荷物は受け取れません！』というルールを貼る」イメージです。

① 動的テーブルのサイズ制限（上限を設ける）

HPACKの「脳内手帳」が際限なく大きくならないように、あらかじめ「ここまでね」と上限（リミット）を厳しく定めます。

② 最大ヘッダーサイズの制限

サーバーが一度に受け取るヘッダーの合計サイズに制限をかけ、怪物のような巨大データに膨らむ余地を与えません。

—

【実践】Go言語でのHTTP/2サーバー設定例

もしあなたがGo言語でWebアプリケーションや独自サーバーを構築しているなら、標準の`http.Server`で以下のように設定して、メモリを守る防壁を作ることができます。

package main

import (
“log”
“net/http”
“golang.org/x/net/http2”
)

func main() {
mux := http.NewServeMux()
mux.HandleFunc(“/”, func(w http.ResponseWriter, r http.Request) {
w.Write([]byte(“こんにちは！安全なHTTP/2の世界へようこそ！”))
})

server := &http.Server{
Addr: “:443”,
Handler: mux,
}

// HTTP/2の詳細な設定オブジェクトを作成します
h2Server := &http2.Server{
// 【重要】HPACKの動的テーブルが消費する最大メモリサイズを制限します
// デフォルトよりも小さく安全な値（例: 4KB）に絞ることで、圧縮爆弾の暴走を防ぎます
MaxDecoderHeaderTableSize: 4096,

// 1つのリクエストで許可するヘッダーの最大サイズ制限（例: 16KB）
MaxUploadBufferPerConnection: 1024 1024,
}

// HTTP/2機能をサーバーに有効化して紐付けます
http2.ConfigureServer(server, h2Server)

log.Println(“安全装置付きのHTTP/2サーバーを起動します (ポート: 443)…”)
// 実際の本番環境ではTLS（証明書）の設定も必要になります
// if err := server.ListenAndServeTLS(“server.crt”, “server.key”); err != nil {
// log.Fatalf(“サーバーエラー: %v”, err)
// }
}

このように、「脳内手帳の大きさに上限（`MaxDecoderHeaderTableSize`）を設ける」ことが、HPACK圧縮爆弾を防ぐための最もシンプルかつ強力な特効薬となります。

—

5. まとめ：安全で爆速なネットワークをつくるために

今回は、HTTP/2の便利すぎる裏側にある脆弱性「HPACK圧縮爆弾」について解説しました。

HTTP/2のHPACKは、短縮コードを使って通信を爆速にする賢い仕組み。
しかし、その仕組みを悪用して、小さなデータから巨大なメモリ消費を引き起こすのが「圧縮爆弾」。
対策として、動的テーブルのサイズ上限をきちんと設定し、サーバーのメモリを守ることがインフラエンジニアの重要な仕事。

インフラやネットワークの世界は、便利さの裏側にこうしたセキュリティの攻防が常に隠されています。でも、仕組みを一つひとつ紐解いていけば、決して恐ろしいものではありません。

「便利さの仕組みを知り、正しく守る」。この視点を持てば、あなたも立派なネットワーク・スペシャリストへの第一歩を踏み出しています。

それでは、また次回の技術の旅でお会いしましょう！安全で快適なネットワークライフを！