CSRF攻击的防御法本质是浏览器自动携带Cookie。你登录了银行网站，漏洞Cookie还在有效期，防御法这时又打开了一个恶意页面，漏洞那个页面里的防御法表单或脚本悄悄向银行发起了转账请求。浏览器不管请求是漏洞从哪里发起的，只要Cookie有效，防御法就照单全收。漏洞就这么简单，防御法一个合法请求，漏洞一个非法来源，防御法服务器却分不清。漏洞

最有效的防御法防御手段，是漏洞校验请求头中的Origin或Referer字段。Origin字段是防御法浏览器自动附加的，JavaScript无法修改。当服务器收到一个POST请求，先检查Origin是否在白名单内。如果请求来自恶意站点，Origin自然不对，直接拒绝。这个方法几乎零成本，而且对用户体验没有任何影响。但有个坑——有些老旧的浏览器不支持Origin，或者某些隐私插件会剥离Referer，这时候就得有备用方案。

更通用的做法是CSRF Token。服务器在渲染表单时，生成一个随机的、与用户会话绑定的Token，放进隐藏字段里。提交时，服务器验证这个Token是否匹配。恶意站点拿不到这个Token，因为它存在于目标网站的页面源码中，跨域读取会被同源策略拦下。这里有个细节：Token不能放在Cookie里，否则又回到了原点——攻击者可以通过CSRF让浏览器带上Cookie，如果Token也在Cookie中，整个防御就形同虚设。Token要放在页面里，或者放在请求头中，由JavaScript读取后附加到请求上。

还有一个容易被忽略的点：双重提交Cookie。把Token同时放在Cookie和请求参数中，服务器只比较两者是否一致。这种方法不需要服务端存储会话状态，适合无状态API。但它的安全性略弱——如果子域名被攻破，攻击者可以往该域名的Cookie中写入任意值，然后构造匹配的请求参数。所以，这种方法只适合低风险场景，别用在金融操作上。

我见过一个真实案例。某电商平台的退款接口只用了Referer校验，但他们的CDN配置错误，导致部分静态资源从第三方域名加载。攻击者构造了一个页面，先加载该第三方域名下的图片，触发Referer为第三方域名，再通过表单提交退款请求——服务器一看Referer是白名单内的第三方域名，就放行了。这暴露了一个问题：Referer校验必须严格匹配完整域名，不能只检查包含关系，而且白名单要尽量小。

另外，别忽略JSON接口的防御。现在很多前端用AJAX提交JSON，Content-Type是application/json。这类请求会触发CORS预检，所以很多人觉得安全。但攻击者可以用text/plain类型提交，或者用Flash的跨域漏洞（虽然Flash已死，但老系统还在）。所以，不要依赖Content-Type来判断来源，该做的校验一样不能少。

最后说个反直觉的事实：同步请求比异步请求更容易被CSRF利用。因为表单提交不触发CORS预检，而且可以跨域发送。所以，凡是涉及状态变更的接口，无论同步还是异步，都必须防御。我的习惯是：写操作一律校验Token，读操作可以放宽。毕竟，CSRF攻击的目标是“让服务器执行操作”，而不是“偷看数据”。

防御CSRF不是追求绝对安全，而是把攻击成本提高到不值得尝试的程度。Token加上Origin双重校验，已经能挡住绝大多数攻击。剩下的极少数漏洞，往往出在业务逻辑的边角料上——比如某个接口忘了加Token，或者某个回调URL没校验。定期审查代码，把CSRF防御写进开发规范，比什么都强。

(责任编辑：娱乐)