对SameSite Cookie行为的更改-对Web开发人员的行动呼吁

我们正在将cookie的SameSite属性的默认值从None更改为Lax。这将大大提高用户的安全性。但是，一些网站可能(甚至在不知情的情况下)依赖于旧的默认设置，这可能会导致这些网站中断。在Mozilla，我们正在慢慢引入这一变化。我们强烈鼓励所有的网站开发人员使用新的默认设置来测试他们的站点。

SameSite是Cookie的一个属性，允许Web开发人员声明Cookie应仅限于第一方或同一站点上下文。该属性可以具有下列值之一：

严格-浏览器将仅发送同站点请求的Cookie(即，源自设置Cookie的站点的请求)。

Lax-Cookie将在跨站点请求(如调用加载图像或帧)时被扣留。但是，当用户从外部站点导航到URL时(例如，通过跟随链接)，将发送Cookie。

目前，缺少SameSite属性意味着Cookie将附加到针对给定源的任何请求，无论该请求是由谁发起的。此行为等效于设置SameSite=None。但是，这种“默认打开”行为使用户容易受到跨站点请求伪造(CSRF)攻击。在CSRF攻击中，恶意站点试图使用来自合法站点的有效cookie来执行攻击。

为了保护用户免受CSRF攻击，浏览器需要更改处理Cookie的方式。两个主要更改是：

显式设置SameSite=None以启用跨站点传递的Cookie还必须设置安全属性。(换句话说，它们必须需要HTTPS。)。

依赖旧的默认行为的网站现在必须将SameSite属性显式设置为None。此外，还要求它们包含安全属性。一旦在Firefox中进行了此更改，如果网站无法正确设置SameSite，则这些网站可能会对用户造成破坏。

新的SameSite行为从Nighter75(2020年2月)开始就一直是Firefox Nighways的默认行为。在Mozilla，我们已经能够探索这一变化的含义。从Firefox79(2020年6月)开始，我们将其推广到50%的Firefox Beta用户群。我们想监控任何潜在破损的范围。

目前还没有将此功能发布到Firefox发布频道的时间表。我们希望看到Beta用户没有看到不可接受的网站破损量--这表明大多数网站已经适应了新的默认行为。由于“破坏”没有确切的定义，而且很难通过遥测来确定，我们正在关注几个渠道(例如，Bugzilla、社交媒体、博客)关于站点破坏的报道。

此外，我们希望看到该提案在IETF中进一步推进。作为开放网络的支持者，对网络生态系统的改变进行适当的标准化是很重要的。

这是整个行业对浏览器的改变，而不是Mozilla一个人在做的事情。谷歌从2020年2月开始向Chrome用户推出这一改变，SameSite=lax是他们所有频道(发行版、测试版、金丝雀版)中一定百分比(未发布)的默认设置。

Mozilla正在与谷歌合作，在我们各自的漏洞跟踪数据库中跟踪和共享网站崩溃的报告。我们共同鼓励所有Web开发人员开始将SameSite属性显式设置为最佳实践。

在Firefox Nighly和Beta频道的测试表明，网站确实发生了破坏。虽然我们已经联系了我们遇到的那些站点，并鼓励他们在其Web属性上设置SameSite属性，但是Web显然太大了，不能在个案的基础上这样做。

重要的是，所有的Web开发人员都要根据这个新的默认设置来测试他们的站点。这将为Firefox和Chrome浏览器在各自的发布渠道中进行切换做好准备。

此时，请彻底测试您的站点。尤其要注意任何涉及登录流、多个域或跨站点嵌入内容(图像、视频等)的内容。对于任何涉及POST请求的流，您应该使用和不使用长延迟进行测试。这是因为Firefox和Chrome都实现了两分钟的阈值，允许在顶级的跨站点POST请求(一个常见的登录流)上发送没有SameSite属性的新创建的cookie。

要查看您的站点是否受到新Cookie行为的影响，请检查Firefox Web控制台并查找以下消息之一：

Cookie被拒绝，因为它具有“sameSite=None”属性，但缺少“Secure”属性。

Cookie将“sameSite”策略设置为“lax”，因为它缺少“sameSite”属性，而“sameSite=lax”是该属性的默认值。

看到这两条消息中的任何一条并不一定意味着您的站点将不再工作，因为新的Cookie行为可能对您的站点的功能并不重要。因此，至关重要的是，每个现场都要在新的条件下进行测试。然后，验证新的SameSite行为没有破坏任何内容。一般来说，显式设置Cookie的SameSite属性是保证您的站点继续以可预测的方式运行的最佳方式。