1. 前提
- 之前博客已经写了关于Cors解决跨域的问题
- 服务器端对于跨域请求的处理流程如下：
- 首先查看http头部有无origin字段；
- 如果没有，或者不允许，直接当成普通请求处理，结束；
- 如果有并且是允许的，那么再看是否是preflight(method=OPTIONS)；
- 如果不是preflight（简单请求），就返回Allow-Origin(必须的)、[Allow-Credentials，Access-Control-Expose-Headers]，并返回正常内容。
- 如果是preflight（预先请求），正式通信前多一次预检请求，就返回Allow-Headers、Allow-Methods等，内容为空
- 但是对于cookie的发送，即使设置了cors也不会发送cookie
2. CSRF攻击
- 具体的csrf过程也在之前的博客提到（上面那个链接），CSRF利用的是网站对用户浏览器的信任，攻击者伪造用户浏览器的请求，去访问用户曾经认证访问过的网站。使目标网站接收并误以为是用户的真实操作而去执行命令。常用于盗取账号、转账、发送虚假消息等，攻击者利用网站对请求的验证漏洞而实现这样的攻击行为，网站能够确认请求来源于用户的浏览器，却不能验证请求是否源于用户的真实意愿下的操作行为。
- 用户Tom登录并信任了网站A，浏览器保存了网站A的cookie，Tom在同一个浏览器打开了haker网站B，B有个隐藏的链接或者图片标签会自动请求A的资源，haker网站B在请求A的资源的时候，如果当前的请求地址url符合cookie的domain和path设置条件，浏览器发送请求就会自动携带上这个cookie（访问同一个域名下的页面请求，浏览器会自动携带当前域下的cookie这一个特性），从而B伪造了用户Tom的身份，可以获取A的信息以及利用他的身份做坏事。
- 借助第三方网站（需要注册一个恶意网站）
- 需要用户登录
- 需要一个ajax异步请求
- 解决方法：
- 验证HTTP的referer字段
- 在请求地址中添加token
抵抗csrf的关键就是在请求中放入不存在cookie中，且黑客不能伪造的信息，在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。
- 可以把CSRF攻击看做是万恶之源，看做是跨域问题的起点（跨域之后是不允许携带ccokie的，不管是script还是ajax请求，都不允许携带cookie），看做是浏览器同源政策的诞生原因，同源政策诞生之后，为开发带来了很多麻烦，开发者想出了jsonp等方法，后来h5出来才诞生了cors
- 浏览器有了同源策略为什么还会有csrf，因为cookie限制只是针对ajax和script的，from表单提交（get/post）都是可以携带cookie的
2. Cors中携带cookie的三个条件
- 服务器的响应头需要携带Access-control-allow-Credentials，并设置为true：表示允许携带cookie请求资源
- 浏览器发起的ajax请求，必须设置withCredential为true，表示允许发送cookie
- 响应头中的Access-control-allow-origin一定不能为*,需要指定域名
