j*ascript的CSRF攻击是什么_怎样进行防护？_石家庄创泽智能科技有限公司

新闻中心 NEWS CENTER

2025-12-13

浏览次数：次

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

javascript的csrf攻击是什么_怎样进行防护？

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

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

用document.createElement('form')构造隐藏表单，填好参数后form.submit()
用fetch或XMLHttpRequest发POST请求，credentials: 'include'确保带Cookie
甚至用<img src="https://site.com/logout" alt="j*ascript的CSRF攻击是什么_怎样进行防护？" >触发GET型操作（如登出、关注）

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

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

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

Figma

Figma 是一款基于云端的 UI 设计工具，可以在线进行产品原型、设计、评审、交付等工作。

1371 查看详情 Figma

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），这类接口极易被<img alt="j*ascript的CSRF攻击是什么_怎样进行防护？" >或<a></a>标签触发
前端生成token？不行。必须由后端安全生成并绑定用户会话，否则毫无意义

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

以上就是j*ascript的CSRF攻击是什么_怎样进行防护？的详细内容，更多请关注其它相关文章！