JWTの「なんとなく」を捨て去れ：HS256からの脱却と署名検証の深淵
多くのテックリードが「JWTを使っているから認証は安全だ」と口にする。だが、インシデント対応の最前線にいる我々から見れば、そのJWT実装の多くは「鍵のかかっていない玄関」に等しい。
JWT（JSON Web Token）は、その柔軟性ゆえに、実装者の知識の欠如を鋭く突く設計上の脆弱性を内包している。今回は、HS256という「対称鍵の沼」から脱出し、RS256/ES256という「非対称鍵の堅牢性」へ移行するための、アーキテクト視点での防衛ロジックを解剖する。
—
1. 脆弱性の温床：なぜHS256が「負け戦」なのか
HS256（HMAC with SHA-256）は、共有秘密鍵を使用する。この設計の最大の問題は、「トークンを発行する側と検証する側が、完全に同じ鍵を共有しなければならない」という一点に尽きる。
マイクロサービス環境において、認証サービスとリソースサーバーが同じ秘密鍵を保持している現状を想像してほしい。リソースサーバーが一つでも侵害されれば、攻撃者は即座に署名鍵を奪取し、あらゆるユーザーになりすます権限を手に入れる。
さらに、alg: none 攻撃や、鍵の強度が低い場合のブルートフォース攻撃が、この「共有」という構造の脆さを常に狙っている。我々が行うペネトレーションテストでは、HS256を使っているサービスを見つけると、まずそのメモリダンプやコンフィグファイルから鍵を抽出する作業を優先する。防衛側としては、この「鍵の配布」というリスクそのものを排除しなければならない。
—
2. RS256/ES256への移行：公開鍵インフラの強制
RS256（RSA Signature with SHA-256）やES256（ECDSA using P-256）へ移行する最大のメリットは、「検証側に秘密鍵を渡す必要がない」ことだ。
リソースサーバーは公開鍵のみを保持し、署名の検証を行う。万が一リソースサーバーが踏み台にされても、トークンの偽造は不可能だ。また、量子コンピュータの台頭を見据えるなら、RSAよりも効率的で鍵長に対して高い耐性を持つES256（楕円曲線暗号）へのシフトを推奨する。
実装における検証ロジックの要諦
多くの開発者が陥る罠は、JWTライブラリを使いながら「alg ヘッダを検証していない」ことだ。以下のGo言語による実装例を見てほしい。
import (
“github.com/golang-jwt/jwt/v5”
)
func ValidateToken(tokenString string, publicKey interface{}) (jwt.Token, error) {
return jwt.Parse(tokenString, func(token jwt.Token) (interface{}, error) {
// 1. アルゴリズムの厳格な固定 (HS256を排除)
// 攻撃者がヘッダを書き換えて ‘alg: none’ や ‘HS256’ を送り込んでもここで弾く
if _, ok := token.Method.(jwt.SigningMethodECDSA); !ok {
return nil, fmt.Errorf(“予期せぬ署名アルゴリズム: %v”, token.Header[“alg”])
}
// 2. 公開鍵のみを返却
return publicKey, nil
})
}
このコードの肝は、token.Method の型を明示的にチェックしている点だ。ここで SigningMethodECDSA 以外を拒絶することで、alg ヘッダを介した注入攻撃（Type Confusion）を根絶できる。
—
3. 生成AI時代のガードレイル：署名検証の先にあるもの
昨今、LLMを利用したアプリケーションにおいて、JWTの検証ロジックをプロンプトインジェクションの踏み台にされるケースが出てきている。例えば、AIエージェントが外部APIを呼び出す際、トークンが適切にスコープ制限されていないと、エージェントが持つ権限を悪用して機密データが抽出される。
アーキテクトが打つべき一手
1. JTI (JWT ID) の追跡: トークンの一意性を保証する jti クレームをRedis等の高速なKVSで管理し、リプレイ攻撃を防ぐ。
2. KID (Key ID) のローテーション: 鍵を固定せず、ヘッダの kid を見て適切な公開鍵をJWKS (JSON Web Key Set) エンドポイントから動的に取得する。これにより、鍵漏洩時のリカバリ（無効化）を即座に行える。
3. 量子耐性への備え: 現在のES256は量子コンピュータに対して脆弱である。将来的な耐量子暗号（PQC）アルゴリズムへのアップデートを考慮し、アプリケーションの認証層を疎結合に設計しておくことが、真のプロフェッショナルとしての「備え」だ。
—
結びに：セキュリティは「仕様」ではなく「思考」である
JWTの脆弱性は、アルゴリズムの仕様そのものよりも、「開発者がその裏にある暗号学的制約を理解せず、ライブラリのデフォルト値に依存する」という怠慢から生まれる。
署名アルゴリズムをES256へ移行し、検証ロジックを厳格化することは、あくまでスタートラインだ。あなたのシステムが、攻撃者にとって「解くのにコストがかかりすぎる難問」であり続けるために、今日からコードの alg チェックを再確認してほしい。
セキュリティバイブルの主筆として断言する。技術的負債を放置したままの「便利さ」は、必ず将来の惨事という利息を伴って帰ってくる。今すぐ、その鍵を公開鍵へ切り替えろ。
コメント