lucastran05/cve-2023-48223Proof-of-conceptで、fast-jwtライブラリにおけるJWTアルゴリズム混乱を実証します。脆弱なサーバー、トークン偽造スクリプト、およびセキュリティ教育用の検証修正が含まれています。
このリポジトリは、トークン検証時に許可されたアルゴリズムをロックしていない fast-jwt における JWT アルゴリズム混乱（algorithm confusion）を実演します。
プロジェクトのルートから次を実行してください:
npm install
このアプリは次のファイルを必要とします:
keys/private.pemkeys/public.pem次のいずれかのコマンドセットを実行してください。
PowerShell（Windows）:
New-Item -ItemType Directory -Path keys -Force | Out-Null
openssl genrsa -out keys/private.pem 2048
openssl rsa -in keys/private.pem -RSAPublicKey_out -out keys/public.pem
Linux/macOS/Git Bash:
mkdir -p keys
openssl genrsa -out keys/private.pem 2048
openssl rsa -in keys/private.pem -RSAPublicKey_out -out keys/public.pem
node server.js
想定される出力:
Server running at http://localhost:3000
curl http://localhost:3000/generateToken
node sign.js
出力されたトークンをコピーします。
node checkAdmin.js <JWT_TOKEN>
攻撃が成功すると、レスポンスに Welcome Admin! が含まれます。
server.js では、検証側がアルゴリズムを制限していません:
const verifySync = createVerifier({
key: publicKey,
});
アルゴリズムの許可リストがないため、サーバーは公開鍵を HMAC シークレットとして署名された悪意のある HS256 トークンを受け入れる可能性があります。
チームの CVE デモでは、脆弱な対象はライブラリであり（単独では実行できません）。そのため、実際のシステムがそのライブラリの API を呼び出す方法を模倣するために、模擬アプリケーションを使用する必要があります。このリポジトリでは、server.js が模擬アプリケーション層です。
補助的な PoC コードフロー:
要約すると、チームはライブラリの関数を書き直していません。脆弱なライブラリの元の API（createSigner、createVerifier）を模擬アプリケーション内で使用して、悪用シナリオを正確に再現しているだけです。
検証を RS256 のみに制限します:
const verifySync = createVerifier({
key: publicKey,
algorithms: ["RS256"],
});
このプロジェクトは、管理されたラボ環境でのセキュリティ学習のみを目的としています。