不少用户升级到了 Chrome 80 版本以后发现登入公司的聚合类中台项目成功之后,打开内部嵌套的一个 iframe OA 应用但还是让输入用户名密码登录。这个情况是什么原因导致的?如何解决?

定位问题

  • 第一步,认为可能是自身认证体系出了问题,于是查看用户电脑上的浏览器,发现浏览器通过中台前端页面打开 iframe 嵌套的 OA 应用,OA 的链接上有带 OA 的认证参数。直接用该链接打开 OA 的网页是会做到免密登录的。
  • 第二步,单独通过网页直接打开 OA 链接,在 DevTools 里查看 Application,发现 Cookies 里是有用户的认证信息等相关参数的。但是如果通过中台打开 OA,发现 OA 的 Cookies 里没有数据。
  • 第三步,而且最近没发什么重大改动的版本,排除了服务器或者程序的问题。那么顺着这条路子,初步怀疑应该是浏览器的原因。最后发现是 Chrome 80 版本的一个新特性搞的鬼。

解决方案

先说解决方案。

准确定位到问题,就好办了。这里想到了三种解决方法:

  1. 让用户直接访问 aaaa.com 这个网址的中台。因为自从中台迁移 IDC 后,中台相关的项目都统一在 aaaa.com 这个域名下,OA 也是。所以访问这个域名下的易道因为是在同一个主域名下,所以这个问题就避免了。但是如果用户访问的是 bbbb.com 这个网址的话, 里面的 OA 因为和该网址不是同一个主域名,所以会有跨域问题,导致 OA 的Cookies 设置不上。
  2. 浏览器显式关闭该功能。
  • 地址栏输入:chrome://flags/
  • 找到 SameSite by default cookies 和 Cookies without SameSite must be secure
  • 将上面两项设置为 Disable 即可。
  1. 显示关闭 SameSite 属性,按照上述有效响应头设置登录接口的响应头即可。将 SameSite 属性值改为 None, 同时将 secure 属性设置为 true。且需要将后端服务域名必须使用 https 协议访问。由于设置 SameSite = None,有 SCRF 风险,所以,最佳方案是使用 token 代替现有的 Cookie 方式作验证。
//...
response.setHeader(name: "Set-Cookie", value: "_u=xxxx; Path=/Login; SameSite=None; Secure")
//...

在 Chrome 80 版本中,Chrome 会将没有声明 SameSite 值的 cookie 默认设置为 SameSite=Lax。只有采用 SameSite=None; Secure 设置的 cookie 可以从外部访问,前提是通过安全连接(即 HTTPS)访问。

那这 SameSite 又是什么?

什么是 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,所以就有了第一方cookiefirst-party cookie)和第三方cookiethird-party cookie)的区别。上面提到的 CSRF 攻击,就是利用了第三方 cookie 可以携带发送的特点 。

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

SameSite 总共有三个值:StrictLaxNone。以下内容引自阮一峰博客

  1. Strict

Strict 最为严格,完全禁止第三方 Cookie,跨站点时,任何情况下都不会发送 Cookie。换言之,只有当前网页的 URL 与请求目标一致,才会带上 Cookie

Set-Cookie: CookieName=CookieValue; SameSite=Strict;

这个规则过于严格,可能造成非常不好的用户体验。比如像本人当前遇到的现象,cookie 带不过,等于一直没有登录状态,就会回到登录页。

  1. Lax

Lax 规则稍稍放宽,大多数情况也是不发送第三方 Cookie,但是导航到目标网址的 Get 请求除外。Chrome 80 之后默认设置为该值。

Set-Cookie: CookieName=CookieValue; SameSite=Lax;

导航到目标网址的 GET 请求,只包括三种情况:链接,预加载请求,GET 表单。详见下表。

请求类型示例正常情况Lax
链接<a href="…"></a>发送 Cookie发送 Cookie
预加载<link rel="prerender" href="…"/>发送 Cookie发送 Cookie
GET 表单<form method="GET" action="…">发送 Cookie发送 Cookie
POST 表单<form method="POST" action="…">发送 Cookie不发送
iframe<iframe src="…"></iframe>发送 Cookie不发送
AJAX$.get(“…”)发送 Cookie不发送
Image<img src="…">发送 Cookie不发送

设置了 Strict 或 Lax 以后,基本就杜绝了 CSRF 攻击。当然,前提是用户浏览器支持 SameSite 属性。

  1. None

浏览器会在同站请求、跨站请求下继续发送 cookies,不区分大小写。网站可以选择显式关闭 SameSite 属性,将其设为 None ,同时必须设置 Secure 属性(表示 Cookie 只能通过 HTTPS 协议发送,HTTP 协议不会发送),否则无效。

下面为无效响应头:

Set-Cookie: widget_session=abc123; SameSite=None

下面为有效响应头:

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

参考

  1. http://www.ruanyifeng.com/blog/2019/09/cookie-samesite.html
  2. https://www.ithome.com/0/471/735.htm
  3. https://www.chromestatus.com/feature/5088147346030592