你点开一个论坛帖子，跨站里面藏着一张标签，请求src指向银行转账接口。伪造浏览器二话不说带上你的普遍Cookie发了请求。钱没了。跨站这就是请求CSRF，跨站请求伪造——它不偷你的伪造密码，它直接用你的普遍身份干活。

2007年，跨站Gmail被CSRF漏洞击穿。请求攻击者构造了一个看似无害的伪造网页，里面嵌着自动提交的普遍表单，目标指向Gmail的跨站联系人导出接口。用户只要在登录Gmail的请求状态下访问那个页面，浏览器就乖乖把整个通讯录打包送走。伪造Google后来修了，但同类手法至今没绝迹。我去年在一个小型电商后台还见过类似逻辑：删除商品的操作是GET请求，URL带个id参数，没有任何token校验。我随手在聊天窗口发了个链接给同事，他点了一下，商品没了。他以为是自己误操作。

浏览器设计之初就没考虑跨站信任边界。Cookie机制让同域请求自动携带凭证，这本身是便利，也是软肋。服务器收到请求，只看Cookie有效，就认为“这是用户本人”。可用户本人在哪？在另一个标签页里刷视频。攻击者不需要接触用户设备，不需要破解加密，只需要让用户的浏览器替自己发一个请求。这个请求甚至不需要返回结果——转账、改密码、发帖，副作用已经发生。

很多人以为CSRF需要用户点击什么按钮。不用。一个自动提交的表单，一段fetch调用，甚至一张图片的src，都够了。POST请求稍微麻烦点，但攻击者可以用form标签加JavaScript自动提交，用户感知不到。我试过在本地搭一个测试页，把银行转账接口的URL塞进img标签，刷新页面，转账成功。当然那是测试环境，但逻辑一模一样。

防御手段其实不复杂。随机token是最常见的做法：服务器在表单里埋一个一次性字符串，提交时校验。攻击者拿不到这个token，因为同源策略阻止他读取页面内容。还有SameSite Cookie属性，现代浏览器默认把跨站请求的Cookie限制住，这招挺管用。但老系统迁移慢，很多内部管理后台还在裸奔。我见过一个政府项目，所有删除操作都是GET，参数明文，没有任何防护。问开发，答：“内网，没事。”内网钓鱼邮件一点，照样中招。

CSRF的可怕在于它不破坏认证，它滥用认证。你密码再强，双因素认证再全，浏览器里的会话一活跃，攻击者就能借刀杀人。用户完全无感，服务器日志里那条请求看起来和正常操作一模一样。排查的时候，你只能看到IP是用户的，Cookie是用户的，User-Agent也是用户的。唯一不对劲的是Referer头——但很多服务器根本不检查这个。

有个细节值得玩味：CSRF攻击往往针对状态变更操作。读取数据反而少，因为攻击者拿不到返回内容。所以转账、改邮箱、加管理员、发消息，这些才是重灾区。我见过一个社交平台，改绑定手机号的接口没token，攻击者诱导用户访问一个页面，手机号直接换成攻击者的。用户第二天登录，发现账号找不回了。

说回现实。很多开发者觉得用了JWT就安全了。JWT放在Authorization头里确实能防CSRF，因为浏览器不会自动携带。但要是把JWT存localStorage，再用Cookie传，那又绕回来了。安全这东西，链条上任何一环松了，整个就垮。CSRF不是最复杂的漏洞，但它是最容易被忽视的。因为它太简单了，简单到很多人觉得“不至于”。

我写这些不是要吓谁。只是每次看到那些没有token的表单，没有SameSite的Cookie，没有Referer校验的接口，就觉得像看到一扇没锁的门。门里不一定有贼，但路过的人随手一推，就开了。

(责任编辑：休闲)