跨站请求伪造怎么解决

跨站请求伪造（CSRF）的跨站解决办法，说白了就一句话：让服务器认得出，请求这个请求是伪造用户主动发的，而不是解决黑客伪造的。但这句话背后藏着不少坑，跨站我见过太多团队栽在“以为加了Token就万事大吉”上。请求

先讲个真实案例。伪造去年我帮一个电商平台做安全审计，解决他们的跨站后台管理接口全部加了CSRF Token，看起来固若金汤。请求结果我发现，伪造他们的解决Token是存在localStorage里的，而且前端用AJAX请求时，跨站会从localStorage取出Token放到请求头。请求这就有意思了——如果黑客能往你的伪造页面注入一段脚本，就能直接读取localStorage里的Token。更讽刺的是，他们为了防CSRF，却忽略了XSS（跨站脚本攻击）这个更大的漏洞。CSRF和XSS往往是一对孪生兄弟，光防一个不够。

最基础的解决办法，是同步令牌模式。服务器在渲染页面时生成一个随机Token，存在用户的Session里，同时把这个Token埋进表单的隐藏字段。用户提交表单时，服务器比对提交的Token和Session里的Token是否一致。不一致就拒绝请求。这个方案简单可靠，但有个致命弱点——如果页面被XSS攻击，Token照样会被偷走。而且对于前后端分离的架构，你得额外处理Token的传递方式，不能像传统表单那样直接塞进HTML里。

更现代的做法是双重提交Cookie模式。服务器不存Session，而是生成一个Token，同时写入Cookie和请求参数。服务器收到请求后，比对Cookie里的Token和请求参数里的Token是否一致。这个方案的巧妙之处在于——攻击者无法跨域设置Cookie，所以即使他伪造了请求参数，也没法让浏览器带上正确的Cookie。但这里有个细节很多人忽略：你得确保Cookie的SameSite属性设置正确。我见过不少团队，Token机制做得很好，结果Cookie没设SameSite=Lax或Strict，攻击者照样可以通过跨站请求带上Cookie。

说到SameSite，这算是现代浏览器给的“免费午餐”。只要把Cookie的SameSite属性设为Strict，浏览器就只在同站请求时才会带上Cookie。这意味着，即使攻击者构造了一个恶意页面，诱导用户点击提交按钮，浏览器也不会把目标网站的Cookie发过去——因为请求是跨站的。这个方案几乎零成本，但有个问题：如果你有合法的跨站跳转需求（比如从支付平台跳回你的网站），Strict会把这个流程打断。所以很多人退而求其次用Lax，允许GET请求带Cookie，但POST请求不行。这基本能挡住绝大多数攻击。

还有个偏门但有效的办法——检查请求头中的Origin或Referer。服务器只接受来自自己域名的请求，如果Origin不是自己的域名，直接拒绝。这个方案简单粗暴，但要注意：Referer有时候会被浏览器省略（比如从HTTPS跳到HTTP），而Origin在有些老浏览器里支持不好。所以它更适合作为辅助手段，而不是唯一防线。

我个人的建议是，别迷信单一方案。最佳实践是组合拳：首先，所有写操作（POST、PUT、DELETE）必须用Token验证；其次，给所有关键Cookie设置SameSite=Lax；最后，在服务器端检查Origin头。三层防御，哪一层被绕过，另外两层还能兜底。这就像给门上了三道锁，虽然每道锁都能被撬开，但一起撬开三道锁的难度就大多了。

最后说个反直觉的观察——很多安全漏洞不是技术问题，而是设计问题。比如，如果你的API设计成“GET请求也能改数据”，那再强的CSRF防护也白搭。因为黑客可以用<img src="http://你的网站/delete?id=1">这种标签，让浏览器自动发GET请求。所以，从根源上规范API设计，让写操作必须用POST，这本身就是一种CSRF防御。别光想着加Token，先检查你的接口设计是否合规。