所以要被CSRF攻击，必须同时满足两个条件：
1.登录受信任网站A，并在本地生成Cookie。
2.在不登出A的情况下，访问危险网站B。
CSRF 攻击的对象
在讨论如何抵御 CSRF 之前，先要明确 CSRF 攻击的对象，也就是要保护的对象。从以上的例子可知，CSRF 攻击是黑客借助受害者的 cookie（session） 骗取服务器的信任，但是黑客并不能拿到 cookie，也看不到 cookie 的内容。另外，对于服务器返回的结果，由于浏览器同源策略的限制，黑客也无法进行解析。因此，黑客无法从返回的结果中得到任何东西，他所能做的就是给服务器发送请求，以执行请求中所描述的命令，在服务器端直接改变数据的值，而非窃取服务器中的数据。所以，我们要保护的对象是那些可以直接产生数据改变的服务，而对于读取数据的服务，则不需要进行 CSRF 的保护。比如银行系统中转账的请求会直接改变账户的金额，会遭到 CSRF 攻击，需要保护。而查询余额是对金额的读取操作，不会改变数据，CSRF 攻击无法解析服务器返回的结果，无需保护。
故：增删改需要防范CSRF攻击，而读无需防范。
当前防御 CSRF 的几种策略
在业界目前防御 CSRF 攻击主要有四种策略：
- 验证 HTTP Referer 字段；
- 在请求地址中添加 token 并验证；
- 在 HTTP 头中自定义属性并验证；
- Chrome浏览器端启用SameSite cookie
1、验证 HTTP Referer 字段
什么是HTTP Referer？下面GIF图是由百度跳转到QQ邮箱页面的Referer查看示意：
可以看出Referer为
Referer：https://www.baidu.com/
根据 HTTP 协议，在 HTTP 头（request 的 header）中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。如果黑客要对银行网站实施 CSRF 攻击，当用户通过黑客的网站发送请求到银行时，该请求的 Referer 值是指向黑客的网站而不是用户的网站。因此，要防御 CSRF 攻击，银行网站只需要对于每一个转账请求验证其 Referer 值，如果是以 www.bank.example开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果 Referer 是其他网站的话，则有可能是黑客的 CSRF 攻击，拒绝该请求。
这种方法的显而易见的好处就是简单易行，网站的普通开发人员不需要操心 CSRF 的漏洞，只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。特别是对于当前现有的系统，不需要改变当前系统的任何已有代码和逻辑。