从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：1.登录受信任网站A，并在本地生成Cookie。2.在不登出A的情况下，访问危险网站B。
看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：
1.你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。2.你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。（事实上，关闭浏览器不能结束一个会话，但大多数人都会错误的认为关闭浏览器就等于退出登录/结束会话了......）（Cookie有两种，临时cookie，关闭浏览器后临时cookie就失效，持久cookie，这种cookie会保存在本地，并设置一个失效时间）
3.上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。上面大概地讲了一下CSRF攻击的原理。
CSRF能够攻击成功，其本质原因是重要操作的所有参数都是可以被攻击者猜测到的。
重要操作对象的增删改有CSRF防范校验；重要操作对象包括不限于用户信息、跟金钱相关的支付、转账、促销活动等；备注：有些产品会使用get请求发送删除操作的请求，此类请求也需要加CsrfToken校验
CSRFToken检查1、Token要足够的随机，必须使用安全的随机算法生成；2、Token要由服务器侧生成，要确保Token在会话间有效，即会话更新，token也要跟着更新；会话失效，Token也必须失效。3、Token可以放到url、header和body中，不可放到cookie中；4、Token也可以不与会话绑定，譬如采用使用1次即失效也是可以的。5、由客户端在重要请求中提交给服务器，服务器侧来验证Token的有效性。6、获取Token的接口，需要对请求头中的refer值进行安全校验。7、Token长度至少为24字节。
避免CSRF攻击：1.验证Refer。根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。RefererCheck的缺陷在于。服务器并非什么时候都能取到referer，很多用户处于隐私保护的考虑，限制了referer的发送，此外，referer容易被攻击者修改，所以无法依赖RefererCheck作为防御CSRF的主要手段
2.验证码：安全，需要用户参与，麻烦。
3.CSRF Token：请求头中带上token，保证随机性。
总结：鉴权信息放到cookie中，存在该攻击。生成随机token放到header中进行鉴权则不存在该问题。
实例：
原场景：项目集成到某框架中，框架把鉴权的woAuth信息通过cookie传过来。前端拿到信息再通过cookie传到后台，后台拿到后调用框架的sdk鉴权接口进行校验。
思路：在原先鉴权基础上增加以下功能： 前端访问后台的get请求接口，后台生成随机码，放到session中，同时放到header里反回给前端。前端访问post接口的时候在header中带上这个随机码，后台从session中取出进行校验。