谷歌浏览器升级80以上版本SameSite导致跨域请求失败

一、起因

项目参加GDPR项目，需要暂时支持双协议http/https。一共出现两个问题，现在记录一下。

• 1.发现A应用调用内嵌的B应用的服务，一直重定向。
• 2.解决重定向之后，发现需要重新登录B应用后才可以访问内嵌的B应用服务。

二、解决问题

• 1.第一个问题是由于A应用还是HTTP请求，但是B应用是HTTPS。导致一直302重定向
• 2.第二个问题排查时间比较就，因为之前一直都是正常访问。

•  2.1、排查过程中发现，A页面中调用B页面会存在重新登录B应用的情形
  

•  2.2、需要在另外一个窗口手动访问B应用，才可以正常调用A页面的内嵌B服务。
  

•  2.3、地址栏输入：chrome://flags/  
  

•  2.4、找到SameSite by default cookies和Cookies without SameSitemust be secure将上面两项设置为 Disable
  

三、思考过程

• 当时考虑到是session不能共享，B服务不能使用A服务的session，导致需要B服务重新登录
• 查找资料发现，谷歌在2020.2.18升级80版本服务，为了解决CSRF漏洞，新增了Cookies default to SameSite=Lax新特性

四、什么是SameSite

以下内容引自随风丶逆风

SameSite是Cookie中的一个属性，它用来标明这个 cookie 是个“同站 cookie”，“同站 cookie” 只能作为第
一方cookie，不能作为第三方cookie，因此可以限制第三方Cookie，解决CSRF的问题。不知道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可以携带发送的特点 。

SameSite总共有三个值：Strict、Lax、None。以下内容引自阮一峰博客

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

Strict
Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。
Set-Cookie: CookieName=CookieValue; SameSite=Strict;
这个规则过于严格，可能造成非常不好的用户体验。比如像本人当前遇到的现象，cookie带不过，等于一直没有登录状态，就会回到登录页。

Lax
Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。Chrome 80之后默认设置为该值。
Set-Cookie: CookieName=CookieValue; SameSite=Lax;
导航到目标网址的 GET 请求，只包括三种情况：链接，预加载请求，GET 表单。详见下表。
设置了Strict或Lax以后，基本就杜绝了CSRF攻击。当然，前提是用户浏览器支持 SameSite 属性。

None
浏览器会在同站请求、跨站请求下继续发送cookies，不区分大小写。网站可以选择显式关闭 SameSite 属性，将其设为 None ，同时必须设置 Secure 属性（表示Cookie 只能通过 HTTPS 协议发送，HTTP协议不会发送），否则无效。
下面为无效响应头：
Set-Cookie: widget_session=abc123; SameSite=None

根据谷歌文档Reject insecure SameSite=None cookies中所述，85版本后默认启用“拒绝非安全的
samesite=none的cookie”这一特性，要同时显式声明secure=true，这个cookie才能跨域携带。

下面为有效响应头：

Set-Cookie: widget_session=abc123; SameSite=None; Secure 
Set-Cookie: widget_session=abc123; SameSite=None; Secure=true