金融SRC实战手记：当我用JWT伪造漏洞拿下高危勋章，那感觉真是绝了！
哎哟喂，兄弟们，今天咱们不聊虚的，就唠唠我上个月在金融SRC（安全应急响应中心）平台上，靠着JWT伪造漏洞一路过关斩将，最终拿到那个闪着金光的高危勋章的心路历程，说实话，那会儿我盯着屏幕，手都有点抖，心里就俩字：“真绝了！”
你们也知道，金融行业嘛，那防护级别，简直是铜墙铁壁，各种WAF、风控策略堆得跟山一样，平时想挖个洞，感觉就像在铁桶上找缝，难搞哦！但咱就是干这行的，越难越得啃，那天午后，我正盯着某金融APP的接口文档发呆，心里还嘀咕着：“这token机制看着挺严的，加密算法也正规，怕是没啥戏了……” 嘿！结果你猜怎么着？
我习惯性地把抓到的JWT（JSON Web Token）令牌丢进解码器里瞎琢磨，突然发现，这玩意儿Header里的算法字段竟然写着none？！我当时就愣住了，揉了揉眼睛，“我滴个乖乖，这不是送人头吗？” 这可不是开玩笑的，很多新手可能不知道，JWT伪造的核心逻辑，就是这几行Base64编码的信任危机。如果服务端没校验算法类型，咱就能把算法改成none，然后把签名部分一删，直接冒充任意用户！ 那个瞬间，我脑子里“嗡”的一声，感觉就像在沙漠里渴了三天，突然瞅见一汪清泉，那兴奋劲儿,别提了！
紧接着，我立马动手，把那令牌的Payload（载荷）里的user_id和role字段，稀里哗啦全改成管理员的参数，当我用这个伪造的、没签名的token去请求管理后台的API时——好家伙！ 服务器居然真的信了！一大堆内部交易流水、用户身份证信息，就那么赤裸裸地躺在响应包里，那一秒钟，我头皮都发麻了，倒吸一口凉气，心想：“这要是被坏人搞到手，那不得炸锅啊？” 虽然咱是白帽子，但那一刻的震撼,真的难以形容。
不过吧，兴奋归兴奋，咱可不能乱来，我赶紧按照SRC的标准流程，小心翼翼地录屏、截图、整理成报告，连漏洞危害描述都写得明明白白的，特别强调了JWT签名未验证的致命性，提交上去的那几天，我其实挺忐忑的，心里直打鼓：“审核小哥会不会觉得我是瞎报的呀？” 结果，第三天一打开后台，高危！那个大大的红章，直接拍在我脸上！我当时就“噗嗤”一声笑了出来，成就感爆棚！感觉那几天的秃头都值了。
说真的，JWT伪造这个点，在金融行业里还挺常见的，很多开发为了赶进度，容易把第三方的库用错，或者干脆偷懒不校验签名，我这就相当于给他们敲了个警钟呀，兄弟们，如果你们也想搞搞金融SRC,不妨多留意一下这几个点：
- 看算法：是不是支持
HS256却用了RS256的公钥验签？或者干脆支持none？ - 看密钥：硬编码的弱密钥（比如
secret、123456），直接爆破,那酸爽！ - 看参数：改了
role、is_admin之类的字段,响应有没有变化？
哎，反正我这趟下来，最大的感受就是，安全无小事，细节定成败，漏洞挖掘有时候真的像看推理小说，破绽往往藏在最不起眼的角落里，咱这算是幸运的,但背后的脑细胞死的也多啊。
最后呢，跟大家伙说个掏心窝子的话，这行水挺深的，单打独斗容易迷路。如果你也对网络安全、渗透测试、SRC挖掘这些玩意儿感兴趣，但一个人学起来又觉得没什么方向，加个兄弟聊聊嘛！我的QQ是：3382688692，咱们互相交流交流心得，说不定下次碰上硬骨头，还能一起啃呢！嘿，对了，觉得我这篇文章有价值的，记得帮忙转发一下，让更多朋友少走弯路！咱们下回再聊！
