JWT 算法混淆攻击：你以为签名了，其实没签
JWT 在 Web 认证里几乎是标配了，但很多人只关心"token 能不能解析"，很少仔细看 header 里那个
攻击的逻辑很直白。服务器本来用 RS256（非对称，私钥签名、公钥验证）发 token。攻击者拿到一个合法 token，把 header 的
这不是理论漏洞，真实世界里多次出现过。最容易踩坑的场景是：JWT 库默认接受多种算法、不做白名单限制；或者开发者把公钥和 HMAC 密钥存在同一个配置字段里，验证逻辑根据 header 自动切换。一旦切换逻辑没加约束，攻击者就能"指定算法"来完成绕过。
修复方式其实很简单：验证端硬编码只接受你期望的算法，比如只允许 RS256，收到 HS256 直接拒绝。不要让 token 自己决定怎么被验证——签名方案是服务端的安全决策，不是客户端的声明。
JWT 在 Web 认证里几乎是标配了，但很多人只关心"token 能不能解析"，很少仔细看 header 里那个
alg 字段到底意味着什么。这个字段告诉验证方用什么算法校验签名——问题就在这里，验证方信任了 JWT 自己声明的算法。攻击的逻辑很直白。服务器本来用 RS256（非对称，私钥签名、公钥验证）发 token。攻击者拿到一个合法 token，把 header 的
alg 改成 HS256（对称，同一密钥既签名又验证），然后把原来用作验证的公钥当成 HMAC 密钥，重新签名整个 token。服务器收到后看到 alg: HS256，就拿公钥去做 HMAC 验证——签名自然通过，因为攻击者用的就是同一个公钥。于是一个完全伪造的 token 被当作合法 token 接受了。这不是理论漏洞，真实世界里多次出现过。最容易踩坑的场景是：JWT 库默认接受多种算法、不做白名单限制；或者开发者把公钥和 HMAC 密钥存在同一个配置字段里，验证逻辑根据 header 自动切换。一旦切换逻辑没加约束，攻击者就能"指定算法"来完成绕过。
修复方式其实很简单：验证端硬编码只接受你期望的算法，比如只允许 RS256，收到 HS256 直接拒绝。不要让 token 自己决定怎么被验证——签名方案是服务端的安全决策，不是客户端的声明。
