10.2 CSRF 攻击与防御CSRF 全称Cross-Site Request Forgery跨站请求伪造核心一句话利用用户当前已登录的身份诱导用户在不知情的情况下发起跨站请求执行非自愿操作。和 XSS 对比简单记忆XSS 是偷你的身份凭证以攻击者身份执行CSRF 是借用你浏览器自带的身份Cookie以你的身份偷偷发请求。10.2.1 CSRF 攻击原理前提条件缺一不可用户已经登录目标网站A浏览器保存了A的登录CookieCookie是同源自动携带网站A的关键业务接口只依靠Cookie识别身份没有二次校验请求是否为用户自愿发起攻击者构造恶意站点B诱导登录A的用户访问B在B页面中嵌入自动向A发起请求的代码图片、表单、iframe、js请求等。完整攻击流程用户正常访问bank.com并登录浏览器存放bank.com的登录Cookie攻击者制作恶意页面里面嵌入请求!-- 自动提交转账请求 -- img src[https://bank.com/transfer?toattackermoney10000](https://bank.com/transfer?toattackermoney10000)或者自动提交隐藏表单form action[https://bank.com/transfer](https://bank.com/transfer) methodPOST idcsrfform input nameto valueattacker input namemoney value10000 /form scriptdocument.getElementById(csrfform).submit()/script诱导已经登录银行网站的用户点开这个恶意网页浏览器发起对bank.com的请求会自动带上bank.com域下的Cookie后端收到请求校验Cookie有效认为是登录用户本人操作执行转账用户完全不知情操作在后台完成。关键特点攻击者拿不到Cookie只是浏览器自动带上同源策略不阻止跨站GET/POST请求同源策略主要阻止读取跨站响应不阻止发送跨站请求攻击是“冒用身份”不是窃取身份常见受害场景修改密码、转账、改手机号、发帖、解绑手机号、后台管理操作GET请求最容易构造POST请求也可以被CSRF攻击很多人误以为只有GET才有CSRF这是误区。和XSS简单对比XSS注入脚本主动偷Cookie、读页面数据漏洞在服务端输出/前端DOMCSRF借用已有Cookie偷偷发起请求漏洞在于接口缺少请求合法性校验。10.2.2 主流防御方案按推荐优先级排序方案1CSRF Token最经典、使用最广泛原理服务端给前端页面下发一个随机、一次性、和用户会话绑定的Token放到表单/请求头里后端接收请求时必须校验这个Token是否合法、和当前会话匹配校验通过才执行业务。Cookie是浏览器自动带的而Token必须前端主动携带恶意页面无法获取这个Token同源策略限制。实现流程用户打开表单页面服务端生成 CSRF Token存入当前SessionToken下发到页面放在隐藏表单域或者放到前端Meta标签input typehidden namecsrf_token value随机字符串用户提交表单时主动带上csrf_token参数后端校验对比请求里的token和session中保存的token一致才放行Token一般一次性或者短期有效防止重放。注意点不要把Token放到Cookie中会被CSRF自动携带失去意义每个会话刷新/每次表单刷新重新生成更佳前后端分离项目一般放到请求头例如X-CSRF-Token。方案2SameSite Cookie 属性现代浏览器推荐轻量化防御Cookie新增SameSite属性控制跨站请求时是否自动携带Cookie是浏览器原生防御。 三个取值SameSiteStrict严格模式只有同站请求才携带Cookie从别的网站跳转过来的请求一律不带Cookie防护最强。缺点从外部链接跳过来会丢失登录态体验较差。SameSiteLax宽松模式浏览器默认跨站GETa标签、链接跳转允许携带Cookie跨站POST、iframe、img、script这类被动请求不再携带Cookie兼顾安全和用户体验绝大多数业务首选。SameSiteNone不限制跨站携带Cookie必须同时搭配Secure只能HTTPS下生效一般跨域第三方嵌入场景才用不安全。优点改动小不需要改造接口下发Token缺点依赖浏览器支持旧浏览器不识别Lax模式下跨站GET依然存在CSRF风险。方案3验证 Referer / Origin 请求头辅助防御不适合单独做主防御Referer告诉服务器请求是从哪个页面跳转过来的Origin标识请求来源站点比Referer更干净不带路径只有域名。思路后端校验来源域名是否属于自己的可信域名白名单不在白名单直接拒绝请求。示例只允许[https://xxx.com](https://xxx.com)发起请求来自其他域名的请求拦截。缺点很大只能辅助Referer可以被客户端某些代理、隐私插件、浏览器设置清除/篡改部分HTTPS跳转HTTP场景浏览器会丢弃Referer攻击者可以找到一些场景清空Referer绕过结论适合作为补充防护不能单独作为唯一防御手段。方案4二次身份校验高敏感操作强制使用针对高危操作转账、修改绑定手机、修改支付密码、注销账号。在原有登录Cookie之外强制增加短信验证码、邮箱验证码、支付密码、人脸验证。 哪怕CSRF发起请求没有验证码后端拒绝执行。属于业务层防御适合高风险接口成本高不会全接口使用。其他辅助误区说明❌ 错误方案只把接口改成POST 很多人以为GET改成POST就防住CSRF错误。攻击者可以自动提交跨站POST表单POST一样会触发CSRF。❌ 错误方案使用黑名单校验Referer 黑名单很容易绕过一律用白名单。✅ 工程上最佳组合方案SameSiteLaxCookie CSRF Token核心接口 高敏感操作验证码精简版CSRF原理攻击者诱导已登录用户访问恶意页面利用浏览器跨站请求自动携带Cookie的特性冒用用户身份发起非自愿业务请求同源策略只限制读取跨站响应不阻止发送跨站请求。 主流防御CSRF Token主流会话绑定随机令牌请求主动携带、后端校验Cookie SameSite 属性浏览器原生控制跨站是否携带CookieOrigin/Referer白名单校验辅助高危操作增加验证码、二次密码校验。