编码方式JWT伪造

我的天！JWT伪造居然这么简单？——聊聊那个让我头皮发麻的编码方式

哎,兄弟们，今天咱们得好好唠唠这个JWT伪造的事儿！

说实话,我一开始接触JWT的时候，压根没当回事儿，不就是个token嘛，Base64编码一下，签个名，完事儿！可谁知道，就是这看似“安全”的编码方式，差点让我在项目上线前翻了大车，现在想想，后背还是凉飕飕的！

先说个小插曲，急死我了！

前阵子帮朋友看一个接口鉴权的问题,他那边用JWT做登录态管理，我拿过来一看，好家伙！eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyTmFtZSI6ImFkbWluIiwicm9sZSI6ImFkbWluIiwiZXhwIjoxNzEwMDAwMDAwfQ. 这串东西挂在Cookie里，看得我直冒冷汗。

我当时就问他：“兄弟，你这JWT密钥是不是写在代码里了？”他一脸懵：“对啊，不都这么写吗？”我的天！这不等于把家门钥匙放在门口脚垫下面吗？

重点来了！JWT伪造到底是个啥？

咱们得先搞明白JWT是个啥结构,它分三部分：Header（头部）、Payload（载荷）、Signature（签名），前两部分就是Base64编码的JSON，注意啊，只是编码，不是加密！ 你随便找个在线工具就能解开看到明文内容。

关键就在这个alg参数上！很多新手都忽略这个，当你看到"alg":"HS256"的时候，心里得咯噔一下——这是对称加密，密钥一旦泄露，或者算法被篡改成none，那JWT伪造就真的是一分钟的事儿了！

我记得当时我做渗透测试的时候,就试过把这个alg改成none，然后payload里把"role":"user"改成"role":"admin"，重新Base64编码一下……你猜怎么着？服务器居然认了！我当时那个心情啊，简直比大夏天喝到冰可乐还爽，但同时也替那个网站捏了把汗。

我这暴脾气，JWT伪造的几种坑你踩过没？

算法混淆攻击——服务器支持RS256（非对称），但你给它来个HS256（对称），它如果傻乎乎地用公钥当密钥来验签，那你就能用公钥伪造签名！这招我试过，成功率贼高！
密钥泄露——好多开发图省事，密钥直接硬编码在JS文件里，或者放GitHub上，我见过最离谱的，密钥是"secret"……兄弟，你这也太敷衍了吧？好歹用个强密码啊！
none算法——最无脑的伪造方式！直接把alg改成none，删掉签名部分，服务器如果没有禁用这个算法，那你的权限就随便写了！
过期时间不校验——有的后端偷懒，JWT验签通过就放行，压根不检查exp字段，这意味着你拿着一个十年前签发的token都能登录……这心也太大了吧！