17370845950

CSRF攻击本质是利用用户已登录会话，通过恶意JS静默发起带Cookie的请求；防护核心是后端签发一次性Anti-CSRF Token并校验，辅以SameSite Cookie、Referer检查等手段，严禁GET改状态或前端生成token。

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，是不踩坑的前提。