JWTの「none」アルゴリズムという悪夢：検証ロジックを「性善説」で書くエンジニアへ
認証プロトコル、特にJWT（JSON Web Token）を実装する際、多くのエンジニアが陥る「盲点」がある。それは、トークンの署名を検証するライブラリのデフォルト設定を鵜呑みにし、アルゴリズムの固定という基本的な防御策を疎かにすることだ。
かつてCVE-2015-2951やその後の類似した脆弱性で世界中のサーバーを震撼させた「none」アルゴリズム問題は、単なるバグではない。これは、仕様の柔軟性が生む「セキュリティの陥穽」そのものだ。
「none」脆弱性の本質：プロトコルが許容した「なりすまし」
JWTの構造は単純だ。`Header`, `Payload`, `Signature`の3つがドットで連結されている。攻撃者は、このHeader内の`alg`フィールドを`none`に書き換え、PayloadのユーザーIDを`admin`に変更する。
もしバックエンド側で、ライブラリの`verify()`関数を引数なしで呼び出していたらどうなるか。多くのライブラリは、Headerの`alg`を動的に読み取り、それが`none`であれば「署名は不要」と判断するよう設計されていた。結果、攻撃者は秘密鍵を知らずとも、認証を完全にバイパスして管理者権限を奪取できる。
これは、プロトコルレベルの仕様が「多様なユースケースへの対応」を優先した結果、「検証者が署名の有無を信頼の起点にしてしまう」という設計の欠陥である。
アーキテクトが打つべき「アルゴリズム固定」の防衛線
開発現場でこの攻撃を封じ込める唯一の解は、「受信側でアルゴリズムをハードコードする」ことだ。ライブラリに「このエンドポイントではHS256以外は受け付けない」と明示的に命令せねばならない。
以下は、Node.jsの`jsonwebtoken`ライブラリを使用した実務的な実装例である。
const jwt = require(‘jsonwebtoken’);
// 悪例：アルゴリズムを指定せず、ヘッダーに依存する（攻撃者に主導権を渡す）
// const decoded = jwt.verify(token, secretKey);
// 推奨：アルゴリズムを強制的に固定する
try {
const decoded = jwt.verify(token, secretKey, {
algorithms: [‘HS256’] // ここで指定したアルゴリズム以外を拒否する
});
console.log(“検証成功:”, decoded);
} catch (err) {
// 署名不一致やアルゴリズム不一致はここで確実にハンドリングする
console.error(“セキュリティ違反の可能性があるトークン:”, err.message);
}
この一行の記述が、サーバーの防壁を「ザル」から「要塞」に変える。
生成AI時代に求められる「防御層の多層化」
現在のセキュリティ設計は、単なるコード実装に留まらない。最近では、LLM（大規模言語モデル）を組み込んだアプリケーションがJWTを生成・解釈するケースが増えている。もしLLMがプロンプトインジェクションによって不正なPayloadを構築し、それが署名検証を通過してしまったらどうなるか？
アーキテクトとして意識すべきは、JWTの検証は「境界防御の第一歩」に過ぎないという視点だ。
1. 署名の強制固定: `algorithms`オプションのホワイトリスト運用。
2. 鍵の分離: 認証用秘密鍵と、その他の用途で使用する鍵は物理的に分離し、HS256ではなくRSA（RS256）やECDSA（ES256）への移行を検討する。
3. トークンの無効化: JWTはステートレスゆえに、一度流出すれば失効が困難だ。JTI（JWT ID）を用いたブラックリスト運用や、短命なトークン発行（Access Token + Refresh Token）のスキームを徹底せよ。
最後に：ホワイトハッカーからの警告
「ライブラリのドキュメントを読めば書いてあることだろう」と思うかもしれない。しかし、筆者が国内外の監査で目にするインシデントの多くは、こうした「仕様の隅にある落とし穴」を無視した、ベテランによる実装の綻びに起因している。
JWTの脆弱性は、攻撃者がサーバーのメモリ内部を覗き込む必要すらなく、ただパケット構造を書き換えるだけで成立する「安直だが致命的な攻撃」だ。
あなたが書くコードは、単なる機能実装ではない。それは、何万というユーザーの機密情報を守るための「防衛ライン」そのものだ。アルゴリズムを固定し、プロトコルの挙動を制御下に置く。その泥臭い執着こそが、真のエンジニアリングにおけるセキュリティの第一歩である。
コメント