JWT 安全

结构与常见误用

JWT 由 Header.Payload.Signature 三段 Base64url 编码拼接而成，本身不加密（仅 JWE 才加密），所以 Payload 中的内容任何人都能解码查看。开发者把敏感信息（如密码、内部 IP）放进 Payload 是第一类常见错误。

算法混淆攻击（Algorithm Confusion）：2015 年，安全研究员 Tim McLean 披露了 none 算法漏洞——JWT 规范允许 alg 字段设为 none 表示「不签名」，许多早期库直接接受该值，攻击者只需把 Header 改为 {"alg":"none"} 并删掉签名段即可伪造任意 Token。同年发现的 RS256→HS256 混淆攻击同样危险：服务器用 RSA 公钥验证 HMAC 签名时，由于公钥是公开的，攻击者可以用它作为 HMAC 密钥自签 Token。

弱密钥：HS256 的安全性完全依赖密钥长度和随机性。「secret」「password」「123456」等弱密钥可在数秒内被 hashcat 爆破。[1]

正确使用姿势

防御算法混淆的根本方法是在验证端硬编码允许的算法，而不是读取 Token 自带的 alg 字段。主流库从 2016 年前后陆续修复了自动信任 alg 字段的问题，但仍需开发者在初始化时显式指定。

Token 不应存入 localStorage（易被 XSS 脚本读取），推荐存入 HttpOnly Cookie，同时加 SameSite=Strict 或 Lax 抵御 CSRF。服务端需维护已撤销 Token 的黑名单或改用短有效期（15 分钟）配合刷新 Token 机制。HS256 密钥长度不应低于 256 位，并通过密码安全随机数生成器产生。

2022 年，CVE-2022-21449（「Psychic Signatures」漏洞）揭示 Java 15-17 的 ECDSA 实现允许任意签名通过验证，影响所有使用 ES256/ES384/ES512 算法的 JWT，是近年 JWT 生态最严重的供应链级漏洞。