如果一个网站存在csrf漏洞 可以通过

一个链接，网站偷走你的通过登录态。这听起来像魔术，网站但CSRF（跨站请求伪造）就是通过这么干的——它不偷你的密码，它直接借用你浏览器里还热乎的网站Cookie，替你在别处“发号施令”。通过

举个我亲历的网站例子。几年前我测试一个本地论坛，通过管理员后台有个“一键删帖”功能，网站URL长这样：/admin/delete?通过post_id=123。我注册了个普通账号，网站发了个帖子，通过然后构造了一个恶意页面，网站里面藏了个隐藏的通过img标签，src指向那个删帖URL，网站只不过post_id换成了管理员的帖子。我把这个页面链接发给管理员，他一点，浏览器自动请求了那个URL——他的Cookie跟着请求过去了，帖子没了。他全程没输密码，没点确认，就是“看了一眼”我的链接。

问题出在哪？服务器只验证了“你是不是登录了”，却没验证“这个请求是不是你本人主动发起的”。Cookie是浏览器自动带的，请求是浏览器自动发的，服务器傻傻分不清。

所以，CSRF的核心攻击面不是你的密码，而是你浏览器里那个“默认信任”的会话。攻击者不需要知道你登录了哪个网站，他只需要知道那个网站有哪些“敏感操作”的URL长什么样。

防御手段其实不复杂。最直接的是加一个随机的、绑定会话的token——每次表单提交都带上它，服务器比对一下，对不上就拒绝。这个token攻击者猜不到，也拿不到，因为跨域请求读不到响应内容。另一种是检查请求的Referer头，但那个容易被伪造，不太靠谱。还有更狠的，比如要求二次确认密码，或者用SameSite=strict的Cookie，让跨站请求压根不带Cookie。

但说实话，很多小网站根本不设防。我见过一个电商后台，修改收货地址的接口是GET请求，参数全在URL里。这种设计等于把大门钥匙挂在门口——攻击者甚至不需要诱导点击，塞个图片标签就能触发。

别以为CSRF是老古董。2023年还有报告指出，主流CMS插件里仍能找到这类漏洞。原因很现实：开发图省事，把敏感操作写成GET，或者token存了但不校验。你问为什么？因为CSRF不像XSS那样能直接弹窗炫技，它更像“无声的盗窃”，测试时不容易被发现，上线后也难追踪。

最后说个反直觉的点：CSRF的受害者往往是“已登录用户”，而不是匿名访客。所以，如果你是个普通用户，最实用的防护是——别在浏览器里同时登录多个敏感账户，或者用隐私窗口处理重要操作。别嫌麻烦，这比指望每个网站都写对代码靠谱得多。