Chrome 和 Firefox 中的 SameSite=Strict cookie 保护是否被破坏？

Question

似乎 CSRF 保护属性 "SameSite=Strict" 并未在所有情况下提供所需的保护。

场景 1（有效）：

• 用户登录 https://example.com。会话 cookie 已设置，受 "SameSite=Strict".
保护
• 用户访问https://attack-1abc2def.com。跨源表单 POST 到 https://example.com/foo 不发送会话 cookie，很好，保护有效。

场景 2（损坏）：

• 如上所述登录https://example.com。设置了会话 cookie：
  Set-cookie: PHPSESSID=1234; path=/; domain=.example.com; secure; HttpOnly; SameSite=Strict
• 用户访问https://attack-1abc2def.com。本网站制作了一个跨源表单 POST 到 https://example.com/login。 会话 cookie 不会一起发送，因为受 SameSite=Strict.
  保护 但是：/login 路由设置了一个新的会话 cookie
  Set-cookie: PHPSESSID=9876; path=/; domain=.example.com; secure; HttpOnly; SameSite=Strict . （一些框架，如 Symfony，为每个登录请求设置一个新的会话 cookie，无论是否成功。）
  此 cookie 已存储，因此会替换有效的会话 cookie - 尽管有 SameSite 标志。
  -> 尽管之前的会话仍然有效，但浏览器不再使用它，因此用户实际上已注销。

我在 Chrome/78.0.3904.108 和 Firefox/70.0 中对此进行了测试。 由于我添加了 "SameSite=Strict" 标志，CSRF 保护在场景 1 中工作正常，但在场景 2 中存在描述的问题。

"SameSite" cookie 规范（或浏览器开发人员）是否可能遗漏了场景 2？
我希望使用 "SameSite" 标志不再需要特殊的 CSRF 保护措施。

恕我直言，"SameSite" 标志不仅应防止发送现有 cookie，还应防止存储新 cookie。

Answer 1

这是预期的行为。所有顶级请求都可以设置 SameSite cookie。这反映在最新版本的规范中：https://github.com/httpwg/http-extensions/pull/800

Answer 2

引用自SameSite cookies explained：

the cookie will only be sent if the site for the cookie matches the site currently shown in the browser's URL bar.

这意味着 SameSite=Strict 或 SameSite=Lax 将作为保护机制 仅用于第一步跨站点通信，即当用户第一次单击 link 从一个站点到另一个站点时。以下导航将使用 cookie，因为 URL 来源相同。