chrome浏览器iframe嵌套页面跨域无法获取cookie问题（SameSite 属性）

最新推荐文章于 2024-03-09 10:21:24 发布

carry_chenxiaodong

最新推荐文章于 2024-03-09 10:21:24 发布

阅读量2.6w

点赞数 13

分类专栏：前端踩坑文章标签： cookie session web

本文链接：https://blog.csdn.net/carry_chenxiaodong/article/details/114278838

版权

前端踩坑专栏收录该内容

4 篇文章 1 订阅

订阅专栏

问题现象：

系统正常iframe嵌套其他域名网站页面，起初在chrome低版本浏览器和360浏览器、火狐浏览器上是可以正常显示嵌套页面(已后端模拟登录返回页面)并支持当前iframe页面获取cookie信息发送请求。

最近升级新版chrome浏览器后，iframe页面一直没法显示出来（空白页面），页面未报错，查看请求url头部信息Response Headers:

Connection:keep-alive
Content-Length:0
Date:Tue, 02 Mar 2021 02:50:11 GMT
Keep-Alive:timeout=20
session-status:timeout
Set-Cookie:JSESSIONID=12d38d20-247b-447e-adc4-1413055ea33d; Path=/; HttpOnly

原因还原：

1、将嵌套页面的url单独窗口访问，一切正常（页面显示正常，页面请求正常获取cookie信息），排除iframe页面问题。

2、进一步尝试，将这个带有链接的iframe放在一个全新的html文件中也不能正常访问，排除当前系统的iframe加载问题。

3、刚刚新建的html文件在火狐浏览器中打开可以正常访问。

4、新版chrome浏览器访问，iframe页面显示空白。（测试机chrome浏览器版本 88.0.4324.150（正式版本）（64 位））

初步结论：新版chrome浏览器做了限制，iframe页面无法第三方cookie,嵌套此页面的网站无法共享cookie给iframe页面导致。

深入分析：

使用其它浏览器(firefox, ie)，session却是一致的。。
对比chrome和firefox请求头和响应头：

firefox：首次发起请求后，服务端返回sessionId后，之后每次请求中的cookie都会带上sessionId。

chrome：请求头始终未携带sessionId，甚至整个cookie都为空，导致服务器每次都接受不到sessionId，每次都会重新分配一个 session。

问题分析：
Google 在2020年2月4号发布的 Chrome 80 版本（schedule：https://www.chromestatus.com/features/schedule）中默认屏蔽所有第三方 Cookie，

即默认为所有 Cookie 加上 SameSite=Lax 属性（https://www.chromestatus.com/feature/5088147346030592），并且拒绝非Secure的Cookie设为 SameSite=None（https://www.chromestatus.com/feature/5633521622188032）

SameSite的作用就是防止跨域传送cookie，从而防止 CSRF 攻击和用户追踪，此举是为了从源头屏蔽 CSRF 漏洞。关于 SameSite 属性的介绍，《Cookie 的 SameSite 属性》。

Cookie 的SameSite属性用来限制第三方 Cookie，从而减少安全风险。

它可以设置三个值。

Strict
Lax
None

Strict

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


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

这个规则过于严格，可能造成非常不好的用户体验。比如，当前网页有一个 GitHub 链接，用户点击跳转就不会带有 GitHub 的 Cookie，跳转过去总是未登陆状态。

Lax

Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。


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 属性。

None

Chrome 计划将Lax变为默认设置。这时，网站可以选择显式关闭SameSite属性，将其设为None。不过，前提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。

下面的设置无效。


Set-Cookie: widget_session=abc123; SameSite=None

下面的设置有效。


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

上述问题中，在当前系统访问第三方系统时，带了一些cookie过去，然后被这个SameSite机制拦截掉了。

可能在 Chrome 80 中受到影响的场景如下
1、组件数据基于第三方网站的登录态返回相关用户数据的API请求
2、HTTP 本地部署

解决方案
Chrome浏览器打开新标签页，地址栏中分别输入
chrome://flags/#same-site-by-default-cookies
chrome://flags/#cookies-without-same-site-must-be-secure

然后如上如图所示将这两个配置均设置为Disabled（此策略不推荐，可用于应急系统访问）

开发建议：

1.禁用浏览器samsite属性/或降低版本（目前仅chorme存在）
2.保证同源策略cookie共享（保证ip或域名一直）
3.设置response.setHeader(“Set-Cookie”, “HttpOnly;Secure;SameSite=None”)，需设置https证书
4.不使用cookie共享会话，使用token实现