作为提高浏览器安全性的努力的一部分，Chrome开发团队宣布了一个关于cookie的SameSite属性和需求的新实现。新代码使用了更严格的“默认安全”模型来获取和设置浏览器的值。区别是一个强制的“None”的SameSite值加上在第三方cookie上下文中的安全。这一变化也使得浏览器创建者更容易授予用户独立管理第三方cookie和第一方cookie的选项。
First party cookie经常保存用户之前登录过的站点的持久状态信息，比如识别快速登录的浏览器。出于隐私方面的考虑，用户可能会保留这些cookie，但会删除通常是跟踪器的第三方cookie。如果能够做到这一点，而不需要通过一个庞大的熟悉和不熟悉的网站列表来完成工作，那就太好了。
缺省安全的模型
对于开发人员来说，这条新闻的重要部分主要是对第三方cookie的不同处理，这是浏览器领域默认安全趋势的一部分。Firefox和Edge将从2月份开始加入Chrome的行列，实施这项新政策。Safari最近宣布的智能跟踪预防(ITP)与之类似，但处理相同设置的方式可能与这里所解释的不同。
默认安全(secu- by-default)是一种防御姿态，在第一次接触时，双方只建立了最少的信任(没有)。访问敏感信息的权限升级，如在第三方上下文中检索cookie值，在浏览器将请求头中的cookie值发送到网站之前，需要明确的权限设置。第一方cookie具有用于传输的已建立的基础设施特权。
YouTube跨站点cookie示例
假设一个用户登录到YouTube，其中会话cookie设置为第一方上下文。新策略需要一个SameSite属性值’ None ‘以及一个’ Secure ‘声明(SameSite=None;安全)明确允许YouTube在第三方上下文中检索它的cookie值，比如发布在外部博客上的嵌入式播放器。当cookie以这种方式设置和检索值时——有时是在第一方，有时是在第三方上下文中——它们被分类为跨站点cookie。
跨站点cookie允许YouTube小部件识别登录用户的浏览器，并激活视频播放器窗口中的“稍后查看”选项，作为一个嵌入到外部站点的框架。只要初始cookie设置为’ SameSite=None;然后YouTube的小部件就会继续正常工作。YouTube可能已经为即将到来的变化做好了准备，谷歌建议你也做好准备。
准备改变
在实现时，新的SameSite策略机制将要求第三方cookie进行自我识别并通过TLS (https://)连接传输，否则它们将受到默认安全回退模型的限制。属性SameSite=None需要安全指定，否则指令被拒绝，请求被视为SameSite=Lax(在第三方上下文中cookie值不被发送)。
在各种谷歌资源中有一些关于如何在有或(错误地)没有安全声明的情况下测试SameSite=None实现的提示。针对此行为的专用测试使用Chrome或Firefox配置设置。对于Chrome 76+它是启用以下地址:
chrome: / /标志/ # cookies-without-same-site-must-be-secure
火狐69+在它的about:配置设置你想设置以下:
network.cookie.sameSite.noneRequiresSecure
当您在第三方上下文中实现SameSite时，还可以在浏览器开发人员工具中执行测试并查看SameSite控制台警告。
跨站点请求伪造
在应用程序安全领域，跨站点请求伪造(CSRF)是危险的。新的cookie策略可以限制(但不能消除)使用已知CSRF漏洞的成功攻击。网络的传统开放性允许cookie值可以自由发送，因此攻击者通常会评估网络通信，寻找通过网站不安全的cookie实现访问的途径。
不要在cookie值中存储应用程序秘密。
尽管应用程序安全性超出了本文的范围，但web表单中的反csrf隐藏令牌可以帮助确保动作请求来自有效用户，而不是来自在公共热点劫持用户活动会话的冒名者。
然而，这些策略都不是万无一失的。
相同的cookie设置指南
SameSite有三个可能的值:Strict、Lax和None。到目前为止，我们主要处理的是第三方访问的None设置。并不是所有的设置都与所有的上下文相关。为了帮助解决这个问题，驱散困惑