2024服务器CSRF攻击防护实操指南：从原理到落地全流程避坑

很多运维、后端开发都碰过用户账号被恶意改密、后台数据莫名删除的情况，排查半天才发现是CSRF攻击借用户登录态发起的恶意请求。这篇整理了我们团队近3年的落地防护经验，从攻击路径、实操配置到高频踩坑点全讲透，没有太晦涩的专业术语，刚入门的技术人员也能跟着配置，帮你少踩90%的防护坑。

先搞懂CSRF针对服务器的常见攻击路径

简单来说CSRF就是攻击者借用已登录用户的身份，在用户不知情的情况下向服务器发起恶意请求，常见的攻击场景有三类：

1. 恶意链接诱导跳转

用户登录了网站后台或者电商平台后，点击了攻击者发的钓鱼链接，页面自动发起转账、改密等请求，服务器收到的是合法用户的登录态，就会默认执行操作。

2. 嵌入式资源自动请求

攻击者把恶意请求嵌在第三方网站的图片、iframe标签里，用户只要访问了第三方网站，浏览器就会自动带上目标网站的Cookie发起请求，不需要用户主动点击。

3. 未授权接口批量调用

如果服务器的核心接口没有做来源校验，攻击者可以直接构造批量请求，盗用用户身份批量刷取优惠券、篡改个人信息，甚至批量删除业务数据。

核心落地配置步骤

做服务器CSRF攻击防护第一个要落地的就是同源校验+Referer校验，可以直接在Web服务器层面配置规则，拦截非信任域名的请求，比如Nginx的配置参考如下：

``` 核心接口校验Referer location /api/ { if ($http_referer !~ ^https://(www\.yourdomain\.com|admin\.yourdomain\.com)/) { return 403; } proxy_pass http://your_backend; } ```

如果是开发层面的配置，可以直接在后端框架里开启同源策略校验，允许的跨域域名要做白名单限制，不要用通配符。

动态CSRF Token校验

这是目前最常用的防护方案，用户登录后服务端生成唯一的动态Token，存放在用户会话里，后续所有表单提交、AJAX请求都要携带这个Token，服务端校验不匹配直接拦截请求。现在主流的SpringBoot、Django、Vue等框架都自带CSRF Token组件，直接开启即可，不需要自己手写逻辑。

敏感操作二次校验

做服务器CSRF攻击防护的时候，很多人容易忽略敏感操作的二次校验环节，涉及到改密、转账、删除数据、权限变更这类高危操作，除了基础的Token校验，还要加短信验证码、人脸验证、操作密码二次输入的步骤，就算攻击者绕过了基础防护，也没法完成高危操作。

常见避坑点汇总

不少企业做服务器CSRF攻击防护的时候，只覆盖了PC端的Web接口，忽略了移动端、小程序端的同接口适配，导致移动端接口成了防护漏网之鱼，配置的时候要注意全端覆盖，针对APP端可以用签名校验替代Referer校验，避免移动端拿不到Referer导致误拦截。

• 不要把CSRF Token存在localStorage里，容易被XSS攻击窃取，优先存放在带HttpOnly、Secure标记的Cookie中
• 不要只校验POST请求，GET请求的敏感接口也要加防护，避免攻击者用图片链接发起GET型CSRF攻击
• 不要用固定值的Token，必须是用户会话级或者请求级动态生成，会话过期后自动失效

我这两年处理过3起因为CSRF防护不到位导致的用户数据泄露事件，大多都是10人以内的小团队，总觉得“我们业务量小没人会攻击”就省了这步配置，真出事了光是给用户赔礼道歉、修复数据的成本，比提前做防护高几十倍。其实现在云服务商的WAF基本都自带现成的CSRF防护规则，花十几分钟开一下就能规避90%以上的风险，真没必要赌概率。