动态转发JWT伪造：我差点被自己的Token“反杀”的全过程（血泪复盘）
关键词：动态转发JWT伪造
哎,兄弟们，今天这篇文儿，我真是憋着一肚子话想跟你们唠，不瞒你们说，前几天我差点就栽在“动态转发JWT伪造”这六个字上了，你可能觉得这玩意儿就是个常规漏洞，但当我真正在实战里被它摆了一道的时候，我才发现，自己那点水平，就跟纸糊的城墙似的，一戳就破。
我先声明,我不是什么大牛，就是个在安全圈边缘疯狂试探的小菜鸟，那天下午，我正在测一个平台，老规矩，登录后抓包，把那个JWT（JSON Web Token）翻来覆去地看，心里还美滋滋呢，这Token签名算法HS256，密钥估计是个弱口令，爆破一下不就完事儿了？呵，真是天真得可爱。
动态转发？这TM是个啥啊！
我按照老套路,把Header里的alg改成none，Payload里面把user_id换成管理员ID，然后重新编码，哎？你猜怎么着？服务器居然没直接报401，反而给我返回了一个奇怪的302跳转，指向一个内网地址，当时我就愣了，这跟教科书上写的不一样啊！再一查，好家伙，这平台多了个“动态转发”的代理层，它不直接校验Token，而是先把请求转发到后端服务，由后端再去解析这个JWT，最关键的是，这个转发过程是动态的——它根据你提交的某些头部字段，比如X-Forwarded-Host或者自定义的Endpoint，来决定把请求转发到哪儿去。
那一刻,我脑子“嗡”地一下，这不就是把攻击面给无限放大了吗？我伪造的那个none算法Token，在后端识别不出来，但它却把这个非法请求当成“合法包裹”给转发走了，你想想，这就好比你家门口的保安，他不看你的通行证是不是真的，他只管把进门的人往某个楼梯口带，至于带去哪儿，看的是你手里纸条上写的字。
我的“伪造”居然成了别人的跳板
我顺着这个思路往下试,把动态转发的目标指向了我自己的VPS，然后构造了一个恶意JWT，里面塞满了各种路径穿越的Payload，结果怎么着？后端服务器真的把那个带有我恶意Payload的请求，原封不动地打到了我VPS上！虽然我没拿到内网权限，但我眼睁睁看着那个“被伪造的请求”在互联网上跑了一圈，那种感觉很奇妙，就像你扔了个回旋镖，结果它带着你的指纹飞了一圈又回来了。
哎呀,写到这儿我还有点后怕。动态转发JWT伪造的核心痛点根本不是签名的强度问题，而是转发逻辑本身的可控性，很多开发者觉得，我只要对接好/login接口，把Token验好就万事大吉，但一旦加了个动态网关，或者那个“中转层”带了点“智能路由”的脾气，那JWT的信任链就被打破了，我这边的攻击逻辑变成了：伪造JWT + 动态转发参数控制 = 让服务器对我的恶意请求进行二次代理，这可比单纯的alg=none或者密钥爆破高级多了，也隐蔽多了。
自我反思：别让你自己成为那只“帝企鹅”
那天复盘的时候,我盯着Burp里的那串日志，心里拔凉拔凉的，我要是能早点想到“动态转发”这个变量，早该去测试一下不同转发头组合下的JWT解析差异，而不是傻乎乎地在那儿爆密钥，说真的，这种场景在真实的微服务架构里太常见了，尤其是那些用了Nacos或Consul做动态路由的兄弟，你们的每一个spring.cloud.gateway.routes配置，都可能是一块变形的积木，我甚至怀疑，某些大型系统的0day，就是这么被玩出来的，呃…一想到这儿，鸡皮疙瘩都起来了。
最后的叮嘱
所以啊,朋友们，咱们在做测试的时候，真不能只盯着Token那一亩三分地。动态转发这个机制本身是个好功能，但如果你在动态路由后端的鉴权逻辑里，仍然只认JWT签名而不认转发来源和路径上下文，那就是等着被“借刀杀人”，我现在每次看到JWT，心里都得多嘀咕两句：这玩意儿会不会被动态转发给卖喽？
好了,话就说到这儿，这篇血泪史可都是干货，如果你也在搞安全测试，或者对JWT这块有什么独到的见解，欢迎来跟我唠唠，毕竟，一个人琢磨太容易走火入魔了。
偷偷说一句,学习网络安全可以加QQ：337207030，咱们一起聊聊那些让人夜不能寐的漏洞，不然一个人扛着太累了！
