一个凌晨三点，漏洞攻击者往某论坛的危害私信里塞了一条链接。管理员点了，漏洞第二天整个用户数据库被拖走，危害后台被挂上挖矿脚本。漏洞整个过程里，危害管理员没有泄露任何密码，漏洞浏览器地址栏也没出现异常——CSRF干的危害。

CSRF，漏洞跨站请求伪造，危害本质是漏洞“借刀杀人”。攻击者不需要偷你的危害cookie，不需要破解你的漏洞账号，只需要诱导你在已登录的危害浏览器里发出一个你根本没打算发出的请求。比如那张图片链接，漏洞实则是转账接口。你点开时，浏览器带着你的合法会话，悄悄把款转走了。受害者毫无感知，直到银行短信提醒余额不对。

危害分三个层级。最浅层是“操作冒用”，改个邮箱、发条动态、删个订单，看着不痛不痒，但积少成多能让你账号彻底变成攻击者的傀儡。中层是“数据篡改”，比如CMS后台的配置项被改，整站跳转到赌博页面，SEO权重一夜清零。最狠的是“权限链攻击”——攻击者利用CSRF修改管理员的密码重置邮箱，然后走正常找回流程，直接接管整个系统。这已经不是偷东西，是连房子钥匙都换了。

真实案例比理论更刺眼。某电商平台曾爆出CSRF漏洞，攻击者构造一个商品链接，受害者只要在登录状态下点击，就会自动下单购买高价虚拟商品，钱货两空。更讽刺的是，退款接口同样存在CSRF，攻击者可以反向操作，让平台给任意账号打钱。整个攻击链不需要任何交互，受害者连“我是不是点了什么”的疑问都不会有。

为什么这年头CSRF依然猖獗？因为很多开发者的防护思路还停留在“检查Referer头”这种层面。Referer能伪造，而且浏览器隐私模式、某些安全插件会直接砍掉这个字段，你拦了正常用户，放过了攻击者。更常见的是，小团队图省事，接口不做任何状态校验，全靠“前端按钮隐藏”来防误操作——这等于把门锁装在画上。

我见过最离谱的防护，是某后台用“二次弹窗确认”对抗CSRF。弹窗确实能挡住无脑点击，但攻击者只要构造一个表单自动提交，弹窗照样被触发，用户习惯性点“确定”，一切照旧。真正的防线只有两条：一是关键操作校验不可预测的Token，且Token必须绑定会话；二是给敏感操作加二次验证码，且验证码不能是图形滑块那种能自动破解的。

还有个反直觉的点：CSRF的危害在移动端被放大了。手机浏览器标签页少，用户经常在多个App间跳转，WebView默认携带cookie，攻击者利用URL Scheme唤起浏览器，连用户手动输入的环节都省了。你以为在刷朋友圈，其实已经在给攻击者转账。

别指望用户“小心点”能解决问题。CSRF攻击的根本矛盾在于——浏览器无法区分“用户主动发起的请求”和“恶意构造的请求”。只要用户保持着登录态，任何第三方页面都能借他的身份向你的服务器喊话。你唯一能做的，就是让服务器学会质疑每一个请求，而不是默认信任。