csrf漏洞防护

CSRF漏洞的漏洞本质是浏览器会无条件携带目标站点的Cookie。攻击者不需要偷走你的防护密码，只需要诱导你的漏洞浏览器向目标站点发一个精心构造的请求，服务器看到合法Cookie就信了，防护于是漏洞执行了转账、改密、防护发帖等操作。漏洞这就像有人趁你不在，防护拿着你的漏洞工牌进了公司，前台只看工牌不核对人脸。防护

我见过最典型的漏洞案例是某个论坛的退出登录接口。攻击者在自己的防护页面上放了一个隐藏的img标签，src指向论坛的漏洞退出URL。受害者只要访问了攻击者的防护页面，浏览器就会自动请求那个URL——带着论坛的漏洞Cookie。结果就是用户莫名其妙被登出，反复发生，用户以为是论坛bug，其实是CSRF在作祟。这个例子够温和，但换到银行转账接口，后果就完全不同了。

防护手段分几层，最基础也最容易被忽略的是检查请求头中的Origin或Referer字段。但这两个字段有时候会被浏览器省略，比如某些隐私模式下跳转，或者一些老旧浏览器。所以单靠这个不够保险。

更通用的做法是CSRF Token。服务器在渲染表单时生成一个随机token，存在session里，同时放进隐藏字段。提交时服务器比对表单里的token和session里的token是否一致。攻击者没法提前知道你的token值，伪造的请求自然过不了关。这个方法几乎适用于所有场景，但有个前提——你的站点不能有XSS漏洞，否则token会被直接读走。

还有同步器令牌模式，本质是双提交Cookie。把token同时放在Cookie和请求参数里，服务器校验两者是否匹配。这个方案不需要服务端存储session，适合分布式架构，但实现时容易写错，比如忘了校验Cookie中的token和参数中的token是否一致，那就等于白做。

另外，自定义请求头也是个实用技巧。比如要求所有敏感操作必须带X-Requested-With: XMLHttpRequest，因为跨域请求默认不会带这个头。但注意，这依赖CORS策略配置正确，如果服务端允许了任意来源跨域，这招就失效了。

我个人强烈建议，凡是涉及资金、密码、权限变更的接口，必须加二次校验——比如要求输入当前密码，或者发送短信验证码。这不算CSRF的常规防护，但它是兜底保险。CSRF防护做再全，也怕逻辑漏洞，比如某个接口虽然校验了token，但token存在URL参数里，又被日志记录了，那等于裸奔。

最后说个容易被忽略的点：JSON接口。很多人以为POST JSON就安全，因为form表单没法直接提交JSON。但攻击者可以用fetch或者XMLHttpRequest跨域发JSON请求，只要目标站点没限制Content-Type或没做CORS预检拦截，照样能打。所以别觉得接口格式特殊就掉以轻心。

防护这东西，没有银弹。Token、Origin校验、自定义头、二次验证，每加一层就多一分安全，但也多一分开发成本。我见过不少团队嫌麻烦只做了token，结果token生成逻辑写错，每个请求都校验同一个固定值——那跟没做一样。代码评审的时候得盯着点，别让防护变成形式主义。