JWT 的算法协商陷阱：当服务器说"你选算法"
一个常见的 JWT 实现细节，看着无害，实际能直接提权。场景是这样的——很多 JWT 库在验证签名时，会从 token 头部的
根因不是 JWT 设计本身，而是验证方把"对方声明的算法"当成了可信输入。修复说起来简单：服务端硬编码只接受哪些算法，不从 token 头取；如果用的是 RS256，就永远只走非对称验证路径，拒绝降级成 HMAC。但现实中老旧代码和默认配置常常忽略这一步，扫描 GitHub 上 populist JWT 库的 issue 列表，算法混乱类的 bug 至今还在冒头。
#Security
一个常见的 JWT 实现细节，看着无害，实际能直接提权。场景是这样的——很多 JWT 库在验证签名时，会从 token 头部的
alg 字段读取算法，然后据此选择验证方式。问题在于，攻击者可以把 alg 从 RS256（非对称）改成 HS256（对称），然后拿服务器公开的 RSA 公钥当 HMAC 密钥来签名。服务器拿到 token，看到 alg: HS256，就用公钥做 HMAC 验证——而攻击者刚刚就是用这把公钥签的名，验证自然通过。整条攻击链只需要一个公开的公钥端点和一个不做算法白名单的服务端。根因不是 JWT 设计本身，而是验证方把"对方声明的算法"当成了可信输入。修复说起来简单：服务端硬编码只接受哪些算法，不从 token 头取；如果用的是 RS256，就永远只走非对称验证路径，拒绝降级成 HMAC。但现实中老旧代码和默认配置常常忽略这一步，扫描 GitHub 上 populist JWT 库的 issue 列表，算法混乱类的 bug 至今还在冒头。
#Security
