CSRF漏洞复现

凌晨两点，漏洞我盯着浏览器里的复现转账成功页面，后背发凉。漏洞那笔钱不是复现我转的，但确实从我的漏洞账户出去了。整个过程我只做了一件事——点开了一个论坛帖子里的复现图片链接。

这就是漏洞CSRF（跨站请求伪造）的可怕之处。它不攻击你的复现密码，不破解你的漏洞验证码，它只是复现利用你的浏览器，替你向服务器发送了一个“合法”的漏洞请求。你本人就是复现攻击的帮凶，而且毫无察觉。漏洞

复现这个漏洞，复现技术上并不复杂。漏洞我搭了个简单的银行模拟站，用户登录后可以转账，请求是GET方式的/transfer?to=xxx&amount=100。别笑，很多老旧系统内部接口确实这么写。然后我在另一个域名的页面上放了这么一段代码：

<img src="http://bank.local/transfer?to=hacker&amount=1000" style="display:none">

受害者只要在银行站保持登录状态（Cookie没过期），再访问我这个恶意页面，浏览器就会自动请求那个图片地址。服务器收到请求，检查Cookie，发现会话有效，直接执行转账。受害者完全无感，因为图片加载失败不会显示任何东西，页面看起来一切正常。

我第一次跑通这个流程时，说实话有点震撼。攻击者不需要知道受害者的任何敏感信息，不需要绕过密码，甚至不需要诱导用户点击按钮。只要用户“看过”恶意页面，攻击就完成了。这就像有人借你的手，在你不知情的情况下签了份合同。

更麻烦的是，POST请求也拦不住。用表单自动提交就行，一个隐藏的iframe加一段JavaScript就能实现。防护手段的核心其实就一条：验证请求来源。服务器得确认这个请求是用户主动发出的，而不是某个第三方页面偷偷代发的。

最有效的办法是CSRF Token。服务器生成一个随机值存在会话里，每次提交表单时带着这个Token，服务器比对一致才处理请求。恶意页面拿不到这个Token，伪造的请求自然失效。另一个办法是检查Origin或Referer头，但这两个头有时候会被浏览器省略，所以只能作为辅助。

我这几年看过不少真实案例，CSRF经常和XSS配合使用。XSS负责偷Token或注入恶意脚本，CSRF负责静默执行操作。单独看每个漏洞好像危害有限，组合起来能直接掏空账户。最讽刺的是，有些开发者觉得“只要用POST请求就安全了”，结果被一个自动提交的表单打得满地找牙。

复现这个漏洞最大的收获不是技术细节，而是一种思维转变——别相信任何来自浏览器的请求。请求头可以伪造，Referer可以屏蔽，Cookie可能被窃取。唯一可靠的，就是每次请求都带上一个攻击者无法预知的随机校验值。安全不是靠隐藏接口地址，也不是靠“没人会这么干”的侥幸，而是靠每一层都设计得默认不信任。

现在每当我看到某个网站登录后直接能用GET请求修改资料，或者表单里没有隐藏Token字段，我都会下意识地警觉。这不是矫情，是吃过亏之后的肌肉记忆。