CVE-2023-48223 PoC（fast-jwt 算法混淆）

本仓库演示了当 token 验证未锁定允许的算法时，fast-jwt 中的 JWT 算法混淆问题。

环境搭建

环境要求

• Node.js 18 或更高版本
• npm
• OpenSSL（必须位于终端 PATH 中）

1) 安装依赖

在项目根目录下运行：

npm install

2) 生成 RSA 密钥

应用需要以下文件：

• keys/private.pem
• keys/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

3) 启动服务器

node server.js

预期输出：

Server running at http://localhost:3000

快速运行（PoC 流程）

1) 获取普通 token

curl http://localhost:3000/generateToken

2) 伪造管理员 token

node sign.js

复制打印出的 token。

3) 使用伪造的 token 调用管理员端点

node checkAdmin.js <JWT_TOKEN>

如果攻击成功，响应中会包含 Welcome Admin!。

为什么会存在漏洞

在 server.js 中，验证器没有限制算法：

const verifySync = createVerifier({
  key: publicKey,
});

由于没有算法白名单，服务器可能会接受使用公钥作为 HMAC 密钥签名的恶意 HS256 token。

解释如何模拟存在漏洞的库（用于纳入报告）

在我们团队的 CVE 演示中，存在漏洞的对象是库（无法独立运行），因此需要使用一个模拟应用程序来模拟实际系统调用该库 API 的方式。在本仓库中，server.js 文件就是模拟的应用层。

• 端点 /generateToken：该路由调用 fast-jwt 的 createSigner，使用 RS256 为普通用户（admin=false）生成合法 token，目的是创建一个“正常”的基线 token 用于与伪造 token 对比。
• 端点 /admin：该路由接收 Bearer token，然后调用 fast-jwt 的 createVerifier 验证 token，并根据 payload.admin 决定管理员权限。刻意构造的漏洞点在于验证器未锁定 algorithms，从而导致算法混淆。

补充的 PoC 代码流程：

• sign.js：模拟攻击者调用 createSigner，使用 HS256 并以公钥作为 secret 对伪造 token（admin=true）进行签名。
• checkAdmin.js：向 /admin 发送带有伪造 token 的请求，以证明服务器在存在漏洞的配置下会接受该伪造 token。

总之，我们团队没有重写该库的函数，只使用存在漏洞的库的原始 API（createSigner、createVerifier）在模拟应用内复现真实的利用场景。

修复方案

将验证限制为 RS256：

const verifySync = createVerifier({
  key: publicKey,
  algorithms: ["RS256"],
});

安全说明

本项目仅用于在受控实验室环境中进行安全学习。