JWTの脆弱性：alg=noneと鍵の取り違え

JWTは暗号学的に署名されていますが、多くのライブラリに深刻な脆弱性がありました。最も多く悪用されたのは、alg=none攻撃、RS256→HS256の混同攻撃、弱いシークレットの総当たり攻撃です。これらはすべて、攻撃者が制御できるヘッダーフィールドを信頼することに起因します。

JWT仕様では、保護されていないトークンにalg:"none"を指定できます。脆弱なライブラリはこれを受け入れ、署名検証を完全に省略していました。攻撃者はペイロード（例: "role":"admin"）を変更し、alg:"none"を設定して署名を削除すると、サーバーに受け入れさせることができます。

元のトークン: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyIn0.SIG 攻撃: eyJhbGciOiJub25lIn0.eyJzdWIiOiJhZG1pbiJ9. （空の署名、末尾のドット）。脆弱なサーバーは検証に成功し、管理者アクセスを許可します。

本番環境ではalg:"none"を決して受け入れないでください。許可するアルゴリズムを明示的にホワイトリストへ登録してください: jwt.decode(token, key, algorithms=["HS256"])。最新のライブラリの多く（PyJWT 2+、jsonwebtoken 9+）は、デフォルトでalg=noneを拒否します。

サーバーがRS256を使用していて、クライアントがalgをHS256に変更すると、サーバーはRSA公開鍵をHMACシークレットとして使って検証する可能性があります。公開鍵はその名のとおり公開されているため、攻撃者はその鍵で任意のペイロードに署名でき、サーバーはそれを検証してしまいます。

手順: 1) JWKSエンドポイントから公開鍵を取得します。2) 悪意のあるペイロードを作成します。3) 公開鍵の生のPEMバイト列をHMACシークレットとして、HMAC-SHA256で署名します。4) ヘッダーにalg:"HS256"を設定します。5) サーバーのHS256処理で検証が成功します。

検証呼び出しでは、想定するアルゴリズムを必ず明示的に指定してください。トークンヘッダーからアルゴリズムを決定しないでください。RS256とHS256には、呼び出し元が切り替えられない別々のコードパスを使用してください。

エントロピーが256ビット未満の弱いシークレットを使うHS256は、オフラインで総当たり攻撃を受ける可能性があります。hashcatなどのツールはJWTのクラッキングに対応しています: hashcat -a 0 -m 16500 token.txt wordlist.txt。少なくとも32バイトの暗号学的にランダムなシークレットを使用してください。

kid（鍵ID）ヘッダーは、使用する鍵を選択します。サーバーがkidをサニタイズせずにSQLクエリパラメータやファイルシステムパスとして使用すると、kid="../../dev/null" → 空の鍵を使ったHMAC → 偽造トークンが受け入れられる、という事態が起こります。kidは必ずサニタイズしてください。

jwkヘッダーには、検証用の公開鍵を埋め込めます。脆弱なサーバーは埋め込まれた鍵をそのまま使用してしまう可能性があり、攻撃者は自分の鍵ペアを指定し、秘密鍵でトークンに署名して公開鍵を埋め込めます。検証には登録済みの鍵だけを使用してください。

実装によっては、expクレームのチェックを忘れていたり、サーバー時刻を一貫性なく扱っていたりします。exp、nbf、iatは必ず明示的に検証してください。これらをデフォルトでチェックするライブラリを使用し、本番環境ではクレームの検証を決して無効にしないでください。

RS256→HS256の鍵混同攻撃で、攻撃者は何をHMACシークレットとして使用しますか。

JWTの脆弱性は、algヘッダーを信頼すること、alg=noneを受け入れること、弱いシークレットから生じます。対策は、検証側でアルゴリズムを固定し、強力なシークレットを使用し、kidをサニタイズすることです。次は、安全なJWT実装の実践について学びます。