【问题标题】:SameSite cookies, frames, sub domains and redirectionsSameSite cookie、框架、子域和重定向
【发布时间】:2020-05-04 06:02:31
【问题描述】:

Cookie 的SameSite 概念绝对是一个难以掌握的概念……

为准备Chrome 80 的更改,我正在尝试衡量缺少SameSite 属性对我的cookie 的影响。我有以下配置:

  1. 用户最初访问 main.mysite.com
  2. main.mysite.com 设置 SomeCookie (Set-Cookie: SomeCookie=value; path=/; secure; httponly) 并重定向到 auth.mysite.com
  3. 用户在 auth.mysite.com 上进行身份验证并被重定向回 main.mysite.com(POST 请求)

因为 main.mysite.comauth.mysite.com 之间的重定向被视为同一个站点,并且因为缺少 SameSite 属性被视为 @987654328 @ by Chrome 80,这很好用。

但是,当 main.mysite.com 嵌入到托管在另一个站点(例如 othersite.com)的页面的框架中时,SomeCookie em> 不会在第 3 步发送回 main.mysite.com

这是正常的吗?为什么?

【问题讨论】:

    标签: google-chrome cookies samesite


    【解决方案1】:

    上面的答案是不正确的......让我澄清一些困惑。

    1.对于 SameSite 而言,2 个站点何时是“同一站点”?

    无论 cookie 的域属性如何,当两个站点的 eTLD+1(又名可注册域)相同时,它们将被视为相同。更详细的解释见我的回答here

    因此,在这种情况下,假设 eTLD 是“.com”,我们会认为 auth.mysite.com 和 main.mysite.com 是同一个站点,因为它们的 eTLD+1 都是 mysite.com。另一方面,anything.mysite.com 和 othersite.com 始终是跨站点的。无论是顶级导航还是子资源请求(如 iframe 中的图像或文档)都是如此。

    2。域属性是什么意思?

    如果 cookie 设置为 Set-Cookie: cookiename=cookievalue; Domain=mysite.com,则 cookie 将根据请求发送到与 *.mysite.com 匹配的任何域(即所有子域)。

    这是一种调整 cookie 范围的方法。例如,您可以将Domain=mysite.com 用于您的所有域都关心的全局cookie,将Domain=corp.mysite.com 用于您公司所有内部域都关心的cookie(例如,您的外部域不关心)。

    默认(对于未明确设置域属性的 cookie)是 cookie 仅发送到设置 cookie 的域。 (没有子域。)

    您不能设置与请求的 URL 不匹配的域属性。

    (另外,没有 cookie 的“来源”属性。)

    3.那么域与 SameSite 有什么关系?

    什么都没有。它们是独立的 cookie 属性。 Domain 不关心同站点/跨站点上下文,SameSite 也不关心 cookie 的域/子域范围。

    4.当 mysite.com 嵌入到 othersite.com 的 iframe 中时,为什么不发送 default-Lax cookie?

    这被认为是跨站点上下文,因为用户 URL 栏中的站点是 othersite.com,而请求是向 mysite.com 发出的,它们有两个不同的 eTLD+1。

    因为它在 iframe 中,所以这不是顶级导航,所以所有跨站点请求都将排除 SameSite cookie。

    如果它顶级导航(用户单击将他们从 othersite.com 带到 mysite.com 的链接),那么请求方法将很重要。在绝大多数情况下,这将是一个 GET 请求,因此将发送 Lax 模式下的 cookie

    希望这会有所帮助!更多详情可以参考最新版spec

    【讨论】:

    • 感谢您的详细回答,我认为这 4 点非常有意义。但是,它并没有真正回答我的问题。如果您查看问题中的场景,并在框架内播放它,那么 SomeCookie 没有发送回 main.mysite.com 对我来说仍然没有意义i> 当 auth.mysite.com 重定向回 main.mysite.com 时,因为两者都被视为同一站点(所有这些都发生在框架内)。你怎么解释这个?
    • 答案肯定在这里:tools.ietf.org/html/…(感谢@chlily 指出规范),但我很难解释它(它非常复杂!)
    • 啊,我明白了。感谢您澄清问题。框架中的页面与顶级站点的页面存在相同站点的概念,导航到的站点与导航到的站点存在相同站点的概念。这些是微妙的不同。该算法大致是这样工作的: 1. 比较框架中的页面与顶级框架。如果是同站,则执行第2步,否则为跨站,只有SameSite=None;应发送安全 cookie。
    • 好的。如果我做对了,请告诉我: 1. 用户访问 othersite.com,它有一个嵌入 main.mysite.com 的 iframe。 2. 在对 main.mysite.com 的请求中,服务器发送一个包含 SomeCookie 的 Set-Cookie,然后重定向到 auth.mysite.com。 3.(仍在 iframe 中)auth.mysite.com POST 回 main.mysite.com,并且 SomeCookie 在此 POST 请求中不存在。 -- 在这种情况下,第 1 步中对 main.mysite.com 的请求是跨站点的,由于它不是顶级请求,因此第 2 步中的浏览器不会接受 SameSite cookie。所以在第 3 步中,甚至没有要发送的 cookie。
    • @GermanQuinteros 这一定是别的东西。如果 SameSite='None' 应该提供 cookie。确保属性实际应用在 cookie 中,有时您的框架需要更新才能设置属性(例如,我们使用的是 .Net Core 2.2,必须更新到最新的 2.2.8)
    【解决方案2】:

    首先,我假设 cookie 的 domain 属性设置为 auth.mysite.com 而不是 .mysite.com。如果 cookie 的 domain 属性是 auth.mysite.com,那么 auth.mysite.commain.mysite.com视为 SameSite。

    您需要将cookie域属性设置为.mysite.com,以便浏览器可以看到两个站点之间的共享源并将它们视为同一个站点。

    我对您的问题的回答: 是的,当您没有将 SomeCookie 发送回 main.mysite.com 时,这是正常的正在使用 iframe,原因如下:

    • 在没有sameSite属性的情况下,该属性的值被视为Lax
    • SameSite=LaxSameSite=Strict 几乎完全相同,除了SameSite=Lax 还允许通过'顶级导航' 发送cookie。顶级导航是当 URL 栏中的值发生变化时的导航类型。 iframe 上下文不会被解释为顶级导航。

    如果您想让您的 cookie 可用于 iframe 上下文,您可以做两件事:

    1. sameSite属性值设置为none,同时将secure属性值设置为true,这样就明确地告诉了浏览器你的意图(即跨站认证)。
    2. 如果您将cookie 的domain 属性设置为.mysite.com,那么您甚至可以使用SameSite=Strict,即它们将被解释为同一个站点,因此无需额外注意必填。

    【讨论】:

    • 您猜对了,cookie 是为每个子域设置的。是的, SameSite=None 工作正常。不过,我仍然对“同一站点”的概念有些困惑,因为我从 this answer 了解到 auth.mysite.commain.mysite.com将被视为“同一站点”(因为 TLD 是 .com)。我猜它只是在“顶级导航”的上下文中被这样对待。
    • 想象一下,有人简单地将 '.com' 分配给 cookie 的 Domain 属性。如果浏览器不检查公共后缀列表 (PSL) 并按原样接受,则该 cookie 最终将附加到每个以 .com 结尾的请求,无论它是 gmail.com 还是 facebook.com。 PSL 能够说“这个 cookie 的 .com 属性不足以说 gmail.com 和 facebook.com 是同一个站点”。在您的示例中,您的 cookie 没有经过 PSL 检查,因为它已经足够长,可以从主子域中排除 auth 子域,反之亦然。
    • > 如果 cookie 的域属性是 auth.mysite.com,则 auth.mysite.com 和 main.mysite.com 不被视为 SameSite。这实际上是不正确的,仅供参考。 cookie 的 Domain 属性与 SameSite 属性是分开的。两个站点是否为“同一站点”的概念基于公共后缀列表。有关更多详细信息,请参阅我的回复 here。所以 auth.mysite.com 和 main.mysite.com 总是是同一个站点。
    • 对不起,我不同意。这可以很容易地测试,我做到了。要将两个 URI 视为同一个站点,有两个条件: 1- cookie 的域属性必须与 URI 匹配 2 - 必须通过 PSL 检查。
    猜你喜欢
    • 2020-06-21
    • 2011-08-26
    • 1970-01-01
    • 2012-04-03
    • 1970-01-01
    • 1970-01-01
    • 2022-01-15
    • 2011-05-28
    • 1970-01-01
    相关资源
    最近更新 更多