目标网站未校验请求来源服务器仅依赖Cookie判断身份不验证请求是否由用户本人真实发起。攻击者能构造恶意请求攻击者可以诱导用户访问一个恶意页面或点击恶意链接该页面会自动向目标网站发起请求。 经典攻击流程示例假设某银行的转账接口是POST /transfer 参数toAccount目标账户amount金额正常流程用户在银行网站填写表单 → 点击转账 → 浏览器带上用户的Cookie发送请求。CSRF攻击流程用户登录银行网站获得合法Cookie。攻击者构造一个恶意页面包含一个隐藏表单或图片链接!-- 恶意网站 evil.com 上的代码 -- img srchttps://bank.com/transfer?toAccountattackeramount10000 styledisplay:none用户访问恶意网站可能是通过钓鱼邮件、垃圾广告等诱导。浏览器自动加载图片 → 自动携带用户在bank.com的Cookie → 发送转账请求。银行服务器校验Cookie通过→ 误以为是用户本人操作 → 执行转账。二、CSRF攻击的主要体现形式攻击方式原理典型场景GET型恶意链接或图片自动触发GET请求img srchttps://target.com/delete?id123POST型自动提交隐藏表单或Ajax请求form actionhttps://target.com/changeEmail methodPOST自动提交JSON型利用JavaScript发送JSON格式的API请求通过fetch或XMLHttpRequest自动发送实际案例修改密码用户访问恶意页面自动发送修改密码请求把密码改成攻击者指定的。发表言论在用户不知情下自动发送带恶意链接的微博/论坛帖子。购物下单自动把商品加入购物车并下单寄送到攻击者地址。三、CSRF vs XSS关键区别维度CSRFXSS本质利用身份认证机制的漏洞利用用户输入输出的漏洞是否需要用户执行代码需要用户点击恶意链接/访问恶意网站目标网站自己执行了恶意代码与目标网站关系利用目标网站对请求来源的信任利用目标网站对用户输入的信任是否需要注入脚本不需要攻击代码在第三方网站需要代码注入到目标网站防范难度相对容易参考下文较难需要全面过滤一句话总结XSS攻击代码在目标网站上运行窃取用户信息或控制页面。CSRF攻击代码在第三方网站上运行利用用户已登录的身份执行操作。四、防御CSRF的核心方案实战建议✅ 1.使用CSRF Token最经典有效服务器生成一个随机的、不可预测的Token嵌入到表单或请求头中服务器验证必须携带正确的Token。!-- 服务器返回的页面包含Token -- form action/transfer methodPOST input typehidden namecsrf_token valuerandom_token_abc123 转账金额: input typetext nameamount /form工作流程用户请求表单页面 → 服务器生成Token存入Session并返回给表单。用户提交表单 → 必须携带该Token。服务器验证Token是否匹配 → 不匹配则拒绝请求。优点攻击者无法获取该Token因为同源策略限制恶意网站无法读取目标网站的页面源码。缺点需要所有修改状态的操作都嵌入Token实现成本稍高。✅ 2.SameSite Cookie属性现代浏览器推荐设置Cookie的SameSite属性限制第三方域名发起的请求携带Cookie。Set-Cookie: session_idxyz123; SameSiteLax; Secure; HttpOnlySameSite取值Strict任何跨站请求都不带Cookie最安全但可能影响正常的外链跳转。Lax顶级导航如点击链接带Cookie但POST表单、iframe、img等不带推荐。None跨站请求也带Cookie但必须同时设置Secure仅HTTPS。优点无需修改后端代码配置简单兼容主流现代浏览器除IE外。缺点旧浏览器不支持如IE 11。✅ 3.验证Referer/Origin头检查请求头中的Referer或Origin是否与当前站点域一致。def is_valid_request(request): referer request.headers.get(Referer) if not referer: return False return referer.startswith(https://yourdomain.com)优点实现简单无需额外存储。缺点某些场景下Referer可能缺失如HTTPS到HTTP、用户隐私设置部分低版本浏览器可伪造。✅ 4.二次验证高安全场景对于敏感操作修改密码、转账、手机解绑等要求用户重新输入密码/短信验证码/图形验证码。举例网银转账超过一定金额必须输入短信验证码。优点彻底防御CSRF即使Token泄露也无法绕过。缺点影响用户体验仅适用于高敏感操作。✅ 5.使用自定义请求头针对API要求所有API请求必须携带一个自定义Header如X-Requested-With: XMLHttpRequest因为跨域请求无法设置自定义Header除非CORS明确允许。// 前端Ajax请求自动添加 fetch(/transfer, { headers: { X-Requested-With: XMLHttpRequest } })注意这要求所有请求都是Ajax方式传统表单提交不适用。五、总结与最佳实践推荐防御组合分层防御纵深保护基础层使用CSRF TokenSameSiteLax Cookie现代框架如Django、Spring、Rails均内置支持。增强层敏感操作加入二次验证密码/验证码。兜底层验证Referer/Origin作为辅助检测。常见误区❌ 仅依赖POST请求就认为安全攻击者同样可以伪造POST表单。❌ 使用验证码防御所有请求体验差不适合每个操作。❌ 认为SameSite能100%防御旧浏览器不支持且仅限制Cookie携带无法防御已窃取到Token的场景。框架内置支持DjangoCsrfViewMiddleware默认开启Spring SecurityCsrfFilter默认开启Express (Node.js)csurf中间件Laravel (PHP)VerifyCsrfToken中间件