典型案例：
A网站SameSite.a.com 作为iframe嵌入在B网站test.b.com 中 。B站中访问iframe（A站）时想要发起请求setCookie，但是cookie并没有被塞进去。以登陆信息举例，大多数系统在用户访问时如果登陆信息校验失败，就会发起登陆请求，登陆请求setCookie的同时又会重定向到系统，页面可能就会反复跳转刷新，进入死循环。
前言
CSRF攻击（Cross-site request forgery）跨站请求伪造
典型的CSRF攻击流程：
- 受害者登录a.com，并保留了登录凭证（Cookie）。
- 攻击者引诱受害者访问了b.com。
- b.com 向 a.com 发送了一个请求：a.com/act=xx。浏览器会默认携带a.com的Cookie。
- a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求。
- a.com以受害者的名义执行了act=xx。
- 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作。
cookie
有状态协议： 必须时刻与服务器建立连接，如果意外断开回话就会丢失，重头建立连接后一般需从头开始
无状态协议： 会话与连接本身独立，即便断开会话状态也不会严重受损，保持会话不需要保持连接本身
http协议是无状态协议，如果在同一个客户端向服务器发送多次请求，服务器不会知道这些请求来自同一客户端。如果 HTTP 协议只是用来访问静态文件，那不会有任何问题，但是如果你要为广大用户提供更好的服务，服务器就需要知道每个请求具体来自于哪个用户，比如你在逛淘宝的时候你只需要登录一次，当你发起一次购买请求，服务器就已经知道你登录过了，不会再让你进行登录。
cookie的意义： HTTP协议占浏览器的一小块存储访问当前用户的‘状态’，每次发起HTTP请求，在请求中携带这些状态，让服务器知道‘你是谁’
风险：各大广告和购物网站可使用第三方Cookie获取用户数据、窥探用户隐私
第三方cookie
访问www.taobao.com 该网站会把一些cookie写入到.taobao.com这个域下。然而打开控制台你会看到，并里面还有很多其他域下的Cookie，这些所有非当前域下的 Cookie 都属于第三方 Cookie，虽然你可能从来没访问过这些域，但是他们已经悄咪咪的通过这些第三方 Cookie来标识你的信息，然后把你的个人信息发送过去了。
这时再访问天猫，已经不需要再登录了
第三方cookie的用途
- 前端日志打点
大多数 Web 站点都会引用一些第三方 SDK 来进行前端异常或性能监控，这些 SDK 会通过一些接口将监控到的信息上传到他们的服务器。一般它们都需要标识每个用户来方便排查问题或者统计 UV 数据，所以当你一此请求这个站点的时候，它们可能会在你的站点上 set 一个 Cookie，后续所有的日志上报请求都会带上这个 Cookie。
由于一般这些第三方 SDK 都是用于监控的通用服务，它们肯定会拥有自己独立的域名，比如 log.com，它在你的域名 mysite.com 下种下的 Cookie 就属于第三方 Cookie。 - 广告营销
- Facebook Pixel
在电商业务中，追踪流量、导流量、转换率、销售额这些都是商家最关心的问题。可使用 Facebook Pixel追踪广告的转化量、改进受众定位、使广告花费回报最大化，简单来说 像素就是一串 JavaScript代码。
- mmstat
平时我们在国内的搜索引擎或视频网站上搜索到一些东西，然后打开购物网站就可以收到各种你兴趣的相关推荐，这已经是大众习以为常的事情了，各大购物网站、广告商，会通过第三方 Cookie 收集你的年龄、性别、浏览历史等从而判断你的兴趣喜好，然后带给你精准的信息推荐。 比如，我们在浏览百度、优酷、天猫等网站时，都能看到几个 .mmstat.com 这个域下的 Cookie
- Facebook Pixel
在电商业务中，追踪流量、导流量、转换率、销售额这些都是商家最关心的问题。可使用 Facebook Pixel追踪广告的转化量、改进受众定位、使广告花费回报最大化，简单来说 像素就是一串 JavaScript代码。
浏览器针对cookie的策略
chrome80版本以后默认把cookie的SameSite属性设置为Lax，以此来对第三方cookie做一些限制，对于使用第三方cookie场景的系统，往往会造成登陆异常，系统崩溃等大问题。
Safari 13.1、Firefox 79 版本中，三方 Cookie 已经被默认禁用
Chrome
Chrome51版本为浏览器的Cookie新增的了一个属性SameSite， 阻止浏览器将此Cookie与跨站点请求一起发送。其主要目标是降低跨源信息泄漏的风险。同时也在一定程度上阻止了CSRF攻击。
SameSite属性介绍
SameSite是cookie的一个属性，用来限制第三方Cookie。它有三个值：
- Strict（禁止第三方 cookie）
- Lax（Chrome80以后cookie的默认策略）
- None （浏览器会在同站请求、跨站请求下继续发送 Cookies，不区分大小写。）
注意：cookie的SameSite设置为None以后，Secure需要同时设置为true，这意味着你的网站必须支持https）
验证是否为SameSite的问题
如果出现第三方请求setCookie失效的情况，那么我们就可以使用以下操作来验证是否为SameSite的问题。
步骤如下：
Chrome浏览器地址栏输入 chrome://flags/
找到：SameSite by default cookies、Cookies without SameSite must be secure
设置上面这两项设置成 Disable，重启浏览器
解决方案
方案一：统一主域名
将A网站与B网站的主域名统一，比如可以将A网站由 SameSite.a.com 变为SameSite.b.com ，与B网站test.b.com 保持一致。如果采取这种方法的话，需要重新申请域名，并且原有的域名都需要重定向到新域名。
方案二：升级https
特别注意：
- SameSite=None需要只对chrome80以上版本进行设置，chrome51-chrome66以及其他某些浏览器不接受SameSite=None。
- 如果网站存在http与https同时使用的情况，需要对此做兼容，只有https的时候才设置Secure;SameSite=None。原因在于当Secure设置为true时，表示创建的 Cookie 会被以安全的形式向服务器传输，也就是只能在 HTTPS 连接中被浏览器传递到服务器端进行会话验证。
Chrome 也宣布，将在下个版本Chrome83，在访客模式下禁用三方Cookie，2022年全面禁用三方 Cookie，到时候即使指定SameSite为None也没有意义。
safari
第三方cookie已默认被禁用，手动更改浏览器的隐私设置解除限制
全面禁止Cookie可能出现的问题
前端日志异常
可能会出现UV暴涨，但PV却没有什么变化。 原因：打点SDK使用的三方Cookie被禁用掉了。SDK将无法在你的域下写入一个三方Cookie，导致每次刷新页面它都会带一个新的Cookie，后端误以为这些都是不同用户的请求，计入UV。
智能广告推荐消失
无法追踪转化率
比如当你查看商品时，会在你的浏览器中放置一个 Cookie，表示你已经看到它。如果随后你进入转化阶段（购买、收藏等），能追踪没一个行为才能计算投放的效果，从而作出优化策略。
