CSRF攻击：陌生链接不要随便点|浏览器篇

中我们讲到了 XSS 攻击，XSS 的攻击方式是黑客往用户的页面中注入恶意脚本，然后再通过恶意脚本将用户页面的数据上传到黑客的服务器上，最后黑客再利用这些数据进行一些恶意操作。XSS 攻击能够带来很大的破坏性，不过另外一种类型的攻击也不容忽视，它就是我们今天要聊的 CSRF 攻击。

相信你经常能听到的一句话：“别点那个链接，小心有病毒！”点击一个链接怎么就能染上病毒了呢？

我们结合一个真实的关于 CSRF 攻击的典型案例来分析下，在 2007 年的某一天，David 无意间打开了 Gmail 邮箱中的一份邮件，并点击了该邮件中的一个链接。过了几天，David 就发现他的域名被盗了。不过几经周折，David 还是要回了他的域名，也弄清楚了他的域名之所以被盗，就是因为无意间点击的那个链接。

那 David 的域名是怎么被盗的呢？

我们结合下图来分析下 David 域名的被盗流程：

• 首先 David 发起登录 Gmail 邮箱请求，然后 Gmail 服务器返回一些登录状态给 David 的浏览器，这些信息包括了 Cookie、Session 等，这样在 David 的浏览器中，Gmail 邮箱就处于登录状态了。
• 接着黑客通过各种手段引诱 David 去打开他的链接，比如 hacker.com，然后在 hacker.com 页面中，黑客编写好了一个邮件过滤器，并通过 Gmail 提供的 HTTP 设置接口设置好了新的邮件过滤功能，该过滤器会将 David 所有的邮件都转发到黑客的邮箱中。
• 最后的事情就很简单了，因为有了 David 的邮件内容，所以黑客就可以去域名服务商那边重置 David 域名账户的密码，重置好密码之后，就可以将其转出到黑客的账户了。

以上就是 David 的域名被盗的完整过程，其中前两步就是我们今天要聊的 CSRF 攻击。David 在要回了他的域名之后，也将整个攻击过程分享到他的站点上了，如果你感兴趣的话，可以参考

原理拆解： 攻击者通常看不到受害者的登录 Cookie，但这并不妨碍浏览器在符合 Cookie 发送规则时自动携带它。恶意页面只负责构造对受信任站点的请求，目标服务器看到有效会话后便把请求识别成受害者；若敏感接口没有额外验证请求意图，修改邮箱转发规则、变更绑定信息等操作就会成功。后续的密码重置和域名转移属于业务后果，并不是 CSRF 请求本身。

最小验证： 输入是一台本地服务和浏览器对 /transfer 的请求，要验证仅有会话 Cookie 时会被拒绝，同时具备会话与 CSRF Token 才能修改状态。将代码保存为 csrf-demo.js，用 node csrf-demo.js 启动后访问 http://localhost:3000/。

const http = require('http');

http.createServer((req, res) => {
  if (req.url === '/') {
    res.writeHead(200, {
      'Content-Type': 'text/html; charset=utf-8',
      'Set-Cookie': 'sid=alice; HttpOnly; SameSite=Lax'
    });
    return res.end(`<form method="POST" action="/transfer">
      <input name="csrf" value="token-123">
      <button>提交转账</button>
    </form>`);
  }
  if (req.method === 'POST' && req.url === '/transfer') {
    let body = '';
    req.on('data', chunk => body += chunk);
    return req.on('end', () => {
      const loggedIn = (req.headers.cookie || '').includes('sid=alice');
      const validToken = new URLSearchParams(body).get('csrf') === 'token-123';
      res.writeHead(loggedIn && validToken ? 200 : 403);
      res.end(loggedIn && validToken ? 'transfer accepted' : 'forbidden');
    });
  }
  res.writeHead(404).end();
}).listen(3000, () => console.log('http://localhost:3000/'));

表单正常提交时预期得到 transfer accepted；删除隐藏值或用不含令牌的表单提交时得到 forbidden。示例令牌为固定值，仅用于展示校验链路，生产系统应生成不可预测且绑定会话的令牌。

边界与排查： SameSite 能降低跨站携带 Cookie 的概率，但旧客户端、错误属性和特定跳转链路可能削弱保护，不能代替服务端校验。XSS 若已能读取页面或代替用户调用接口，也可能绕过页面中的令牌防线。排查时应核对敏感接口是否拒绝无令牌请求，并检查 Origin、Referer、Cookie 属性、审计日志及状态变更记录。