广东人社局官网突然弹出“CSRF Token验证失败”的广东攻击红色警告，后台日志里涌进一批伪造的人社社保补贴申请请求。这不是局检电影桥段，2023年广东某地市人社局就遇到过——攻击者利用已登录用户的广东攻击浏览器，在用户不知情时向系统发送修改银行账户的人社指令。值班工程师老陈盯着屏幕说：“请求来源是局检内部IP，但操作时间集中在凌晨3点，广东攻击正常人不会那时候改账号。人社”

CSRF（跨站请求伪造）攻击的局检核心就一句话：借你的手，干我的广东攻击事。你登录了人社局系统，人社浏览器存着会话Cookie。局检攻击者诱导你点开一个恶意页面，广东攻击页面里藏着一个自动提交的人社表单，目标指向人社局后台的局检“修改联系电话”接口。你的浏览器带着Cookie把请求发出去，系统以为是你的正常操作。广东人社局每天处理几十万笔业务，一旦被CSRF批量篡改待遇发放账户，后果不是丢几个数据那么简单。

检测到CSRF攻击，第一反应不是拔网线。先看日志里的Referer头。正常请求来自人社局自己的域名，攻击请求的Referer要么是空，要么是某个奇怪的外站。再看请求里的Token参数。广东人社局从2021年起给所有敏感操作加了一次性Token，每次页面加载随机生成，服务端校验。攻击者拿不到这个Token，伪造的请求里Token字段要么缺失，要么是旧值。老陈那次就是靠Token校验拦住了大部分请求，剩下几个漏网的因为Referer异常被标记。

确认是CSRF后，临时封禁攻击源IP段。但别只封IP，攻击者可能用代理池。更有效的做法是强制所有在线用户重新登录，让旧会话立即失效。同时把敏感接口的Token校验从“可选”改成“强制”，并增加SameSite Cookie属性——把会话Cookie的SameSite设为Lax或Strict，浏览器就不会在跨站请求里带上它。广东人社局那次攻击后，运维团队连夜把Cookie策略从None改成了Lax，第二天攻击流量直接降了九成。

有人会问，为什么不用验证码？验证码能挡自动化脚本，但挡不住诱导真人点击的CSRF。真正的防线是Token加SameSite加Referer白名单，三样缺一不可。广东人社局后来还加了一条：修改银行账户必须短信二次验证。攻击者就算伪造了请求，拿不到用户手机也白搭。

普通用户遇到人社局系统提示“操作异常”或“会话失效”，别急着关页面。先检查自己有没有在别的网站登录过人社局账号，尤其是那些看起来像官方但域名不对的“社保查询”页面。发现异常立刻打12333挂失账户，比等系统报警快得多。

技术团队事后复盘时发现，攻击者其实在三天前就扫描了人社局的外围系统，找到一个存在XSS漏洞的旧版公告页面，把CSRF攻击代码嵌了进去。XSS加CSRF组合拳，老套路但管用。修复XSS漏洞比防CSRF更根本——没有XSS，攻击者很难在用户浏览器里执行恶意脚本。

广东人社局现在每季度做一次CSRF演练，用内部工具模拟攻击，看值班人员多久能定位到Token校验日志。上次演练用了7分钟，比2023年那次实际攻击快了20分钟。技术这东西，平时多流汗，战时少流血。