简述csrf漏洞

一个真实的简述案例：2018年，某大型电商平台的漏洞安全团队发现，攻击者仅凭一个精心构造的简述图片链接，就能让已登录的漏洞用户在不知情的情况下修改自己的收货地址。用户什么都没做，简述只是漏洞浏览了包含恶意图片的网页，账户就被操控了。简述这不是漏洞钓鱼，不是简述病毒，而是漏洞CSRF——跨站请求伪造。

CSRF的简述核心逻辑其实特别朴素：浏览器会自动携带Cookie。你登录了银行网站，漏洞浏览器里存着银行的简述会话凭证。这时候你又打开了另一个恶意网站，漏洞这个网站里藏着一个指向银行转账接口的简述请求。浏览器看到这个请求，二话不说就把你的Cookie也带上了。银行服务器一看，Cookie有效，用户身份验证通过，那就执行吧。

问题就出在“服务器无法区分这个请求是用户主动发出的，还是被第三方网站诱导发出的”。换句话说，服务器信任了浏览器的“自动附带凭证”机制，却没验证请求的“意图”。这就像你把自己的家门钥匙复制了一份放在门口地毯下，任何路过的人都能用这把钥匙打开你的门，而门锁不会问一句“你真的是主人吗”。

我见过最经典的攻击场景是在一个论坛里。攻击者发了一个帖子，帖子里嵌入了这样一个图片标签：<img src="http://victim-site.com/changePassword?newpass=hacker123">。受害者登录着论坛，也登录着另一个同浏览器的网站——那个网站恰好有个改密码的接口，而且用的是GET请求。图片加载时，浏览器就向那个改密码的URL发了个请求，密码就这么被改了。

这里有个容易被忽略的细节：CSRF攻击不需要拿到你的Cookie，也不需要破解你的密码。它只是“借用”了你浏览器的身份凭证。攻击者甚至看不到你Cookie的内容，但这不重要，重要的是服务器收到了一个带着有效Cookie的请求。这就像有人偷了你的工牌复印件，虽然他没拿到原件，但门禁系统只认卡不认人，照样放行。

修复CSRF的手段其实也不复杂。最常用的是加一个随机的token：服务器在渲染页面时生成一个一次性token，放入表单的隐藏字段。提交请求时，服务器会检查这个token是否匹配。攻击者构造的恶意请求里没有这个token，自然就被拦下来了。另一个办法是检查请求的Referer头，但这个方法不太可靠，因为有些浏览器或代理会去掉Referer。

还有个有意思的现象：很多开发者觉得用了POST请求就安全了，其实不然。攻击者可以用隐藏表单自动提交POST请求，甚至用JavaScript的fetch方法。只要请求能被跨域发出，方法本身不构成防御。真正有效的还是token、SameSite Cookie属性这类机制——SameSite属性可以限制Cookie在跨站请求时不被发送，算是从源头堵住了漏洞。

说实话，CSRF在今天的互联网里已经不算什么新潮漏洞了，但它依然顽强地存活在很多老旧系统里。我去年还见过一个政府网站的后台管理系统，改管理员密码的接口连个token都没加。这种问题为什么反复出现？多半是开发者图省事，觉得“内部系统没人攻击”，可攻击者最喜欢的就是这种“没人会攻击”的系统。

你只需要记住一个判断标准：凡是能改变状态的请求——改密码、转账、删数据、发消息——都必须验证请求来源。别把浏览器的自动凭证机制当成理所当然的安全保障，它只是便利，从来不是安全。