什么是csrf漏洞

你登录了网上银行，准备转一笔钱给朋友。页面正常，密码输入正确，验证码也对了。钱转出去了，但收款人不是朋友，而是一个你从未见过的账户。整个过程你没有任何失误，甚至没发现任何异常。这不是科幻电影，这就是CSRF漏洞干的好事。

CSRF，全称Cross-Site Request Forgery，中文叫跨站请求伪造。名字听着绕口，实际意思很直白：攻击者借你的手，发一条你不知情的请求。关键在于，这条请求是从你的浏览器发出的，带着你的登录状态，服务器根本分不清是你点的还是别人伪造的。它信任的是你的身份，不是你的意图。

举个最常见的例子。假设你正在逛一个论坛，同时开着网银的标签页，网银还没退出登录。这时候有人在论坛帖子里放了一张图片，图片的地址不是一张jpg，而是一个转账链接——比如http://bank.com/transfer?to=黑客账户&amount=10000。你的浏览器看到这张“图片”，自动发起GET请求，网银服务器收到请求，发现你已登录，就执行了转账。你什么都没干，钱就没了。

有人会说，那我不点链接不就行了？问题是，这种攻击根本不需要你点击。图片、iframe、ajax请求，甚至一个简单的表单自动提交，都能触发。你只是打开了一个网页，背后可能已经发生了好几笔“合法”交易。更阴险的是，攻击者还能用JavaScript在后台偷偷提交表单，你连页面闪烁都看不到。

那服务器端是怎么中招的？很多老系统的接口设计得过于宽松。它们只用Cookie来判断用户身份，而Cookie是浏览器自动带上的。只要你的会话没过期，任何来自你浏览器的请求都会被视为你本人操作。服务器压根没验证这个请求是不是真的从你正在操作的页面发出来的。它缺少一个校验机制：请求的来源是否可信。

修复CSRF的常规做法，是在表单里加一个随机token。这个token是服务器生成、存在你会话里的，每次提交表单时必须带上。攻击者伪造的请求拿不到这个token，服务器一比对就知道不对劲。还有检查Referer头，看请求是从哪个页面来的，但这个方法不太可靠，有些浏览器或代理会去掉Referer。更稳妥的是双重验证，比如要求输入密码或短信验证码，但这对用户体验是个负担。

我见过不少开发者在项目初期根本不在乎这个。他们觉得，我接口都是JSON格式，别人没法用表单提交。这想法太天真了。JSON接口照样能被跨域请求，只是需要多一步预检请求，但有些服务器配置不当，照样放行。还有人说，我们用了HTTPS，应该安全了吧？HTTPS只加密传输，不解决信任问题。CSRF跟加密没关系，它利用的是你浏览器里的会话凭证。

说个我亲身碰到的案例。前两年给一家电商公司做安全审计，发现他们的用户修改收货地址接口完全没有防护。攻击者只需要构造一个页面，诱导用户访问，就能把用户的默认收货地址改成自己的，然后下单时系统自动填了那个地址。受害者浑然不觉，直到包裹寄丢了才发现。这漏洞修起来就一行代码的事，但没人意识到风险，直到出了事。

说到底，CSRF漏洞的本质是身份认证和操作意图的脱节。服务器确认了“你是谁”，却没确认“你是不是真的想干这件事”。就像你出门时把钥匙放在门口花盆底下，小偷不用撬锁，直接拿了钥匙开门就行。别觉得这事儿离你远，只要你用过带登录状态的网站，就暴露在风险里。开发者的责任，就是别让用户为这种低级失误买单。

很赞哦!（34594）