CSRF攻击能做哪些事情

你正登录着网上银行，顺手点开一个论坛帖子。事情帖子里的攻击图片链接指向 bank.com/transfer?to=hacker&amount=10000。浏览器带着你的事情银行Cookie发了这个请求。钱没了。攻击这就是事情CSRF——跨站请求伪造。它不偷Cookie，攻击它让浏览器替你发请求。事情

CSRF能做的攻击事情，取决于你当前登录了什么网站、事情那个网站有什么功能。攻击我见过最离谱的事情案例，是攻击一个路由器管理后台。攻击者构造一个表单，事情自动提交到 192.168.1.1/setup.cgi，攻击把DNS服务器改成恶意地址。用户只要访问了恶意页面，家里所有设备的流量就全被劫持了。整个过程用户毫无感知，页面甚至没刷新。

银行转账是经典场景。假设某银行转账接口是GET请求：https://bank.com/transfer?to=xxx&amount=xxx。攻击者只需在恶意页面放一个 <img src="https://bank.com/transfer?to=attacker&amount=5000">。你打开页面，图片加载失败？无所谓。请求已经发出，钱已经转了。当然现在大银行不会用GET做转账，但很多中小网站的后台管理功能还在这么干。

社交平台是另一个重灾区。2018年某知名社交网站爆过一个漏洞：关注接口没有CSRF防护。攻击者可以构造一个页面，让访问者自动关注指定账号。一个营销号靠这个漏洞，一天涨了十几万粉丝。更狠的是发帖功能——攻击者能让你的账号自动发布一条带有恶意链接的推文。你的好友看到是你发的，点击率飙升。

改邮箱、改密码这类操作，CSRF同样能完成。前提是这些操作不需要旧密码验证。我测试过一个开源电商系统，修改收货地址的接口只验证了Cookie。攻击者可以把你默认收货地址改成他的，然后等你下次下单——货直接寄到他那儿。你付了钱，他收了货。

企业内网是CSRF的“富矿”。很多内部系统默认内网安全，不做CSRF防护。比如OA系统、GitLab、Jenkins。攻击者可以构造一个页面，让访问它的员工自动在Jenkins上执行构建脚本，或者给GitLab仓库添加一个后门。员工只是点了个链接，内网就沦陷了。

还有一种隐蔽玩法：CSRF配合JSONP或CORS。比如某网站用JSONP返回用户信息，攻击者可以构造 <script src="https://site.com/userinfo?callback=steal">，虽然这更接近信息泄露，但如果接口有写操作，比如 ?callback=doSomething&action=delete，那就直接变成CSRF了。

CSRF不能做什么？它不能读取响应。你发了转账请求，但攻击者看不到余额。所以单纯的信息窃取不是CSRF的强项。它擅长的是“盲操作”——只要请求发出去了，效果就达到了。所以那些不需要返回值的写操作，都是CSRF的靶子。

防御CSRF的标准做法是加Token。但现实很骨感。我见过太多开发者只在登录接口加Token，其他接口全裸奔。也见过用Referer校验的，但用户从HTTPS跳转到HTTP时Referer会丢失，结果正常用户被误拦。还有把Token放在Cookie里的——这等于没加，因为CSRF攻击本来就会带上Cookie。

最讽刺的是，很多网站对CSRF的防护还不如对XSS的防护上心。XSS能偷Cookie，CSRF不能。但CSRF能直接造成资金损失和权限变更，XSS反而需要配合其他漏洞才能达到同样效果。安全圈有个说法：XSS是偷钥匙，CSRF是直接用你的钥匙开门。哪个更危险？取决于门后面是什么。

下次你登录网银后，别随便点陌生链接。浏览器很听话，你让它带Cookie发请求，它绝不问为什么。CSRF利用的就是这份“听话”。