文章总结： 本文揭示了一种CSRF防护漏洞：令牌未与用户会话绑定，仅验证令牌是否在全局池中有效。攻击者可获取自己的合法令牌，替换到其他用户的请求中实现跨用户操作。建议测试时交叉验证令牌与会话的绑定关系，避免仅依赖令牌存在性。 综合评分： 80 文章分类： web安全,漏洞分析,实战经验

CSRF TOKEN 就是个摆设？这个未绑定会话的洞让我白捡一笔赏金

原创

升斗安全XiuXiu 升斗安全XiuXiu

升斗安全

2026年7月10日 08:45 广东

在小说阅读器读本章

去阅读

【文章说明】

• 目的：本文内容仅为网络安全技术研究与教育目的而创作。
• 红线：严禁将本文知识用于任何未授权的非法活动。使用者必须遵守《网络安全法》等相关法律。
• 责任：任何对本文技术的滥用所引发的后果自负，与本公众号及作者无关。
• 免责：内容仅供参考，作者不对其准确性、完整性作任何担保。

阅读即代表您同意以上条款。

你有没有遇到过这种情况：明明做了 CSRF 防护，令牌也加上了，结果人家换个令牌照样能打穿？这不是你眼花，也不是测试姿势不对，而是你撞上了一种挺隐蔽的逻辑失误：CSRF 令牌压根没跟用户会话绑定。

咱们先说清楚这是怎么回事。

有些应用的 CSRF 防护机制比较“佛系”。它们不在乎每个令牌是谁领的，只认一件事：你是不是从我这儿发出去的合法令牌。于是它们维护了一个全局的“已签发令牌池”，只要你能掏出一个在这个池子里的有效令牌，请求就直接放行。

听起来好像也没啥大问题？其实问题大了。这意味着什么呢？意味着攻击者可以拿自己的令牌，去冒充别人的操作。

实操起来非常简单，甚至可以当流水线来玩：

先用 Burp 的内置浏览器登你自己的账户，走一遍“更新邮箱”的流程，把请求拦截下来。看一眼里面的 CSRF 令牌值，记住它，然后把这次请求扔掉，我们不真改自己的邮箱。

接下来，打开一个隐私窗口，登另一个测试账户，同样抓一次“更新邮箱”的请求扔进 Burp Repeater。这时候做个调换操作：把请求里的 CSRF 令牌换成刚才你账户里拿到的那个。一发请求，你会发现居然成功了。

这说明什么？说明令牌跟会话之间根本没有一对一的绑定关系，应用只看令牌合不合法，不管这令牌是谁的。这就像你拿别人的工牌刷开了一扇不属于你的门，保安只看工牌是公司发的就放行，根本不核对人脸。

到了这一步，剩下的就是常规操作了。按标准无防护 CSRF 的 PoC 方式构造一个利用脚本，唯一的区别是：因为这类令牌往往是一次性的，所以你要在脚本里放一个全新的、有效的令牌进去。然后把邮箱地址改成和你自己不一样的目标地址，保存脚本，发送给受害者，整套攻击就闭环了。

这种漏洞在实战里比你想象中更常见，尤其是在一些自研或早期版本的防护方案里，开发者可能只做到了“有令牌”这个表象，却忘了最关键的“令牌是谁的”这一步。测试的时候，只要学会在“换令牌”这个动作上多留个心眼，往往就能挖出别人忽略的中危甚至高危。

所以，下次碰到带着 CSRF 令牌的请求，别一看有令牌就绕着走。换个账号、换个令牌，交叉验证一下，说不定惊喜就在那儿等你。

如果这篇文章帮你打开了新思路，别藏着掖着，点赞、在看、转发三连走起，让身边的赏金猎人朋友们也少走点弯路。还没关注的，赶紧点个关注，后续还有更多实战挖洞技巧和思路拆解，咱们一起在赏金之路上越走越稳。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：升斗安全 升斗安全XiuXiu 升斗安全XiuXiu《CSRF TOKEN 就是个摆设？这个未绑定会话的洞让我白捡一笔赏金》