Cookie与CSFR
最近在做重构项目时，发现了其中使用了SCRF Token用于防御CSRF攻击，它是这样实现的页面加载时调用后端的一个接口，这个接口做的事情只有一个，就是往cookie里写入了一个csrft-token的字段。疑惑了很久，这样可以防御CSFR？这不是妥妥的自欺欺人吗？？？
查阅了相关资料，了解了一下Cookie和CSFR相关的知识，记录一下-。-
Cookie
1.是什么
以下来自维基百科
Cookie复数形态：Cookies），又称“小甜饼”。类型为小型文本文件，指某些网站为了辨别用户身份而储存在用户本地终端（Client Side）上的数据（通常经过加密)
所以，Cookie是一个小型文本文件，存储在用户本地，用于辨别用户身份。一般不超过 4KB ，由一个名称（Name）、一个值（Value）和其它几个用于控制 Cookie 有效期、安全性、使用范围的可选属性组成。
这里关于Cookie的更多知识，贴一个文章，写得很好。
2.为什么
为什么需要Cookie? Cookie用来解决什么问题？
HTTP是无状态的，服务端在接收到请求时，并不知道这个请求是来自于谁，这时候某些与用户相关的操作，就无法实现。所以，需要一个可以用于携带与用户有关的信息的东西，用于告诉服务端，这个请求是谁发起的，Cookie就承担了这个责任。
3.怎么做
3.1那么Cookie是如何发送到服务端的呢？
在请求时，Request Headers中，会携带一个Cookie字段，会和请求一起到达服务端，服务端通过解析这个字段获取Cookie
3.2Cookie里带了什么呢
刚刚提到，Cookie这个文本内容是落在用户本地的，那么如果存在Cookie,每次就都会带上吗？每个请求带的内容都一样吗？
答案是否定的，如果是这样，那不是你在网上冲浪的时候，带着你本地的Cookie到处发？如果这里面保存了一些你的基本信息，这样到处发，那不是全世界都知道了？
Cookie的每一条内容，发给谁，其实都是由该条内容的特定属性字段来控制的。
- Domain属性
这个属性指定了 Cookie 可以送达的主机名。假如没有指定，那么默认值为当前文档访问地址中的主机（域名）部分（但是不包含子域名）。
比如你在https://fanyi.baidu.com这个域名被写入的Cookie，就由这个域名的服务通过set-cookie时候的Domain属性来控制发给谁，如果它在写入的时候，没有指定这个属性，那么默认是当前的域名，即fanyi.baidu.com。
需要注意的是，不能跨域设置 Cookie，比如百度域名下的页面把 Domain 设置成谷歌是无效的。 - Path
指定了一个 URL 路径，这个路径必须出现在要请求的资源的路径中才可以发送 Cookie 首部。比如设置 Path=/docs，/docs/Web/ 下的资源会带 Cookie 首部，/test 则不会携带 Cookie 首部。
综上，这条Cookie值可以发给谁，是由这条Cookie的Domain 和 Path 标识共同定义的。
3.3Cookie如何设置呢
Cookie可以由服务端通过Response Headers中的Set-Cookie字段来设置，也可以在前端通过document.cookie来设置。
以上就是我认为Cookie需要注意的点了，解决了我一开始不理解的Cookie到底发了什么给谁这个问题。接下来大概说说CSRF与Cookie的关系问题
Cookie与CSRF
CSRF是什么，这个问题应该就不需要多讲了吧，也给个文章。
我们继续从Cookie开始讲。刚刚提到，Cookie是发送给由Cookie属性中的Domian和Path
共同确定的地址去的。
那么如果这时候，有一个网页上存在一个链接，是发往你的服务器的，这时你的某个用户访问了这个网页，那么这个请求被用户触发，开始给你发请求，同时这个用户的本地存着你写入的Cookie，这个Cookie的目标服务就是你的服务，这个时候对于你来说，你就接受到了一条携带这这个用户信息的请求，自然你就判断，哦这个请求是这位用户发来的，处理它！那么你就中招了，这就是CSRF攻击，跨站（来自别的站点）请求伪造（伪造成你的用户）。
如何防止这种情况出现呢？自然是把Cookie设置为只能由你的站点发起的请求来携带，别的站点发起的请求不可以携带，这就是Cookie的SameSite属性，可以设置为Strict/Lax/None。（详情依旧是看这篇）。
到这里，我的问题都解决了，结论也很清晰，我的项目里的防御方法自然是不生效的，因为它的token字段依旧是写入到Cookie里，在被伪造的时候，依旧会携带，除非是把这个token Cookie的SameSite设置为Strict，让来自其他站点的请求无法携带这个token。
======================补充=================
今天看代码的时候，发现了华点。原来前端的fetch加了一个拦截器，会读取cookie的csrf-token字段并写入请求头。这样的话原本的操作就能说通了，后端将token写入cookie只是存储的作用，前端会读取后在请求头进行发送，后端判断身份时应该是根据请求头的token而非cookie的tooken。这样就可以起到防御的作用了，应为其他站点发起的请求是无法获取cookie自然也无法添加tooken这个请求头字段的。
