Web开发编程网
分享Web开发相关技术

SameSite cookie的解释

ookies是可用于向网站添加持久状态的方法之一。多年来,他们的能力不断发展壮大,但使平台遗留了一些有问题的遗留问题。为了解决这个问题,浏览器(包括Chrome,Firefox和Edge)正在更改其行为,以强制实施更多保留隐私的默认设置。

每个cookie是一个“ 键=值”对以及一些控制何时和何处使用该cookie的属性。您可能已经使用这些属性来设置诸如到期日期之类的信息,或者指示cookie仅应通过HTTPS发送。服务器通过在响应中发送适当命名的Set-Cookie标头来设置cookie。有关所有详细信息,您可以深入研究RFC6265bis,但现在这里是快速更新。

假设您有一个博客,希望在其中向用户显示“新功能”促销。用户可以撤消该促销,然后过一会儿再看不到它。您可以将该首选项存储在cookie中,将其设置为在一个月(2,600,000秒)内到期,然后仅通过HTTPS发送。该标题看起来像这样:

Set-Cookie: promo_shown=1; Max-Age=2600000; Secure

图片的替代文字

当您的读者查看满足那些要求的页面时,即他们处于安全连接并且cookie不到一个月,那么他们的浏览器将在其请求中发送此标头:

Cookie: promo_shown=1

图片的替代文字

您还可以使用document.cookie在JavaScript中添加和读取可用于该站点的cookie。对document.cookie进行分配将使用该密钥创建或覆盖cookie。例如,您可以在浏览器的JavaScript控制台中尝试以下操作:

> document.cookie = "promo_shown=1; Max-Age=2600000; Secure"
< "promo_shown=1; Max-Age=2600000; Secure

读取document.cookie将输出在当前上下文中可访问的所有cookie,每个cookie用分号分隔:

> document.cookie;
< "promo_shown=1; color_theme=peachpuff; sidebar_loc=left"

图片的替代文字

如果您在一些受欢迎的站点上尝试此操作,您会注意到大多数站点设置的数量远远超过了三个cookie。在大多数情况下,这些cookie是在每个单个请求上发送到该域的,这有很多含义。对于您的用户,上传带宽通常比下载带宽受到更多限制,因此所有出站请求的开销都会增加您的第一个字节的时间延迟。保守您设置的Cookie的数量和大小。利用“最大年龄”(Max-Age)属性可帮助确保cookie的停留时间不会超过所需的时间。

什么是第一方和第三方Cookie?#
如果您回到以前选择的相同站点,您可能会注意到存在针对各种域的cookie,而不仅仅是您当前正在访问的cookie。与当前站点的域匹配的Cookie(即浏览器地址栏中显示的Cookie)称为第一方Cookie。同样,来自当前站点以外的域的cookie也称为第三方cookie。这不是绝对的标签,而是相对于用户的上下文。同一Cookie可以是第一方也可以是第三方,这取决于用户当时所在的网站。

图片的替代文字

继续上面的示例,假设您的一篇博客文章中包含一张特别令人惊叹的猫的图片,并将其托管在/blog/img/amazing-cat.png。因为这是一个了不起的图像,所以另一个人直接在其网站上使用它。如果访问者访问过您的博客并具有promo_shown cookie,那么当他们在其他人的站点上查看amazing-cat.png时,将在该图像请求中发送cookie。这对任何人都不是特别有用,因为promo_shown并未用于此人网站上的任何内容,它只是增加了请求的开销。

如果那是意想不到的效果,那么为什么要这样做呢?通过这种机制,站点可以在第三方上下文中使用时保持状态。例如,如果您在自己的网站上嵌入YouTube视频,则访问者将在播放器中看到“稍后观看”选项。如果您的访问者已经登录YouTube,则该会话将通过第三方Cookie在嵌入式播放器中提供-意味着“稍后观看”按钮将立即保存视频,而不是提示他们登录或必须将它们从您的页面上移开,然后返回到YouTube。

图片的替代文字

网络的文化属性之一是默认情况下它倾向于打开。这是让如此多的人在那里创建自己的内容和应用程序的一部分。但是,这也带来了许多安全和隐私问题。跨站点请求伪造(CSRF)攻击依赖于将Cookie附加到给定源的任何请求这一事实,无论谁发起该请求。例如,如果您访问evil.example,则它可以触发对your-blog.example的请求,并且您的浏览器会很高兴地附加关联的cookie。如果您的博客对如何验证这些请求不满意,那么evil.example可能会触发删除帖子或添加自己的内容之类的操作。

用户也越来越意识到如何使用cookie来跟踪他们跨多个站点的活动。但是,到目前为止,还没有一种方法可以明确地表示您对Cookie的意图。您的promo_shown Cookie仅应在第一方上下文中发送,而故意嵌入到其他站点的窗口小部件的会话cookie则有意在第三方上下文中提供登录状态。

通过SameSite属性显式说明Cookie的使用情况
#SameSite属性(在RFC6265bis中定义)的引入使您可以声明将cookie限制在第一方上下文还是在同一站点上下文中。准确了解“站点”在这里的含义是有帮助的。该站点是域后缀和域后缀的组合。例如,www.example.com域是示例站点的一部分。

`Key Term:
If the user is on your-project.github.io and requests an image from my-project.github.io that's a cross-site request.

`

在Cookie上引入SameSite属性可提供三种不同的方式来控制此行为。您可以选择不指定属性,也可以使用“严格”或“宽松”将cookie限制为同一站点请求。

如果将SameSite设置为Strict,则cookie仅在第一方上下文中发送。用用户术语讲,只有在Cookie的站点与浏览器的URL栏中当前显示的站点匹配时,才会发送cookie。因此,如果按如下所示设置 promo_shown cookie:
Set-Cookie:promo_shown = 1;SameSite =严格

当用户在您的网站上时,该Cookie将与预期的请求一起发送。但是,当您链接到您网站的链接时,例如从另一个网站或通过朋友发送的电子邮件,在该初始请求中,将不会发送cookie。当您有与功能相关的cookie总是处于初始导航之后(例如更改密码或购买商品),但对promo_shown的限制过于严格时,这很好。如果您的读者访问该站点的链接,则他们希望发送Cookie,以便可以应用其首选项。

那就是SameSite = Lax的出现,它允许通过这些顶级导航发送cookie。让我们从上面重新访问cat文章示例,其中另一个站点引用了您的内容。他们直接利用您的猫照片,并提供指向您原始文章的链接。

看看这只神奇的猫!

阅读文章

Cookie已设置为:

套餐Cookie:promo_shown = 1;SameSite =松懈

当读者在其他人的博客上时,如果浏览器请求amazing-cat.png,则不会发送该cookie。但是,当读者通过链接访问您博客上的cat.html时,该请求将包含cookie。这使得Lax成为影响网站显示的Cookie的不错选择,而Strict对于与您的用户执行的操作相关的Cookie很有用。

严格和宽松都不是您网站安全的完整解决方案。Cookie是作为用户请求的一部分发送的,您应该将它们与其他任何用户输入一样对待。这意味着对输入进行消毒和验证。切勿使用cookie来存储您认为是服务器端机密的数据。

最后,可以选择不指定值,该值以前是隐式声明您希望在所有上下文中发送cookie的方式。在RFC6265bis的最新草案中,通过引入SameSite = None的新值来明确指出这一点。这意味着您可以使用“无”来明确表示您有意要在第三方上下文中发送cookie。

图片的替代文字

在没有SameSite的情况下更改为默认行为

尽管SameSite属性得到了广泛支持,但不幸的是,它尚未被开发人员广泛采用。开放的默认发送Cookie到处意味着所有用例都可以使用,但使用户容易受到CSRF和意外信息泄漏的影响。为了鼓励开发人员陈述其意图并为用户提供更安全的体验,IETF提案《渐进式更好的Cookies》提出了两个关键更改:

没有SameSite属性的Cookie将被视为SameSite = Lax。
SameSite = None的Cookie也必须指定安全,这意味着它们需要安全的上下文。
Chrome自80版本起就实现了这些行为。Firefox从Firefox 69起就可以对其进行测试,并将在将来使它们成为默认行为。要在Firefox中测试这些行为,请打开about:config并设置network.cookie.sameSite.laxByDefault。Edge还计划更改其默认行为。

未经允许不得转载:WEB开发编程网 » SameSite cookie的解释
微信扫码关注微信公众号

WEB开发编程网

谢谢支持,我们一直在努力

安全提示:您正在对WEB开发编程网进行赞赏操作,一但支付,不可返还。