什么是 CSRF

在了解 CSRF 之前我们需要科普两个前提。首先是登录权限验证的方式有很多种，目前绝大多数网站采用的还是 session 会话任务的方式。session 机制简单的来说就是服务端使用一个键值对记录登录信息，同时在 cookie 中将 session id（即刚才说的键）存储到 cookie 中。另外我们又知道浏览器中 HTTP(s) 请求是会自动帮我们把 cookie 带上传给服务端的。这样在每次请求的时候通过 cookie 获取 session id，然后通过它在服务端获取登录信息即可完成用户权限的校验。

本来这也是个不错的功能。但是由于 cookie 实在是太开放了，如果一个用户在 A 网站登录了，如果用户在 B 网站访问的时候发送了一个 A 网站的请求，那么这个请求其实是带有这个用户在 A 网站的登录信息的。如果这时候 B 站的 A 网站请求是用户不知道的，那就是非常严重的危害了。以上的过程就是跨站请求攻击，即 Cross-Site Request Forgery，即 CSRF。

CSRF 的危害

简单总结 CSRF 漏洞就是利用网站权限校验方面的漏洞在用户不知觉的情况下发送请求，达到“伪装”用户的目的。攻击者利用 CSRF 实现的攻击主要有以下几种：

攻击者能够欺骗受害用户完成该受害者所允许的任一状态改变的操作，比如：更新账号细节，完成购物，注销甚至登录等操作
获取用户的隐私数据
配合其他漏洞攻击
CSRF 蠕虫

其中 CSRF 蠕虫如其名所指就是产生蠕虫效果，会将 CSRF 攻击一传十，十传百。如：某社区私信好友的接口和获取好友列表的接口都存在CSRF漏洞，攻击者就可以将其组合成一个CSRF蠕虫——当一个用户访问恶意页面后通过CSRF获取其好友列表信息，然后再利用私信好友的CSRF漏洞给其每个好友发送一条指向恶意页面的信息，只要有人查看这个信息里的链接，CSRF蠕虫就会不断传播下去，其可能造成的危害和影响非常巨大！

防御方法

从上文的描述中我们可以知道 CSRF 有两个特点：利用 cookie 自动携带的特性以及跨站攻击。那么针对这两个特性可以使用如下解决方法。

检查 Referer 字段

大家都知道 HTTP 头中有一个 Referer 字段，这个字段用以标明请求来源于哪个地址。通过在网站中校验请求的该字段，我们能知道请求是否是从本站发出的。我们可以拒绝一切非本站发出的请求，这样避免了 CSRF 的跨站特性。

const { parse } = require('url');
module.exports = class extends think.Logic {
  indexAction() {
    const referrer = this.ctx.referrer();
    const {host: referrerHost} = parse(referrer);
    if(referrerHost !== 'xxx') {
        return this.fail('REFERRER_ERROR');
    }
  }
}

同样以 ThinkJS 为例，只要在 Logic 中简单判断下即可。这种方式利用了客户端无法构造 Referrer 的特性，虽然简单，不过当网站域名有多个，或者经常变换域名的时候会变得非常的麻烦，同时也具有一定的局限性。

Token 验证

由于 CSRF 是利用了浏览器自动传递 cookie 的特性，另外一个防御思路就是校验信息不通过 cookie 传递，在其他参数中增加随机加密串进行校验。这里又有两种办法：

后记

除了上面说到的 cookie 登录问题造成的 CSRF 攻击，还有就是增删改等操作使用 GET 请求完成，当该请求未校验登录信息的时候也容易造成 CSRF 攻击。当然这种就比较低级了，不过也还是需要注意。特别是当下 SPA 的流行，越来越多的 AJAX 请求，我们更是要注意 CSRF 攻击的可能。

参考资料：