エンジニア諸君、現場でのJWT（JSON Web Token）の扱いに「甘え」は禁物だ。
多くの開発者がJWTを単なる「便利なセッション管理ツール」だと誤解しているが、セキュリティの最前線から見れば、それは巨大なトラップになり得る爆弾だ。特に、「ペイロードが無限に膨らむ可能性がある」という仕様の盲点は、攻撃者にとって格好の踏み台となる。
今日は、JWTのサイズ制限を怠った結果、サーバーがメモリ枯渇（OOM）で沈む「JWT DoS攻撃」のメカニズムと、それを防ぐための鉄壁の防衛策を叩き込む。
—
1. なぜ「巨大なJWT」が脅威なのか
攻撃者は、JWTの構造がいかにしてパース（解析）されるかを熟知している。通常、JWTはBase64URLでエンコードされているが、サーバー側で検証を行う際、一旦デコードしてJSONオブジェクトに展開する。
ここで、攻撃者が数メガバイトに及ぶ巨大なペイロードを送りつけたとしよう。サーバーはそれを受け取り、メモリ上に展開し、さらに署名検証のために暗号演算（RSAやECDSA）を行う。
1. CPU資源の浪費: 巨大なトークンの署名検証は計算コストが跳ね上がる。
2. メモリの枯渇: 複数のリクエストが同時に巨大なペイロードを送りつければ、サーバーのメモリは瞬く間に食いつぶされ、Node.jsやPHPのプロセスは死亡する。
これが、「認証認可」の入り口で発生するDoS攻撃の正体だ。
—
2. 実務で守るべき「3層防衛ライン」
防御の基本は「境界線での拒否」だ。アプリケーションの奥深くまで不正なデータを入れさせてはならない。
防衛ライン①：Nginxで「入り口」を塞ぐ
アプリケーションコードに到達する前に、リクエストサイズで弾く。これが最も効率的だ。
# Nginxの設定ファイル (/etc/nginx/nginx.conf または site-enabled配下)
# Authorizationヘッダーに含まれるトークンは通常1KB〜4KB。
# 8KBを超えたら即座に413 Request Entity Too Largeを返す。
client_header_buffer_size 8k;
large_client_header_buffers 4 8k;防衛ライン②：アプリケーション層での厳格な検証（Node.js/Express例）
ライブラリ任せにするのではなく、パース前にサイズをチェックする。
const MAX_JWT_SIZE = 8192; // 8KBを上限とする
function secureAuthMiddleware(req, res, next) {
const authHeader = req.headers['authorization'];
if (!authHeader) return res.status(401).send('Unauthorized');
const token = authHeader.split(' ')[1]; // "Bearer <token>"
// トークン長をバイト単位でチェック
if (Buffer.byteLength(token, 'utf8') > MAX_JWT_SIZE) {
console.warn(`[Security Alert] 巨大なJWTを検知: ${token.length} bytes`);
return res.status(400).send('Bad Request: Token too large');
}
// ここで初めてjsonwebtoken等の検証ライブラリへ渡す
next();
}防衛ライン③：ライブラリの脆弱性を排除する
古いバージョンのライブラリを使っていると、パース時に例外を適切にキャッチできず、サーバーがクラッシュするケースがある。常に最新版へ追従し、検証処理は try-catch で囲むことが鉄則だ。
—
3. 暗号理論に基づく「正しい使い分け」の原則
JWTのサイズ問題と密接に関わるのが、署名アルゴリズムの選択だ。
- RSA（RS256など）: 鍵長が長く（2048bit以上推奨）、署名自体も大きくなりがちだ。頻繁な検証にはCPU負荷が高い。
- 楕円曲線暗号（ES256など）: 少ないビット数でRSAと同等の強度を保てる。署名サイズも小さいため、ネットワーク帯域とメモリ負荷の観点から、現代のマイクロサービスでは ES256（ECDSA with P-256） を強く推奨する。
「JWTには必要最小限のクレームのみを含める」
これがセキュリティの鉄則だ。データベースのプライマリキーや、必要以上のユーザー属性をJWTに詰め込むのは、トークンサイズを増大させるだけでなく、情報漏洩のリスクも高める。
—
現場のエンジニアへ：最後のアドバイス
私がこれまで見てきたインシデントの多くは、「機能実装」を優先するあまり、「制約条件」の設計を忘れた結果生まれたものだ。
- サイズ制限: 常に「想定される最大値」を定義し、それを超えるものは即座に捨てろ。
- ログの監視: 巨大なトークンを投げてくるIPアドレスをWAFやFail2Banで自動的にブロックする仕組みを作れ。
- 暗号の選定: 古いRSAへの執着を捨て、ECC（楕円曲線暗号）への移行を検討せよ。
システムは「正常なリクエスト」だけを処理するものではない。「悪意ある巨大なゴミ」が投げ込まれる前提で設計して初めて、真に堅牢なアーキテクトと言える。
今日のコードを明日すぐ反映させろ。それが、お前たちのサービスを守る第一歩だ。
コメント