chrome浏览器获取不到cookie问题说明

一、现象

部分用户在用chrome浏览器审批时，在待办中调用服务重复302，直至满一分钟失败。点开服务详情，会看到设置cookie失败的标识

二、原因及背景

Google 为了杜绝 CSRF（CSRF攻击参考：https://blog.csdn.net/freeking101/article/details/86537087 ）的发生，Chrome会将没有声明SameSite值的cookie默认设置为SameSite=Lax。只有采用SameSite=None; Secure设置的cookie可以从外部访问，前提是通过安全连接（即HTTPS）访问（该设置从2020 年7月14全面展开，具体见：https://www.chromestatus.com/feature/5088147346030592），如果设置SameSite=Lax , 并且嵌入Iframe的地址和iframe外的地址不是SameSite，那么嵌入iframe的地址将无法设置设置cookie。所以目前待办页通过cookie去登陆拿用户信息这种鉴权手段将会失效！

那同样是最新版本Chrome，为什么有些用户不受影响？

在https://www.chromium.org/updates/same-site中，Chrome官方也给出了解释，他们也知道SameSite是“具有较大潜在破坏力的功能”，因此他们的策略是针对部分用户逐步推出，直到最终覆盖100%的Chrome用户

什么是SameSite

SameSite是Cookie中的一个属性，它用来标明这个 cookie 是个“同站 cookie”，“同站 cookie” 只能作为第一方cookie，不能作为第三方cookie，因此可以限制第三方Cookie，解决CSRF的问题。早在Chrome 51中就引入了这一属性，但是不会默认设置，所以相安无事。

第三方Cookie：由当前a.com页面发起的请求的 URL 不一定也是 a.com 上的，可能有 b.com 的，也可能有 c.com 的。我们把发送给 a.com 上的请求叫做第一方请求（first-party request），发送给 b.com 和 c.com 等的请求叫做第三方请求（third-party request），第三方请求和第一方请求一样，都会带上各自域名下的 cookie，所以就有了第一方cookie（first-party cookie）和第三方cookie（third-party cookie）的区别。上面提到的 CSRF 攻击，就是利用了第三方 cookie可以携带发送的特点。

“同站cookie”不是根据同源策略判断，而是PSL（公共后缀列表），子域名可以访问父域名cookie，但父域名无法访问子域名cookie。

SameSite总共有三个值：Strict、Lax、None

Strict：最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。这个规则过于严格，可能造成非常不好的用户体验。
Lax：规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。Chrome 80之后默认设置为该值。设置了Strict或Lax以后，基本就杜绝了CSRF攻击。
None：浏览器会在同站请求、跨站请求下继续发送cookies，不区分大小写。网站可以选择显式关闭 SameSite 属性，将其设为 None ，同时必须设置 Secure 属性（表示Cookie 只能通过 HTTPS 协议发送，HTTP协议不会发送），否则无效。