CSRF 定义
CSRF（Cross-site request forgery）跨站请求伪造：攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
CSRF 的攻击特点
- 跨域请求
- GET 类型请求Header的MIME类型大概率为图片，而实际返回Header的MIME类型为Text、JSON、HTML
- 无法直接盗取 COOIKE , 只是冒充用户身份，让网站以为是用户本人的请求
CSRF 的防御手段
-
根据同源策略，拦截非法跨域请求：
异步请求会携带 Origin Header 和 Referer Header 两个头部，如果 Origin 存在，直接根据其中的字段来确定来源域名（IE 11 和 302 重定向将不会包含 Origin）。
Referer Header 由浏览器提供，在请求中会随 HTTP 请求头一起发送，专门记录请求的来源地址，可通过浏览器的 Referer 策略进行调整。
如果 Origin Header 和 Referer Header 都无法获取到，可直接对请求进行拒绝。
网站的 GET 请求，如果请求头Accept=text/html，可以加载，因为涉及到一些搜素引擎的抓取，不可能不让网站投放，但这样会使得同源策略防御手段失效，所以 GET 请求的资源要保持幂等性，尽量不要对该资源进行其他操作。 -
CSRF Token
CSRF 攻击既然是模拟用户提交，并不能直接获取用户那里的数据，网站就可以给用户发放一个特殊令牌，当用户发送请求时，携带上这个令牌，网站对这个令牌进行验证，如果不存在或是非法的就拒绝请求。
CSRF Token 的一些弊端也是有的，因为 Token 由服务器端存储，当访问量很大时，这会给服务器带来较大压力，并且在分布式环境中，怎么验证 Token 也是较麻烦的处理方式，需要存储在公共的空间比如 Redis 中，其次是该方式需要改写每个需要验证的接口、模板，工作量大，也无法通过统一的请求拦截器来进行处理。 -
验证码和密码
朴实无华且有效，CSRF 攻击者根本无法提前获取随机生成的验证码，关键请求再次输入密码也让攻击者无法提前构造参数。 -
双重 Cookie 验证
该方式有以下步骤完成：
1.用户登录网站，并注入一个 Cookie ，内容为随机字符串（csrfcookie=ksjkdjkfjkl）。
2.用户发送请求时，取出上边的 Cookie 内容，添加到请求参数中（http://example.com/?csrfcookike=ksjkdjkfjkl）。
3.服务端接收请求，并验证参数中携带的 Cookie 内容，过滤非法请求。
该方式是利用了 CSRF 攻击无法获取用户信息的特性来完成的，相当于把 Token 保存在了客户端，服务端只需要完成参数里的字符比对就可以了，这样就解决了 CSRF Token 服务器端存储和验证的问题。但该方式也有弊端和隐患，由于跨域无法获取 Cookie ，域名中的子域如果想使用双 Cookie 验证的方式，需要将验证用的 Cookie 放在顶级域名下，如果任何一个子域名被 XSS 攻击获取到了 Cookie ，就有可能拿到所有域名的攻击权限。 -
Samesite Cookie属性
由 Google 发起的修改 HTTP 协议的草案，在响应头 Set-Cookie 中添加属性 Samesite，该属性用来表明 Cookie 是同站的，其有两种值：
1.Strict：严格模式，表明这个 Cookie 在任何情况下都不可能作为第三方 Cookie。
2.Lax：松散模式，如果是当前页面改变或是代开新页面，并且请求方法是 GET ，则可以作为第三方 Cookie。
该方式尝试从源头来防御 CSRF 攻击，但目前尚不成熟：- 如果使用严格模式，用户在登录以后，打开任何新页面都需要重新登陆，用户体验不好。
- 如果使用松散模式，依然有存在冒用 Cookie 的隐患。
- 目前只支持最新版的 Chrome 和 Firefox。
- 不支持子域
- ** 总结 **
1.少点可疑链接，标题党什么的少看吧。
2.少点可疑图片，不管多诱人。
3.网站安全开发意识要有，仅依赖 Post 提交是不安全的。
