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 甚至用
最靠谱的防护：Anti-CSRF Token机制
核心思路是“服务端发令牌，前端必须回传，且每次不重复”：
用户访问表单页或进入SPA主页面时，后端返回一个一次性token（如csrf_token=abc123），写入HTML hidden input 或注入到JS变量中 所有敏感请求（AJAX或表单提交）必须在请求头（如X-CSRF-Token）或请求体中带上该token 后端收到请求后，比对token是否有效且未使用过；不匹配或已失效则直接拒绝 注意：token不能只存在JS变量里——XSS漏洞下可能被窃取；建议配合HttpOnly Cookie存储服务端校验用的签名值
辅助但不可单独依赖的手段
这些能提高门槛，但都有绕过可能，适合叠加使用：
立即学习“Java免费学习笔记（深入）”；
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，是不踩坑的前提。
以上就是javascript的CSRF攻击是什么_怎样进行防护？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1541985.html
微信扫一扫 
支付宝扫一扫 
