登录人力资源网站，登录到刚输完账号密码，人力页面跳转的资源瞬间，我瞥见地址栏里多了一串陌生的网站参数——?token=4f8a2b9c。这串字符不该出现在这里。检测击我手动删掉它，登录到重新提交登录表单，人力系统提示“会话失效”。资源再试一次，网站带着那个token，检测击登录成功。登录到

这不是人力巧合。人力资源网站存着员工的资源身份证号、银行卡、网站薪资明细、检测击家庭住址，甚至体检报告。攻击者盯上的正是这些数据。CSRF（跨站请求伪造）攻击的逻辑很简单：你登录了网站，浏览器里存着有效的会话cookie，攻击者构造一个恶意链接或页面，诱导你点击，浏览器自动携带cookie发起请求，服务器以为是你在操作，于是执行了攻击者预设的动作——比如修改你的银行卡号，或者把薪资详情发送到指定邮箱。

我检查了那个token的生成逻辑。它并不随机，而是基于用户ID和时间戳的简单拼接。这意味着攻击者只要知道你的登录时间，就能预测出token值。更糟的是，网站对token的校验只存在于登录接口，其他敏感操作——比如修改手机号、导出工资条——根本没有防护。攻击者完全可以构造一个自动提交的form表单，藏在某个论坛帖子里，等你点开。

测试过程比预想中顺利。我用两个浏览器模拟不同用户，一个正常登录，另一个伪造请求。当伪造请求成功修改了用户A的紧急联系人时，我后背有点发凉。这不是实验室环境，这是生产系统。攻击者不需要高超的技术，只需要一封钓鱼邮件，或者一个植入恶意脚本的广告位，就能完成整个攻击链。

人力资源部门的同事还蒙在鼓里。他们以为网站有SSL证书就安全了，以为密码复杂度够高就万无一失。但CSRF攻击根本不碰密码——它利用的是“信任”，信任浏览器携带的cookie就是用户本人。这种信任在Web应用里根深蒂固，几乎每个框架默认都信任会话cookie。

修复方案其实不复杂。加一个真正的随机token，绑定在会话里，每次请求都校验；或者改用自定义请求头，因为跨域请求无法自定义头部；再或者，验证Referer字段，虽然这个字段可以被伪造，但至少能挡住大部分低水平攻击。问题是，开发团队有没有意识去做这些？还是说，等出了事再补救？

我关掉测试环境，给安全团队写了份报告。结尾只留了一句：这个洞，今天是我发现的，明天可能就是别人的。