CSRF原理与防御方法全解析

本文深入剖析了CSRF（跨站请求伪造）攻击在JavaScript环境下的真实利用方式——并非依赖用户点击，而是通过恶意脚本静默构造表单、发起带Cookie的fetch/XHR请求，甚至滥用GET接口实现登出、转账等敏感操作；同时系统性地阐明了以服务端签发并校验一次性Anti-CSRF Token为核心、SameSite Cookie与Referer检查为辅助的纵深防御体系，并特别强调了开发中极易被忽视的关键陷阱：严禁GET修改状态、禁止前端生成token、JSON API同样面临CSRF风险、以及SPA中token生命周期管理的重要性——帮你避开90%的防护失效场景。

JavaScript环境下的CSRF攻击，本质是利用用户已登录的会话状态，通过恶意页面里的JS代码自动发起目标网站的请求（比如转账、改密），而浏览器会悄悄带上Cookie，让服务器误以为是用户本人操作。

CSRF在JS里怎么被利用

常见手法不是靠用户点按钮，而是脚本静默执行：

• 用document.createElement('form')构造隐藏表单，填好参数后form.submit()
• 用fetch或XMLHttpRequest发POST请求，credentials: 'include'确保带Cookie
• 甚至用触发GET型操作（如登出、关注）

最靠谱的防护：Anti-CSRF Token机制

核心思路是“服务端发令牌，前端必须回传，且每次不重复”：

• 用户访问表单页或进入SPA主页面时，后端返回一个一次性token（如csrf_token=abc123），写入HTML hidden input 或注入到JS变量中
• 所有敏感请求（AJAX或表单提交）必须在请求头（如X-CSRF-Token）或请求体中带上该token
• 后端收到请求后，比对token是否有效且未使用过；不匹配或已失效则直接拒绝
• 注意：token不能只存在JS变量里——XSS漏洞下可能被窃取；建议配合HttpOnly Cookie存储服务端校验用的签名值

辅助但不可单独依赖的手段

这些能提高门槛，但都有绕过可能，适合叠加使用：

• SameSite Cookie属性：把关键Cookie设为SameSite=Lax或Strict，可阻止大部分跨站带Cookie的GET/POST请求
• Referer检查：后端验证请求头中的Referer是否来自自家域名；但部分浏览器或隐私模式可能不发Referer
• 双重提交Cookie：前端读取一个含token的Cookie，再把它作为请求头或参数提交；服务端比对两者一致即可——无需服务端存token状态，适合无状态API

开发中容易忽略的关键点

防护失效常因细节疏漏：

• API只接受JSON？别忘了Content-Type: application/json本身不能防CSRF——恶意站点仍可用fetch发带Cookie的JSON请求
• SPA应用中，token需随页面加载时获取，并在后续每个请求中显式携带；不能只靠全局axios拦截器“默认加”，要确保首次token加载成功
• 不要用GET请求做状态变更操作（如/delete?id=123），这类接口极易被或标签触发
• 前端生成token？不行。必须由后端安全生成并绑定用户会话，否则毫无意义

基本上就这些。Token机制是基石，SameSite和Referer是加分项，而杜绝GET改状态、避免前端生成token，是不踩坑的前提。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《CSRF原理与防御方法全解析》文章吧，也可关注golang学习网公众号了解相关技术文章。