你刚在银行网站点了“退出”，跨站浏览器还开着另一个标签页。请求那是伪造个小游戏网站，页面里藏着一行代码，攻击正悄悄向银行服务器发请求——转账。跨站银行服务器一看，请求你的伪造登录Cookie还在，直接执行。攻击钱没了。跨站你什么都没点，请求什么都没输。伪造

这就是攻击CSRF，跨站请求伪造。跨站它不偷你的请求密码，不破解你的伪造账号，它只是借你的手，用你的身份，干它想干的事。浏览器有个根深蒂固的毛病：只要目标网站有你的有效Cookie，任何页面发起的请求，它都自动带上。这个设计本身是为了方便，结果成了攻击入口。

2008年，YouTube就吃过这个亏。攻击者构造了一个页面，里面嵌入对YouTube的请求，把用户喜欢的视频批量加到“最爱”列表里。你打开那个页面，什么都没做，列表就变了。更早的2006年，Netflix也中过招，攻击者能改用户的收货地址和队列。这些还算轻的。路由器DNS设置被改、Gmail自动转发被开启、网银转账被触发——CSRF能干的坏事，取决于目标网站有多少“一键完成”的功能。

关键在于“跨站”两个字。攻击页面和受害网站必须不同源。同源策略挡住了脚本读取响应，但没挡住请求发出。请求发出去了，服务器执行了，响应被同源策略拦在攻击者看不到的地方。攻击者不需要看到响应，他只需要请求被处理。这叫“盲打”，但效果很实在。

防御手段其实不复杂。最直接的是CSRF Token：服务器在表单里埋一个随机值，提交时必须带上，攻击页面拿不到这个值。但Token得是真正随机的，得跟用户会话绑定，还得每次请求都换。很多网站偷懒，Token固定不变，或者只在前端校验，等于没防。

另一个路子是检查Referer头。请求从哪来的，服务器看一眼。但Referer可以被浏览器隐私设置抹掉，也可以被攻击者用某些技巧绕过。还有SameSite Cookie属性，让浏览器在跨站请求时不发Cookie。Chrome从80版开始默认把没设SameSite的Cookie当Lax处理，这招挡掉了大量老式CSRF。但Lax不是万能的，顶级导航的GET请求还是会带上Cookie。如果你的转账接口是GET，照样完蛋。

我见过一个内部系统，所有操作都是GET请求，删除用户就是点个链接。CSRF Token没加，Referer没查，SameSite没设。攻击者只需要在论坛帖子里放个图片，src指向那个删除接口，管理员一登录论坛，用户就被删了。这不是理论，这是2019年某企业真实发生的事。修复方案也简单：把删除改成POST，加Token，设SameSite。三行配置的事，拖了两年。

CSRF的诡异之处在于，它利用的是信任。服务器信任浏览器带来的Cookie，浏览器信任当前页面发起的请求。攻击者夹在中间，两头都不需要骗，只需要搭个桥。你登录了，你访问了，请求就发出去了。整个过程没有弹窗，没有异常，没有需要你点击的“确认”。

现在纯CSRF攻击比以前少了，因为现代框架默认带Token，浏览器默认SameSite。但老系统还在跑，自定义接口还在裸奔。更麻烦的是，CSRF经常和XSS组合出现。XSS能读页面内容，能拿到Token，CSRF就变成了“带Token的CSRF”，防御直接归零。所以别把CSRF当独立问题看，它是一串漏洞里的中间环节。

检查你的网站：所有写操作是不是POST？表单里有没有随机Token？Cookie有没有SameSite？Referer校验是不是只信白名单？四个问题，有一个答不上来，就该动手了。攻击者不会等你准备好。

(责任编辑：知识)