CSRF跨站请求伪造攻击原理与防护方案

一、CSRF攻击的核心原理

CSRF跨站请求伪造是一种利用用户已登录身份发起恶意操作的攻击方式。攻击者构造一个恶意页面或链接，当已登录目标网站的用户访问该页面时，浏览器会自动携带目标网站的Cookie发出请求。服务器无法区分这是用户主动发起的合法请求还是攻击者伪造的请求。

典型的CSRF攻击流程：用户登录银行网站获得Session Cookie且未登出，用户在新标签页访问了攻击者构造的恶意页面，恶意页面自动向银行转账接口提交POST请求，浏览器携带有效Cookie发送请求，服务器验证Session通过处理转账操作。整个过程用户完全不知情。

二、Anti-CSRF Token机制详解

Anti-CSRF Token是目前最广泛使用的CSRF防御方案。服务器为每个用户会话生成一个随机的不可预测的Token值，嵌入在表单的隐藏字段中。当表单提交时，服务器验证Token值与Session中保存的是否一致。由于攻击者无法获取用户的Token值，因此无法构造有效请求。

实现时需注意Token应绑定用户Session，每次提交后建议轮换新Token，Token使用密码学安全的随机数生成器创建，长度至少三十二字节。Token不应通过URL参数传递，只应放在请求体或自定义请求头中。对于AJAX请求可将Token放在自定义HTTP头如X-CSRF-Token中。

三、SameSite Cookie属性配置

SameSite是浏览器提供的新一代CSRF防御机制。该属性有三个取值：Strict模式下Cookie在跨站请求中完全不发送防护最严格但可能影响正常跳转链接，Lax模式允许部分安全请求如GET方式的页面跳转携带Cookie，None模式关闭SameSite保护。

建议核心业务接口使用Strict模式或Lax模式。SameSite属性可在服务端设置Cookie时指定，主流浏览器已全面支持该属性。需要注意的是SameSite并不能完全替代Token验证，因为部分老旧浏览器不支持SameSite属性，因此推荐SameSite加Token的双重防御架构。

四、Referer与Origin头校验

HTTP请求头中的Referer字段记录了请求的来源页面地址。服务器在校验敏感接口时可验证Referer是否来自本站域。如果Referer为空或不合法则拒绝请求。但Referer可能被浏览器隐私模式或代理服务器移除，因此需要同时校验Origin头作为后备方案。

Origin头在POST请求中几乎都会携带，且不会被浏览器移除。校验逻辑为：检查Origin或Referer是否在白名单中，白名单仅包含本站域名及其合法子域名。对于API接口建议要求请求必须携带自定义Header，因为浏览器在跨站请求时无法通过JavaScript设置自定义Header。

五、敏感操作的二次确认

对于修改密码、转账交易、删除数据等高危操作，除了上述技术手段外还应引入用户二次确认机制。常见方案包括弹出确认对话框要求用户主动点击确认、输入登录密码或支付密码、使用短信验证码或邮箱验证码、图形验证码或行为验证码等。

二次确认不仅能防御CSRF攻击，还能防范因用户误操作或被短暂离开工位时他人恶意操作。设计上应遵循关键操作必确认原则，以最短的路径覆盖最高的安全要求。