前端安全：简单来认识CSRF

这是我参与更文挑战的第2天，活动详情查看： 更文挑战

最近想了解一下 CSRF 的原理，看了一些文章，懂了是懂了一点，然后自己也想整理回顾一下，于是便有了这篇文章。

CSRF介绍

先来看看mdn对 CSRF 上的解释

CSRF（Cross Site Request Forgery），简称跨站请求伪造，是一种冒充受信任用户，向服务器发送非预期请求的攻击方式。

简单来说， CSRF是攻击者在用户不知情的情况下，通过冒用用户的cookie，向后台发送请求，后台识别到用户的cookie，认为攻击者就是用户的身份，从而导致请求成功的操作。

CSRF攻击流程

下面我用一张图来说明一下

主要流程：

1. 首先用户在网站A进行登录操作，登录成功后产生cookie存在于浏览器中；
2. 在网站A通过某些操作打开了危险网站B，这时候，危险网站B请求了网站A的接口（危险），因为这时候会带着cookie进行访问
3. cookie认证成功，服务器认为是用户本人，请求成功，则达到了攻击的目的了；

防御机制

根据上面的流程分析，主要是身份通过cookie认证不太安全；
那如果要防御就得从cookie这边着手

SameSite

谷歌新增的一个针对cookie的属性，主要是用来限制第三方cookie，也就是说可以限制危险网站B不能冒用网站A的cookie

可选值有三个：

1. Strict

严格模式，完全限制第三方cookie。任何情况下都不会直接发送cookie，除非新打开的网站和本身的网站是同域的。
有个不好的点就是，就是如果我有外链打开这个网站，如果我之前登陆过，现在又得重新登录一遍，会影响体验；

2. Lax

宽松模式，大部分不会直接发送cookie，只有在打开的链接是get请求(比如GET 表单,a链接)除外；

Google80及以上会使用该值为默认值

3. None

完全不限制，第三方可以使用cookie，但是需要设置secure属性（通过https访问）；

同源检测

既然第三方会冒用cookie，那么就可以验证请求的来源是哪个，可以通过headers里面的origin和refer属性可以知道第三方的来源，判断是来源是一致的才处理该请求；

token认证

另外我们可以通过增加token验证来防御，这个token是由服务端生成；客户端存储（但是token不能存储在cookie），然后请求发出的时候戴上这个token，后端在服务端验证这个token是否准确

验证码

我们在提交请求的时候，需要用户输入验证码才能提交，通过增加验证码的校验，这样第三方也不能窃取到当前页面的验证码，也能防范，只不过体验不是很好（因为每次请求都得输入验证码）

还有别的认证方法（比如cookie双重认证等等），这里就只讲一些常见的

总结

这就是我总结的的CSRF入门了解，我们虽然是前端（俗称页面仔，开个玩笑），安全问题我们可能有时候不一定能接触到，但是我们还是了解一下，因为说不定哪天就派上用场了。