应用错误收集

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。该网站将跨域表单发布到https://example.com/login。由于受SameSite=Strict保护，因此会话cookie不会一起发送。
但是：/login路由设置了一个新的会话cookie
Set-cookie: PHPSESSID=9876; path=/; domain=.example.com; secure; HttpOnly; SameSite=Strict 。（某些框架，例如Symfony，无论成功与否，都会为每个登录请求设置一个新的会话cookie。）
尽管有SameSite标志，但此cookie已存储，因此将替换有效的会话cookie。
->即使上一个会话仍然有效，浏览器也不再使用它，因此用户已被有效注销。

我在Chrome / 78.0.3904.108和Firefox / 70.0中对此进行了测试。自从我添加了“ SameSite = Strict”标志以来，CSRF保护在方案1中就可以正常工作，但是在方案2中存在描述的问题。

“ SameSite” cookie规范（或浏览器开发人员）是否错过了方案2？
我希望不再需要带有“ SameSite”标志的特殊CSRF保护措施。

恕我直言，“ SameSite”标志不仅应防止发送现有的cookie，而且还应防止存储新的cookie。