JWT伪造怎么选？手把手教你避开那些坑，别让黑客钻了空子！
哎，说到JWT伪造，我先叹口气……兄弟们，我是真的吃过亏！以前总以为JWT就是签个名的事，谁还能伪造不成？结果被现实狠狠打脸——项目上线没两周，测试环境就被塞进来一个伪造的admin token，差点把用户数据全给我抖搂出去，吓得我连夜改代码，所以今天咱们就唠唠， JWT伪造怎么选 防护方案，把我的血泪经验全盘托出,你可别走我老路了！
先搞懂，JWT到底是咋被“伪造”的？
很多朋友一听到伪造就懵，心想JWT不是有签名吗？怎么还能伪造呢？嘿，问题恰恰出在“怎么选”签名算法上！
你看，JWT的Header里有个 alg 字段，用来告诉服务器“我用的是HS256还是RS256”。关键坑点来了——有些服务器代码是这么写的：拿到token先不校验算法，直接拿 alg 字段去解密和验签，那黑客就乐坏了，他把 alg 改成 "none"，或者改成对称算法HS256，然后用服务器公钥（如果是非对称算法泄露的话）甚至随便一个字符串去签名……你说说，这哪是JWT不安全？这是你自己选了不安全的校验方式啊！
伪造怎么选？选对算法是关键中的关键！
咱们既然谈“JWT伪造怎么选”，重点就在选算法上，我的建议是，闭眼直接用 RS256（非对称加密）,别纠结。
为啥？HS256是对称加密，你签发token的密钥和校验token的密钥是同一个，一旦你前端打包的代码或者配置里泄露了这个密钥（这种情况不少见，尤其是GitHub上不小心传上去的），黑客就能用同一个密钥随便签发token，那叫一个舒服！而我选RS256，私钥藏服务器后端签名，公钥发给网关或微服务验签，即使公钥被拿走，也只能验签无法伪造签名,这就安全一大截了。
但别忘了，还有一步更重要的选择： 在代码里，一定要显式限定允许的算法列表，列成白名单！比如只允许RS256，其他一律拒绝，你想想，如果你的校验代码写的是“只要签名能过就算数”，那黑客用个HS256拿你的公钥当密钥签名，服务器如果误信了公钥做对称校验，岂不是直接被穿成筛子？JWT伪造怎么选答案很简单：选RS256，并且把 alg 固定死！
除了算法，还有几个点你必须查一遍！
讲真，光选对算法还不够，我那次的漏洞其实还出在别的地方,你听我说：
-
过期时间别设太长！ 我那时图省事，给token设了7天有效期，结果黑客拿到一个泄露的token硬生生用了5天，后台日志都炸了，你说气人不气人？建议设15分钟到一个小时，配合refresh token（刷新令牌）使用，虽然麻烦点,但至少安全指数蹭蹭涨。
-
jti和iss、aud一定要校验！ jti是token的唯一ID，黑名单可以立即生效；iss（签发者）和aud（受众）不校验的话，黑客可以把一个站点的token弄到另一个站点去用，这叫跨站伪造,挺坑的。
-
kid参数小心注入！ 有些Header里带kid（密钥ID），代码可能直接用kid拼路径读取文件，比如
../../etc/passwd这种，这不就造成路径遍历漏洞了嘛，所以JWT伪造怎么选，kid的值必须后台映射稳妥,不能用外部输入直接拼址。
你以为防了伪造就完事？不存在的！
兄弟，就算你把上面的坑全填了，黑客还有招儿——他们可以通过暴力破解弱密钥，假设你真选了HS256，密钥设成了“secret123”、或者公网常见的那种弱口令，那跟木门上挂个纸条有啥区别？分分钟被字典跑出来！所以如果你实在因为某种原因非得用HS256，那密钥长度得至少32位随机字符串，并且定期轮换，但说真的,用RS256你就没这个烦恼了。
再聊聊我的真实感受吧
说实话，每次看到网上说“JWT不安全”的帖子，我都想上去评论一句：“不是JWT的锅，是你JWT伪造怎么选防护措施没选对啊！”这不就跟菜刀切手一样么，你不能因为自己姿势不对,就说菜刀太锋利吧？
码字码到这儿，我又想起那次半夜紧急上线修漏洞的惨状，真心建议大家在做token校验的代码里，多写几行判断，多设几个白名单，别嫌麻烦。安全这东西，选择比努力重要，选对了算法和校验逻辑，黑客想伪造你的JWT？哼,门儿都没有！
下次再遇到JWT伪造的问题，你心里可有底了？先看看 alg 是不是固定死的，再看看公钥私钥分开没，最后检查检查过期时间和kid注入——保准你能硬气一回，要是还有不懂的，欢迎评论区跟我聊聊，或者翻翻我这篇关于 JWT伪造怎么选 的思路总结,咱们一起把安全防线焊死喽！