什么是 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 传递，在其他参数中增加随机加密串进行校验。这里又有两种办法：
- 随机字符串：为每一个提交增加一个随机串参数，该参数服务端通过页面下发，每次请求的时候补充到提交参数中，服务端通过校验该参数是否一致来判断是否是用户请求。由于 CSRF 攻击中攻击者是无从事先得知该随机字符串的值，所以服务端就可以通过校验该值拒绝可以请求。
- JWT：实际上除了 session 登录之外，现在越来越流行 JWT token 登录校验。该方式是在前端记录登录 token，每次请求的时候通过在 Header 中添加认证头的方式来实现登录校验过程。由于 CSRF 攻击中攻击者无法知道该 token 值，通过这种方式也是可以防止 CSRF 攻击的。关于如何在 ThinkJS 中使用 JWT 的话可以参考之前的文章《ThinkJS JWT 鉴权实践》。当然 token 登录方式除了 JWT 之外还有 OAuth 等很多种方式。
后记
除了上面说到的 cookie 登录问题造成的 CSRF 攻击，还有就是增删改等操作使用 GET 请求完成，当该请求未校验登录信息的时候也容易造成 CSRF 攻击。当然这种就比较低级了，不过也还是需要注意。特别是当下 SPA 的流行，越来越多的 AJAX 请求，我们更是要注意 CSRF 攻击的可能。
参考资料：
