JWT 校验缺陷的利用链：三个前置条件与最小验证

服务端必须固定算法白名单，否则 header 里的 alg 由持令牌的人决定用哪种方式验签

这篇只讲机制与验证思路，所有测试都应该在授权范围内、对自己的环境做。

先说结论

三个条件全满足才是高危；只有一两个，多半是「理论上可以」。

• 条件一：入口可达（能碰到）
• 条件二：校验可绕（能通过）
• 条件三：影响可证（能造成后果）
• 验证：用无害 payload 证明，不落地
• 修复：堵住入口或加严校验，二选一

条件一：入口可达

服务端必须固定算法白名单，否则 header 里的 alg 由持令牌的人决定用哪种方式验签。

先确认这个入口是否对外、是否需要登录、是否有网关拦截。很多「漏洞」死在第一步。

条件二：校验可绕

HS256 与 RS256 混用且不校验算法时，公开的验签公钥会被当作 HMAC 的密钥使用。

校验的常见问题是「只做一次」和「只做黑名单」，绕过思路通常来自这两点。

条件三：影响可证

exp、nbf、aud、iss 四项要逐条校验，漏掉 aud 会让别的服务的令牌在本服务通用。

这个问题的几个已知事实

公开资料里比较确定的几条：

• 改密与登出不会让已签发的 JWT 立刻失效，除非维护令牌版本号或一份短期黑名单

验证方法（无害）

用能证明问题存在的最小动作，不读取真实数据、不写入、不横向。

修复思路

把 kid 直接拼进文件路径或 JWKS 地址，等于把「取哪把密钥」的决定权交给令牌，应改成按可信列表查表。

修完必须回归：同一入口的其它路径、同一参数在其它接口、以及历史数据的兼容。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• JWT 的 payload 只是 Base64URL 编码，不加密，任何人拿到令牌都能读出全部字段
• 只解 payload 取 user_id 就放行，签名压根没验
• 用框架默认解码函数，没关掉 alg=none 与算法混淆
• 把签名密钥写在前端或镜像里，轮换时只能全量下线

能证明「三个条件都成立」，比能打穿更重要。