JWT Token 漏洞
整理 JWT 结构、签名校验问题、常见风险与防御建议。
1. 敏感信息泄露
JSON Web Token（JWT）由三部分组成：Header（头部）、Payload（载荷）和 Signature（签名）。其中，Header 和 Payload 仅使用 Base64Url 编码，并未加密。因此，若将敏感信息（如密码、密钥、个人身份信息等）直接存放在 Token 中，可能导致信息泄露。
建议：避免在 Token 中存储任何敏感信息。必要时可对 Payload 进行加密处理，或仅使用 Token 作为索引，将敏感数据存储在服务端。
2. 无签名漏洞（None Algorithm）
某些 JWT 实现支持将签名算法设置为 none，即不进行签名验证。攻击者可通过修改 Token 头部中的 alg 字段为 none，并随意篡改 Payload 内容，构造一个“合法”的 Token 绕过验证。
防护措施：服务端应明确禁用
none算法，并对所有接收到的 Token 进行严格的签名验证。
3. 弱密钥爆破
若 JWT 使用的密钥强度不足（如常用词、短密钥等），攻击者可能通过暴力破解或字典攻击方式猜解密钥，进而伪造有效 Token。
常用工具：
可使用 c-jwt-cracker 进行密钥爆破尝试：
git clone https://github.com/brendan-rius/c-jwt-cracker.git
cd c-jwt-cracker
make
./jwtcracker <token>
建议：使用足够长度和复杂度的密钥，并定期更换。推荐使用系统生成的随机字符串作为密钥。
4. 算法混淆攻击（Algorithm Confusion）
该漏洞源于验证方盲目信任 Token 头部中指定的算法。典型攻击流程如下：
- 攻击者获取一个使用 RS256（非对称加密）签名的 Token；
- 将头部中的
alg改为HS256（对称加密）； - 篡改 Payload 后，使用目标的公钥（作为 HMAC 的密钥）生成签名；
- 服务端收到 Token 后，使用公钥作为密钥验证签名，由于签名本身由公钥生成，验证通过。
注意：复现时需将公钥保存为文件后再用于签名，直接复制字符串可能导致格式错误。
防护措施：在验证 Token 时，应强制指定预期使用的算法，而非依赖 Token 头部中的
alg字段。
5. 其他常见问题与建议
| 漏洞类型 | 防护建议 |
|---|---|
| Token 泄露 | 使用 HTTPS、设置较短的有效期、启用 Token 黑名单 |
| 密钥管理不当 | 密钥隔离存储、定期更换、避免硬编码 |
| 未验证签名 | 在所有接收 Token 的地方进行签名验证 |
| Payload 解析错误 | 使用标准库解析、避免手动解码 Base64 |
总结
JWT 作为一种广泛使用的身份验证机制，其安全性高度依赖于实现方式。开发人员应遵循最佳实践，避免常见漏洞，并使用可靠的库进行处理。定期进行安全审计和渗透测试也是保障系统安全的有效手段。