JWT の脆弱性.

JSON Web Token は認証・認可のクレームを運びますが、ヘッダーで宣言される署名アルゴリズムの柔軟さが、繰り返し現れるいくつかの脆弱性クラスを生み出してきました。alg=none バグは Tim McLean 氏が 2015 年に公表したもので、検証側がトークン自身の alg ヘッダーを信頼し、空の署名に対して true を返す「none」検証器へ処理を委ねてしまう場合に発生します。これにより攻撃者はペイロードを書き換えて署名を削除できます。この不具合は Node の jsonwebtoken の 4.2.2 より前のバージョンで修正されました(CVE-2015-9235)。

**鍵の取り違え(key confusion、CVE-2016-10555)**はより巧妙です。サーバーが RS256 と HS256 の両方を受理する場合、攻撃者はサーバーの 公開 RSA 鍵を共有秘密として HMAC でトークンを署名します。素朴な検証器はその公開鍵を HS256.verify() に渡してしまい、偽造が通ってしまいます。関連する問題として、hashcat でオフラインに解読可能な弱い HS256 秘密鍵、exp/nbf チェックの欠落、ヘッダーインジェクションのシンク(kid のパストラバーサルや SQL インジェクション)、そして攻撃者が所有する鍵を検証に指し示す攻撃者制御の jwk/jku/x5u フィールドなどがあります。2022 年には jsonwebtoken の CVE-2022-23529 が、細工した鍵オブジェクトを介した RCE の懸念を提起しました(後に、悪用の前提条件が争点となり撤回されました)。

対策としては、受理する署名アルゴリズムをサーバー側で固定し、信頼できない入力から alg を決して読み取らないこと、強い非対称鍵を使うこと、kid を許可リストと照合すること、埋め込まれた鍵 URL を無視すること、有効期限を強制すること、そしてすべての JWT フィールドを敵対的な入力として扱うことが挙げられます。

flowchart TD
  A[攻撃者が有効な JWT を入手] --> B{ヘッダーを改ざん}
  B -->|alg none、署名を削除| C[検証器は検査を省略?]
  B -->|RS256 を HS256 へ| D[公開鍵で HMAC]
  B -->|jku / kid が攻撃者の鍵を指す| E[不正な鍵で検証]
  C -->|Yes| F[偽造トークンが受理される]
  D -->|Yes| F
  E -->|Yes| F
  F --> G[権限昇格 / 認証バイパス]
  C -->|alg を固定| H[拒否]
  D -->|alg を固定| H
  E -->|kid を許可リスト化| H