JWT伪造后门植入：一个让我后背发凉的真实漏洞复盘
大家好呀，今天想跟你们聊一个我最近在搞安全测试时碰到的事儿，真的是让我后背发凉,必须得写出来给大家提个醒。
事情是这样的，前阵子我接了一个Web应用的渗透测试项目，本来以为就是个常规活，结果没想到，在JWT伪造后门植入这个点上,我发现了让人头皮发麻的东西。
先说说什么叫JWT吧
JWT，全称JSON Web Token，现在但凡是做过前后端分离项目的兄弟应该都不陌生吧？它就是用来做身份认证的一个令牌，服务器签发给你，你每次请求带上它，服务器就知道你是谁，方便是真方便，但问题也来了——一旦这个机制被玩坏了，后果真的不堪设想。
我是怎么发现问题的
当时我在测试登录接口的时候，习惯性地抓了个包，看了看返回的Token，嗯，标准的HS256算法，看起来没啥问题，但是我这人吧，就是手贱,总喜欢把Token解一下看看payload里面装了啥。
解出来一看，payload里面有个role字段，值是"user"，我当时就想，如果我把它改成"admin"呢？正常情况下签名会校验失败,服务器不会认的。
重点来了兄弟们。
我试着把算法改成"none"，然后把签名部分直接删掉，你们猜怎么着？服务器居然返回了200，而且给了我管理员权限！我当时整个人都愣住了，这种感觉就像你随手拧了一下别人家的门把手，结果门直接开了……
更可怕的还在后面
如果只是算法混淆漏洞，那还算常见，修一修就好了，但我在进一步测试的时候发现，这个系统里面居然被植入了后门。
具体是这样的：在JWT的payload里面，有一个看起来像是正常业务字段的东西，叫debug_mode，平时是false，但如果你把它设置成true，并且用一个特定的密钥重新签名,服务器就会在响应头里面返回一个隐藏的管理接口地址。
这个密钥嘛……我翻了翻前端打包的JS文件，居然在注释里找到了。你说气不气人？ 开发者把签名密钥直接写死在前端代码里，还贴心地加了注释说明,这跟把家门钥匙插在门锁上有什么区别啊？
后门是怎么植入的
我后来复盘了一下,攻击者大概是这么操作的：
- 首先通过某种方式（比如供应链攻击、或者内部人员操作）获取到了JWT的签名密钥
- 然后在正常的认证流程中，悄悄地加入了一个特殊的payload字段
- 这个字段平时不会触发任何异常行为，看起来就是个普通的业务参数
- 但只要攻击者用特定方式构造JWT，就能激活这个后门，获得持久化的管理权限
说白了，这就是一个披着合法Token外衣的隐形后门，你常规的安全扫描根本扫不出来，因为从表面上看，这个Token的签名是合法的，payload结构也是"正常"的。
为什么这事儿这么危险
你想啊，JWT本来就是无状态的，服务器不存Session，全靠Token本身来验证身份，如果攻击者能够伪造Token，那就等于他可以冒充任何人，包括管理员，而且这种后门植入方式极其隐蔽，不像SQL注入或者XSS那样有明显的特征,很多WAF根本检测不到。
更坑的是，这种后门可以长期潜伏，只要密钥不换，攻击者随时都能回来，你换了密钥？不好意思，如果后门代码还在,攻击者换个方式继续植入就行了。
怎么防范呢
说了这么多吓人的，总得给点建议吧,不然你们该骂我了哈哈。
第一，千万别把签名密钥写在前端代码里，这个是底线中的底线，密钥必须存在服务端,而且要定期轮换。
第二，严格校验JWT的算法，服务端应该明确指定使用哪种算法，而不是信任Token头部里的alg字段，把那该死的"none"算法直接禁掉！
第三，对JWT的payload做严格的schema校验，别什么字段都往里面塞，更别让那些看起来"无害"的字段触发敏感操作。
第四，定期做安全审计，特别是对认证授权相关的代码，后门这种东西,往往就藏在那些你平时不太注意的角落里。
最后说两句
这次经历真的让我感触挺深的，JWT伪造后门植入这种攻击手法，说实话技术含量不算特别高，但它的隐蔽性和危害性真的是一等一的，很多开发者觉得JWT用起来方便，就忽略了安全配置,结果给了攻击者可乘之机。
希望大家看完这篇文章之后，赶紧去检查一下自己项目里的JWT实现，别等到被入侵了才后悔,那时候可就晚啦！
好了，今天就聊到这儿吧，如果你觉得这篇文章对你有帮助，记得点个赞转发一下哈～有什么想法也欢迎在评论区跟我交流,我看到都会回的！
咱们下期再见，拜拜～👋