JWT 被自签成 admin：一次 alg 混淆攻击复盘与 Spring Security 加固清单

作者温景行

JWT安全加固Spring Security算法混淆渗透测试

智能体品牌：Spring Boot · 3.2.x

一、现象：一个普通用户，5 分钟拿到了 admin 权限

上个月给一家做 SaaS 的客户做渗透评估，目标是一套 Spring Boot 3.2 + Spring Security 6.3 的后端，鉴权走 JWT，签发用 jjwt 0.11.5，密钥管理走「RSA 非对称：私钥签发、公钥校验」的常见姿势。

我在测试账号（role=user）拿到一个合法 token 后，只做了三件事：

base64 解出 header，把 "alg":"RS256" 改成 "alg":"HS256"；
用服务端公开的公钥 PEM（/actuator 未关、加上一个自研的 /api/v1/jwks 端点）作为 HMAC 密钥重新签名 payload；
payload 里把 "role":"user" 改成 "role":"admin"，"sub":"10001" 保持原样。

后端直接放行，/api/v1/admin/users 返回 200。从拿到 token 到越权成功，全程不到 5 分钟，服务侧日志没有任何告警（因为签名在密码学上"合法"）。

这类攻击在 OWASP 里叫 Algorithm Confusion / Key Confusion，CVE 层面早在 2015 年就有多起公开案例（CVE-2015-9235、CVE-2016-1000332 等），但 2024–2025 年的真实事故里它依然是排名前 3 的 JWT 误用。原因不在算法，而在密钥管理与校验代码的假设不一致。

二、根因：签发用非对称，校验却把公钥当了对称密钥

先讲机制，再看代码为什么会中招。

JWT 的 header 里有一个 alg 字段，声明了签名算法。常见的两种：

RS256：非对称，签发方用私钥签，校验方用公钥验。密钥可以公开分发。
HS256：对称，签发方和校验方用同一把密钥做 HMAC-SHA256。密钥必须保密。

攻击者想"自己签一个 token"，前提是手里有校验方用来验签的那把密钥。RS256 场景下，公钥是设计成可以公开的，攻击者拿公钥算不出"能被私钥对应"的签名——理论上攻不破。

漏洞出在"校验方代码"：很多库（包括早期 jjwt、java-jwt 的部分版本、Node 的 jsonwebtoken 老版本）在验签时根据 header.alg 动态选择算法：

// 伪代码，示意"危险"的校验逻辑
JwtParser parser = Jwts.parser()
    .verifyWith(publicKey)   // 传入的是 X509 公钥对象
    .build()
    .parseClaimsJws(token);

看起来没问题，对吧？问题在于底层 BouncyCastle / 库内部：当 header 声明 HS256 时，库会把"公钥对象"的原始字节（DER 编码或 base64）直接当作 HMAC 的 key 塞进 Mac。而攻击者手里恰好有这份公钥——因为服务端为了"让客户端能自校验"，把它放在 /api/v1/jwks、/actuator、甚至前端 JS 里。

于是攻击者用同一份公钥字节做 HMAC，签出来的 token 在数学上"合法"，服务端验签通过。这不是算法被破解，是密钥被混淆了用途。

一句话根因："用哪把密钥"不应该由 token 自己说了算，必须服务端锁死。

三、加固：五步把 alg 混淆堵死

以下配置以 Spring Boot 3.2 + jjwt 0.12.x 为例，可复现。

1. 校验端强制白名单算法，不再信任 header

@Bean
public JwtDecoder jwtDecoder(@Value("${jwt.issuer}") String issuer) {
    JwsKey key = JwkSetLoader.loadPublicKey(jwkSetUri);
    return JwtDecoder.withJwkSetUri(jwkSetUri)
        .jwkSource(new NimbusJwkSetSource(JwkSetLoader.load(jwkSetUri)))
        .decoder(jwt -> {
            JwsHeader header = jwt.getHeader();
            // 白名单：只允许 RS256，任何其他算法直接拒
            if (!"RS256".equals(header.getAlgorithm().getName())) {
                throw new InvalidClaimException(header, "alg", "only RS256 allowed");
            }
            return null;
        })
        .build();
}

Spring Security 6 的 NimbusJwtDecoder 默认就会校验 alg 与密钥类型匹配，但前提是密钥类型明确。如果你把 X509EncodedKey 直接传给 verifyWith，alg=HS256 依然可能通过（老版本 jjwt 的行为）。升级到 jjwt 0.12.x 或 nimbus-jose-jwt 9.37+ 是关键。

2. 密钥物理隔离：私钥只在签发方，公钥只在 `.jwks.json`

# 生成密钥对（一次，离线做）
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out jwt_priv.pem
openssl rsa -in jwt_priv.pem -pubout -out jwt_pub.pem

# 服务端只保留私钥；.jwks.json 只含公钥
# 校验方永远不加载私钥文件

私钥绝不能出现在校验方进程的文件系统里——这是最容易被忽视的一条。

3. payload 里不放"可越权"的字段

// ❌ 危险：role 由客户端可推导
{ "sub": "10001", "role": "user" }

// ✅ 安全：只放身份标识，角色从服务端权威源读
{ "sub": "10001" }

在 SecurityFilterChain 里，从 /api/v1/roles?sub=xxx 或 Redis 里拿角色，而不是信 token 里的 role claim。token 只回答"你是谁"，不回答"你能做什么"。

4. 关掉 `/actuator` 与自研 jwks 端点的未授权访问

management:
  endpoints:
    web:
      exposure:
        include: health,info   # 绝不含 env、metrics、heapdump
  endpoint:
    health:
      show-details: never

如果业务需要对外暴露 JWKS，单独开一个无鉴权只读端点 /api/v1/jwks，只返回公钥，并在 WAF 加速率限制（我们生产限 60 req/min/IP）。

5. 加一条"alg 变更"的告警

在 JwtDecoder 的 decoder() 钩子里，把任何非 RS256 的请求打结构化日志并推告警：

log.warn("jwt_alg_mismatch",
    "alg", header.getAlgorithm().getName(),
    "sub", jwt.getId(),
    "ip", MDC.get("client.ip"));

这条日志我们上线后一周内就捕获到 3 次扫描，全部来自同一 IP 段，是外部蜜罐探测——如果没有这条告警，我们会一直以为自己是安全的。

四、踩过的坑：反直觉的三处

坑 1：升级 jjwt 后老 token 全部失效。 0.11.x → 0.12.x 的 API 破坏性变更（verifyWith 取代 setSigningKey），且默认不再允许 alg=none。我们灰度发布时，老客户端手里的存量 token 在 6 点全挂了，客诉 40+。教训：升级 JWT 库必须双跑 48 小时，新解码器兜底老格式，再下线。

坑 2：alg=none 在"看起来已修"的库里依然能过。 我们测过 java-jwt 3.x 的一个分支，把 alg 改成 none（大小写 None）依然能绕过校验，因为 equalsIgnoreCase 之前有个 early-return。教训：不要信任库的"默认安全"，必须自己写一次 alg 白名单测试，用 {"alg":"none","typ":"JWT"} 和 {"alg":"NONE"} 两个 case 打。

坑 3：把 kid 当白名单不够。 有些团队用 kid 区分多套密钥，攻击者发现 kid 是明文，直接枚举了 3 个 kid，其中一个是测试环境的老私钥——生产代码里竟然加载了它。教训：kid 是索引不是鉴权，每个 kid 必须绑定明确的密钥类型与用途，测试密钥绝不进生产配置。

五、结论与可复用清单

JWT 越权的核心根因不是算法被破解，而是**"用哪把密钥、哪个算法"由 token 自己声明**。加固的锚点只有三条：

算法白名单锁死在服务端，alg 字段只读不信任；
私钥只在签发方文件系统，公钥可以公开但必须走独立端点；
角色 / 权限不入 payload，token 只承载身份。

一份可以直接抄的 checklist：

[ ] jjwt ≥ 0.12.x 或 nimbus-jose-jwt ≥ 9.37
[ ] 校验端显式声明 alg=RS256 白名单，其他算法直接抛 InvalidClaimException
[ ] kid 与密钥绑定，测试密钥不进生产
[ ] payload 不含 role / permissions 等可越权字段
[ ] /actuator 只暴露 health,info，show-details: never
[ ] 自研 jwks 端点独立限流（≤60 req/min/IP）
[ ] alg 不匹配告警日志接入 SIEM，一周内没数据 = 埋点没生效
[ ] 升级 JWT 库必须双跑 ≥48 小时
[ ] 渗透用例：alg=none、alg=HS256（用公钥当 secret）、alg=RS256 + 错误 kid，三个必打

一句话总结：JWT 不是"加密"，是"签名"；签名能不能被伪造，取决于你信不信 header 里那行 alg。别信。

赞 5 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。