精华内容
下载资源
问答
  • samesite
    千次阅读
    2022-03-03 10:48:28

    今天看了一道面试题,关于cookie中的SameSite属性,但是由于自己开发经验较少,所以并没有涉及到。所以我去查了一些文章,说一下自己对于cookie的SameSite属性的理解
    一、写在头部
    我们在处理CSRF攻击的时候,常常使用的解决方案是1、判断http的Referer属性,2、设置csrf token3、在http中设置自定义字段保存token。我们使用如上三种方式就可以解决CSRF的攻击。今天我们所说的cookie中的SameSite属性也是可以解决CSRF攻击的。
    我们都是HTTP是没有状态的,然后为了保存状态,后来网景公司发明了cookie用来记录用户的状态信息。但是存在一个弊端,就是我们网站A的cookie可以作为第三方网站的cookie去使用。这样就造成了CSRF的漏洞SameSite就可以限制第三方cookie的使用。
    二、SameSite的属性值
    SameSite可以设置为三个属性strict,Lax,None,接下来我们将从三个属性分别去介绍。
    属性一:strict属性:该属性表示表示完全禁止第三方cookie,也就是在跨站时,均不会携带cookie,只有当前站点的url和访问的站点的url一致时,才能携带cookie。但是我们此时想一种情况,比如说当前站点A存在一个链接,链接到gitte网站,如果我们之前已经登录了gitte网站的话,则我们再次访问该网站时应该是处于登录状态的。但是我们对当前站点cookie设置了SameSite属性为strict值,所以当前跳转链接并不会携带cookie,所以我们的信息无法得到认证,此时就需要重新登录。

    Set-Cookie: CookieName=CookieValue; SameSite=strict;
    

    属性二:Lax:该属性比strict的属性要宽松一些,其允许我们在跨站使用get请求时携带cookie

    Set-Cookie: CookieName=CookieValue; SameSite=Lax;
    

    导航到目标网址的get请求主要包括三种,链接,预加载,get表单。具体如下所示。

    请求类型示例正常情况Lax
    连接<a href="..."></a>携带携带
    预加载<link rel="prerender" href="..."/>携带携带
    GET 表单<form method="GET" action="...">携带携带
    POST 表单<form method="POST" action="...">携带不携带
    iframe<iframe src="..."></iframe>携带不携带
    AJAX$.get("...")携带不携带
    Image<img src="...">携带不携带

    SameSite设置为StrictLax时,就可以防止CSRF攻击了
    属性三:None属性:chrome默认将Lax设置为默认值,此时我们可以更改samesite的值,将其设置为none,此时必须同时设置Secure属性(Cookie 只能通过 HTTPS 协议发送),否则无效。
    下面是无效的:

    Set-Cookie: widget_session=abc123; SameSite=None
    

    下面是有效的:

    Set-Cookie: widget_session=abc123; SameSite=None;Secure;
    

    三、使用场景
    如果我们的网站是一个管理系统,或者是用户较少,经常采用输入网址的方式或者从浏览器的收藏夹中打开该网站时,我们可以使用strict。如果我们做的一些网站例如说博客,当我们在其他站点设置跳转的时候,如果我们使用strict的话,就会设置重新登录,此时我们可以将SameSite的值设置为Lax
    如果我们的网站中存在一些iframe嵌套,如果使用strict和Lax就不会携带cookie进行身份验证,此时如果需要身份验证登录,任然需要再次登录。所以此时就能使用strict或Lax属性值。
    四、缺点
    SameSite仍然存在一些缺点:首先就是不支持子域,如果从主域跳转到子域,也不会携带cookie,此时就会重新登录。第二就是浏览器的兼容性不是很好,很多浏览器不支持该属性。

    更多相关内容
  • 警告: SameSite Cookie根本不适用于旧版浏览器,也不适用于某些Mobil浏览器,例如IE 10,Blackberry,Opera Mini,IE Mobile,适用于Android的UC浏览器。 可以在此处找到更多详细信息: Slim 4整合 <?phpuse ...
  • 近日,被Chrom浏览器折磨废了~幸亏公司有各路大神。 问题来源: 对于开发小白来说,这都说的是什么玩意,完全不懂!没关系,我也不懂。 解决方案:首先确定你自己项目的WEB服务器 1、Apache解决方案 ...
  • django-cookies-相同站点 该存储库包含一个中间件,该中间件会自动为Django的旧版本(例如1.11.x,2.2.x或3.0.x)中的会话和csrf cookie设置SameSite属性。 Django 3.1.x不需要此模块,它为会话和csrf cookie引入了...
  • samesite cookie安全特性

    2021-01-07 12:29:00
    Chrome 这几天发布的 80 版本更新了 “Same Site Cookie” 的安全特性 下面是一篇介绍文章 ...这个特性会导致: ...如果网站需要跨域分享数据,则设置相关cookie的samesite属性为none 作者:深入浅出0
  • SameSite cookie 解释

    2021-07-30 11:42:56
    https://web.dev/samesite-cookies-explained/ 通过学习如何明确标记跨站点cookie来保护您的站点。 Cookie是一种可用于向网站添加持久状态的方法。多年来,它的能力不断增长和发展,但给平台留下了一些遗留问题...

    https://web.dev/samesite-cookies-explained/

    通过学习如何明确标记跨站点cookie来保护您的站点。

    Cookie是一种可用于向网站添加持久状态的方法。多年来,它的能力不断增长和发展,但给平台留下了一些遗留问题。为了解决这个问题,浏览器(包括Chrome、Firefox和Edge)正在改变它们的行为,以强制执行更多隐私保护默认值。

    每个cookie都是一个 key=value 的键值对,以及一些控制何时何地使用该cookie的属性。您可能已经使用了这些属性来设置一些内容,比如到期日期或指示cookie应只通过HTTPS发送。服务器通过在响应中发送适当命名的 Set-Cookie 首部来设置cookie。对于所有的细节,您可以深入到RFC6265bis,但现在这里是一个快速复习。

    假设您有一个博客,您想在其中向用户显示“最新消息”促销。 用户可以关闭促销,然后他们将在一段时间内不会再次看到它。 您可以将该首选项存储在 cookie 中,将其设置为在一个月(2,600,000 秒)后过期,并且仅通过 HTTPS 发送。 该首部如下所示:

    Set-Cookie: promo_shown=1; Max-Age=2600000; Secure
    服务器使用 Set-Cookie 首部设置 cookie。

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

    Cookie: promo_shown=1
    您的浏览器会在 Cookie 首部中发回cookie。

    您还可以在 JavaScript 中使用 document.cookie 添加和读取该站点可用的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"
    JavaScript可以使用 document.cookie 访问cookie。

    如果你在一些热门网站上尝试这个方法,你会注意到大多数网站设置的cookie都远远不止三个。在大多数情况下,在每次到该域的请求中都会发送这些cookie,这有很多问题。对于用户来说,上传带宽通常比下载带宽更受限制,因此所有出站请求的开销都会增加第一个字节的时间延迟。在设置的cookie数量和大小上要保守。使用 Max-Age 属性有助于确保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。

    访问不同页面时会发送第三方上下文中的 cookie。

    网络的文化属性之一是默认情况下它往往是开放的。这是让这么多人能够在那里创建自己的内容和应用程序的原因之一。然而,这也带来了许多安全和隐私问题。跨站点请求伪造 (CSRF) 攻击依赖于这样一个事实,即无论是谁发起请求,cookie 都会附加到给定来源的任何请求上。例如,如果您访问 evil.example 那么它可以触发对 your-blog.example 的请求,您的浏览器会很乐意附加相关的 cookie。如果您的博客不小心验证了这些请求,则 evil.example 可能会触发删除帖子或添加自己的内容等操作。

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

    使用SameSite属性显式声明cookie使用情况

    SameSite属性的引入(在RFC6265bis 中定义 )允许您声明您的 cookie 是否应限制为第一方或同一站点上下文。准确理解此处“站点”的含义会很有帮助。站点是指域后缀和它之前的域部分的组合。例如,www.web.dev域是web.dev站点的一部分。


    关键术语

    如果用户打开www.web.dev并从static.web.dev中请求图像,则这是同一站点请求。

    公共后缀列表定义了这一点,因此它不仅仅是像.com这样的顶级域名,也包括像github.io这样的服务。这使得your-project.github.io和my-project.github.io可以算作单独的站点。


    关键术语

    如果用户打开your-project.github.io并从my-project.github.io请求图像,则这是一个跨站点请求。

    在cookie上引入SameSite属性提供了三种不同的方法来控制这种行为。您可以选择不指定该属性,也可以使用StrictLax将 cookie 限制为相同站点的请求。

    如果奖SameSite设置为Strict,则 cookie 将仅在第一方上下文中发送。就用户而言,只有当 cookie 的站点与浏览器 URL 栏中当前显示的站点相匹配时,才会发送 cookie。因此,如果 promo_shown的cookie 设置如下:

    Set-Cookie: promo_shown=1; SameSite=Strict

    当用户在您的网站上时,cookie 将按预期与请求一起发送。但是,当通过链接进入您的网站时,比如从另一个网站或通过朋友的电子邮件,在最初的请求中不会发送 cookie。当您拥有与功能相关的cookie时,这是很好的,这些cookie将始终位于初始导航之后,例如更改密码或进行购买,但对于promo_shown来说限制太多。如果您的读者通过链接进入网站,他们希望发送 cookie,以便应用他们的偏好。

    这就是SameSite=Lax允许通过这些顶级导航发送 cookie的地方。让我们回顾一下上面的 cat 文章示例,其中另一个站点正在引用您的内容。他们直接使用您的猫照片并提供指向您原始文章的链接。

    <p>Look at this amazing cat!</p>
    <img src="https://blog.example/blog/img/amazing-cat.png" />
    <p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>

    并且 cookie 已设置为:

    Set-Cookie: promo_shown=1; SameSite=Lax

    当读者在其他人的博客上时,浏览器请求amazing-cat.png时将不会发送cookie。但是,当读者在您的博客上通过链接访问cat.html时,该请求将包含cookie。这使得Lax对于影响站点显示的cookie来说是一个很好的选择,这些cookie是与用户正在采取的操作相关的而设为Strict有效的cookie。


    注意

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

    最后还有一个选项,可以选择不指定值,该值以前是隐式声明您希望在所有上下文中发送 cookie 的方式。在RFC6265bis的最新草案中, 通过引入SameSite=None新值明确了这一点. 这意味着您可以使用None明确传达您有意希望在第三方上下文中发送 cookie。

    显式地将cookie的上下文标记为None,Lax或Strict。

    ☆ 如果您提供其他站点使用的服务,例如小部件、嵌入内容、附属程序、广告或跨多个站点的登录,那么您应该使用 None 来确保您的意图是明确的。 

    更改默认行为而不使用SameSite

    虽然SameSite属性得到广泛支持,但遗憾的是,它没有被开发人员广泛采用。到处发送cookie的开放默认值意味着所有用例都可以工作,但用户容易受到CSRF和无意信息泄漏的影响。为了鼓励开发人员表明他们的意图,并为用户提供更安全的体验,IETF提案《越来越好的Cookie》列出了两个关键更改:

    • 没有 SameSite 属性的cookie将被视为 SameSite=Lax.
    • 带有SameSite=None 的cookie还必须指定 Secure,这意味着它们需要一个安全的上下文。

    Chrome在84版时就实现了这种默认行为。Firefox 可以从Firefox 69开始对它们进行测试,并将使它们在将来成为默认行为。要在Firefox中测试这些行为,请打开about:config并设定network.cookie.sameSite.laxByDefaultEdge 也计划更改其默认行为。

    默认情况下的SameSite=Lax

    不设置该属性

    Set-Cookie: promo_shown=1

    如果你送一个不指定任何 SameSite 属性的cookie…

    应用默认行为

    Set-Cookie: promo_shown=1; SameSite=Lax

    浏览器会将该cookie视为指定了SameSite=Lax。

    虽然这是为了应用更安全的默认值,但理想情况下,您应该设置一个显式的SameSite属性,而不是依赖浏览器为您应用该属性。这使您对cookie的意图更加明确,并提高了跨浏览器获得一致体验的机会。


    注意

    Chrome应用的默认行为比显式的SameSite=Lax稍微宽松一些,因为它将允许某些cookie在顶级POST请求中被发送。您可以在Blink-dev公告中看到确切的详细信息。这是一种临时缓解措施,您仍然应该使用 SameSite=None; Secure 来修复您的跨站点cookie。

    SameSite=None 必须是安全的

    拒绝

    Set-Cookie: widget_session=abc123; SameSite=None

    没有设置 Secure 的cookie将被拒绝.

    接受

    Set-Cookie: widget_session=abc123; SameSite=None; Secure

    必须确保将 SameSite=None 与 Secure 属性配对。

    您可以从Chrome 76开始测试此行为,方法是启用 about://flags/#cookies-without-same-site-must-be-secure。在Firefox 69中通过 about:config 设置 network.cookie.sameSite.noneRequiresSecure 。

    在设置新cookie和主动刷新现有cookie时,即使它们没有接近到期日期,也要应用此方法。


    ☆ 如果您依赖于在您的网站上提供第三方内容的任何服务,您还应该向提供商确认他们正在更新其服务。您可能需要更新您的依赖项或代码片段,以确保您的站点获得新的行为。

    这两个更改对浏览器都是向后兼容的,他们有的正确实现了SameSite属性的早起版本,或者根本不支持它。通过将这些更改应用于cookie,您可以明确它们的预期用途,而不是依赖浏览器的默认行为。同样,任何尚未识别 SameSite=None 的客户端都应该忽略它,并像未设置属性一样继续操作。


    警告:

    许多旧版本的浏览器(包括Chrome、Safari和UC浏览器)都与新的None属性不兼容,可能会忽略或限制cookie。这种行为在当前版本中是确定的,但您应该检查您的流量,以确定受影响的用户比例。您可以在Chromium站点上看到已知不兼容客户端的列表

    有关如何更新cookie以成功处理对SameSite=None的更改,以及浏览器行为差异的详细信息,请看后续文章,SameSite cookie 秘诀

    展开全文
  • 想请问一下大家, 我在我的Springboot项目的配置中设置了 server: servlet: session: cookie: same-site: none secure: true 就是把sameSite设为了none 请问这样会不会有什么安全问题, (我的跨域配置, 有设置允许指定...
  • 谷歌浏览器80版本以后,如何处理出现的问题SameSite跨域问题

    谷歌浏览器80版本以后,出现的问题:

    情况一:

    如果地址栏里的域名是aaa.com,而对应的Ajax请求也是aaa.com,那么可以将aaa.com下的cookie传给任何aaa.com域名的请求,比如:登录aaa.com时产生的cookie(假设cookie为token=123),在Ajax调用aaa.com/api/queryUser接口时是可以将cookie传递过去的,不管对应的cookie有没有设置Secure与SameSite=None。

    情况二:

    如果地址栏里的域名是aaa.com,而对应的Ajax请求是bbb.com,那么可以将bbb.com下的cookie传给任何bbb.com域名的请求,比如:登录bbb.com时产生的cookie(假设cookie为token=123),在Ajax调用bbb.com/api/queryUser接口时是可以将cookie传递过去的,但是前提是token=123的这个cookie必须设置 Secure与SameSite=None属性,否则即使是同域名cookie也是无法传递的。注意:这里说的是地址栏里是aaa.com,访问的是bbb.com/api/queryUser,跨域名的话,即使加了Secure与SameSite=None,也是不行的哦。

     完整的Nginx配置:

    upstream tomcat_server {
                    server 127.0.0.1:8001  weight=10 max_fails=2 fail_timeout=30s;
    }
    
    
    log_format newmain '$remote_addr - "$http_x_forwarded_for" - "$http_j_forwarded_for" - $remote_user [$time_local]'
    '"$request" $status $bytes_sent '
    '"$http_referer" "$http_user_agent" '
    '"$gzip_ratio"';
    #限流模块
    limit_req_zone $binary_remote_addr zone=ip_limit_index:20m rate=500000r/s;
    
    server
    {
          listen 80;
    
          server_name              www.xxx.com ;
         access_log               /export/xxx/nginx/logs/www.xxx.com/www.xxx.com_access.log main;
          error_log                /export/xxx/nginx/logs/www.xxx.com/www.xxx.com_error.log warn;
          error_page 411 = @error_page;
    
          root /export/App/www.xxx.com/;   
          
          location / {
        	  
            set $flag "flag";
             #如果是指定域名的请求,设置跨域
            if ($http_origin ~* "(xxx.com|xxx.cn)") {
                add_header 'Access-Control-Allow-Origin' "$http_origin";
              add_header 'Access-Control-Allow-Credentials' 'true';
              add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
              add_header 'Access-Control-Allow-Headers' 'Origin,X-Requested-With,Content-Type,Accept,Cache-Control,frLo';
              add_header 'Access-Control-Max-Age' 1728000;
            }
           
            #如果是预检请求,设置跨域后直接返回
            if ($request_method = 'OPTIONS') {
                add_header 'Access-Control-Allow-Origin' "$http_origin";
              add_header 'Access-Control-Allow-Credentials' 'true';
              add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
              add_header 'Access-Control-Allow-Headers' 'Origin,X-Requested-With,Content-Type,Accept,Cache-Control,frLo';
              add_header 'Access-Control-Max-Age' 1728000;
              #预检请求直接返回
              return 200;
            }
            
            
            proxy_next_upstream     http_500 http_502 http_503 http_504 error timeout invalid_header;
            proxy_set_header        Host  $host;
            proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
            #设置cookie,当然也可以对以后的cookie追加SameSite=None; Secure配置
            add_header Set-Cookie 'mycookie=xxxx;Path=/;SameSite=None; Secure';
            proxy_pass              http://tomcat_server;
            expires                 0;
            fastcgi_buffer_size 128k;
    		fastcgi_buffers 32 32k;
    	}
    		
    		 
        #静态资源的处理
        location ~ .*\.(css|js|ico)$ {
    		gzip on;
    		gzip_min_length 1k;
    		gzip_buffers 4 16k;
    		gzip_comp_level 3;
    		gzip_types text/plain application/x-javascript text/css application/xml text/javascript image/jpeg image/gif image/png image/x-icon;
    		gzip_vary on;
    		gzip_disable "MSIE [1-6]\.";
        }
    
        location /logs/ {
            autoindex       off;
            deny all;
        }  
         
    }
    

    如何在Chrome浏览器中模拟请求或修改请求的域名

     F12打开调试模式,在请求路径上右键,然后Copy as fetch,打开Console标签页,粘贴后回车,再回到刚才的Network标签页就可以看到刚才在console里发送的请求了,当然console里可以修改域名及请求的参数。

     

     如何在Chrome浏览器中临时修改SameSite=None和Secure

    然后打上勾 

     

     右键编辑SameSite为None,

     

     此时就算刷新页面编辑的值也不会变,除非清楚缓存或者等当前会话过期。当然这个与Expires/Max-Age这一列的属性有关,如果是Session类型的就是会话过期就还原了。但是这只是临时的方案。

     Nginx新增cookie:

    add_header Set-Cookie 'mycookie=xxxx;Path=/;SameSite=None; Secure';

     

    展开全文
  • Cookie的SameSite属性

    2021-03-30 18:22:30
    SameSite说明 Cookie是可用于向网站添加数据存储的方法之一。多年来,虽然它们的功能不断增长和发展,但给平台留下了一些棘手的问题,特别是用户隐私和安全问题。为了解决这个问题,各主流浏览器(包括Chrome、Fire...

    本文翻译至:
    SameSite说明

    Cookie是可用于向网站添加数据存储的方法之一。多年来,虽然它们的功能不断增长和发展,但给平台留下了一些棘手的问题,特别是用户隐私和安全问题。为了解决这个问题,各主流浏览器(包括Chrome、Firefox和Edge)都正在改变它们的行为,以此来提高安全性和保护用户隐私。

    每个cookie都是由一些以key-value键值对存在的属性属性,开发者可以使用这些属性控制了cookie具体功能。例如你可能已经使用这些属性来设置诸如到期日期或指定cookie只能通过HTTPS发送。服务器端则通过在其响应头中使用Set-Cookie来设置cookie。关于Cookie更多的细节,可以参考RFC6265bis,本文只做简短的介绍。

    假设你有一个博客,你想向你的用户展示一个 "最新 "的广告条,并且用户可以关闭它,并且期望在指定的一个月内不再出现。你可以把这个设置存储在一个cookie中,设置它在一个月内(2,600,000秒)过期,并且只通过HTTPS发送。对应的设置如下:

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

    服务端使用Set-Cookie设置cookie

    当你的读者浏览一个符合这些要求的页面时,他们的数据传输是安全的,而且cookie的过期时间是一个月,浏览器就会在其请求中发送这个Cookie。

    Cookie: promo_shown=1
    

    在这里插入图片描述

    您还可以在JavaScript中使用document.cookie添加和读取该网站的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的请求中,往往会存在延迟的情况,因此需要对cookie的数量和大小进行限制,也可以使用Max-age属性来设置cookie超时时间

    什么是第一方和第三方Cookie?

    在你浏览和查看某些网站的Cookie的时候,你可能会注意到会存在不同域名的Cookie,而不仅仅只有你当前正在浏览的这个网站的Cookie,这里与当前网站域名(你在浏览器地址输入栏中的域名)一致的Cookie被称为第一方Cookie,来自当前正在访问的网站域名的就被称为第三方Cookie。当然第一方和第三方取决于当前用户正在浏览哪个网站。
    在这里插入图片描述
    在本文开头提到的博客网站中,比如说你的一篇博客文章里有一张特别神奇的猫的图片,它的托管地址是/blog/img/amazing-cat.png。因为它是一张很神奇的图片,所以另一个人直接在自己的网站上使用了它,这时如果一个访问者去过你的博客,并且有promo_shown cookie,那么当该用户在其他人(拿你博客中的图片到他网站的人)的网站上查看amazing-cat.png时,这个cookie就会将被发送到该图片的请求中(这个请求是在别人的网站上查看“猫”这张图的请求)。这种情况下这个Cookie实际上没有什么用,因为promo_shown在这个别人的网站上并没有被用来做任何事情,而只是增加了请求的开销。

    这种机制让网站在使用第三方资源或上下文环境时可以保持对应的状态。例如,如果你在你的网站上嵌入了一个YouTube视频,那么访问者将在播放器中看到一个 "稍后观看 "的选项。如果你的访问者已经登录了YouTube,那么这种场景就会以Cookie的形式在你嵌入的播放器中生效,也就是说 "稍后观看 "按钮只会一次性保存视频,而不是提示他们登录,或者将用户导航到YouTube。
    在这里插入图片描述

    人们可以基于互联网构建很多优秀的软件,主要是基于互联网开发的文化底蕴。但是,这也带来了一些安全和隐私问题。跨站请求伪造(CSRF)攻击就是依赖于Cookie的这种机制,即无论谁发起的请求,都会在任何给定来源的请求中附加cookie。例如,如果你访问evil.example,那么它也可以触发your-blog.example的请求,而浏览器也会相应的添加上相关的cookies。如果你的博客没有对请求做安全验证的话,那么evil.example可能会触发删除帖子或添加自己的内容等行为。

    用户也开始意识到Cookie会被用来追踪他们在多个网站上的活动。但是直到现在,还没有一种方法可以明确说明网站使用cookie具体意图。在本文提到的你博客网站的promo_shown cookie原则上应该只在第一方的上下文中使用,然而一些其他网站的widget组件确实就是要提供对应的功能给第三方网站嵌入进去使用的。

    用SameSite属性来指定Cookie的使用方式

    SameSite属性的引入(在RFC6265bis中定义),允许你声明你的cookie是否应该被限制在第一方或同站点上下文中。这里的“站点”是指域名和域名前面部分的组合,例如,域名www.web.dev 中, web.dev就是一个站点

    例如:

    如果用户浏览www.web.dev这个网站,同时在该网站中请求了static.web.dev的图片,这样属于同一站点的访问
    

    根据公共后缀列表中的定义,不仅是.com这样的顶级域名,也包括github.io这样的域名,规定了 your-project.github.io 和 my-project.github.io 可以作为单独的站点来计算。
    例如:

    如果用户在your-project.github.io中请求了my-project.github.io的图片,这种就属于跨站点访问
    

    为了对这种跨站点的访问进行限制,cookie引入SameSite属性并提供了三种不同的方式来控制这种行为。你可以选择不指定该属性,也可以使用Strict或Lax来限制cookie的只在同一个站点中执行请求

    如果将SameSite设置为Strict,cookie将只在第一方上下文中发送。也就是说只有Cookie的站点与浏览器地址栏中的一致时,cookie才会被发送。例如promo_shown cookie可以设置如下

    Set-Cookie: promo_shown=1; SameSite=Strict
    

    这种情况下如果用户在你的站点内访问不同的链接时,Cookie就会被发送。但是如果用户是从第三方的链接或者邮件中的链接进入你的网站中的,这个Cookie就不会被发送。这个Cookie相关的服务是登录或者购买订单相关的请求的话,这样的限制是合理的。但是如果只是为了显示一些普通的信息,例如本文提到的promo_shown,就会有点不太适用了。

    还好SameSite中的Lax可以解决这类问题,在文章开头提到的神奇的猫的图片例子中,就可以使用Lax属性来对Cookie进行设置

    注意:
    无论是Strict还是Lax都不是解决网站安全的完整解决方案。Cookie 是作为用户请求的一部分发送的,都要对他们进行完整的安全校验,同时不要用cookie存储机密的信息

    如果你需要让其他网站的请求也发送cookie的话,可以设置SameSite = None来实现。如果你的站点是要提供服务和widget给其他网站使用,或者需要支持跨站点登录的话,需要把SameSite设置为None
    在这里插入图片描述

    没有配置SameSite的默认行为变化

    虽然SameSite属性得到了广泛的支持,但遗憾的是它并没有被开发者广泛采用。到处随便发送Cookie的情况依然存在,这样的话用户还是容易受到CSRF的攻击,以及个人信息还是会被泄露。为了解决这种处境,提出了以下两条规则

    • 没有SameSite属性的Cookies将被视为SameSite=Lax。
    Set-Cookie: promo_shown=1
    

    这种情况下并没有设置SameSite,但是会被自动变为

    Set-Cookie: promo_shown=1; SameSite=Lax
    
    • 带有SameSite=None的Cookies还必须指定为Secure才行。
    Set-Cookie: widget_session=abc123; SameSite=None
    

    这种设置无效,正确的设置为:

    Set-Cookie: widget_session=abc123; SameSite=None; Secure
    

    Chrome从84版开始就支持了这种默认行为。Firefox 从 Firefox 69 开始支持,并将在未来使其成为默认行为。要在Firefox中测试这些变化,请打开about:config并设置network.cookie.sameSite.laxByDefault。Edge也计划支持这种默认行为。

    展开全文
  • 设置方法如下: 1)chrome地址栏输入chrome://flags 2)通过禁用“SameSite by default cookies”和“Cookies without SameSite must be secure”功能开关 3)重新启动浏览器 2、Set-Cookie:SameSite=None 就是将...
  • Cookie 的 SameSite 属性

    万次阅读 多人点赞 2019-10-09 14:06:01
    今天在做前后端分离姓名的时候...在未来的Chrome版本中,只有当跨站请求设置为“SameSite=None”和“Secure”时,才会发送cookie。您可以在应用程序>存储> cookies下查看开发工具中的cookie,并在https://www...
  • CORS中的withCredentials 与 SameSite withCredentials与SameSite都是针对Cookie跨站的属性,都与CSRF安全相关 但针对同样的事,两者的态度事对立的,一个希望允许,一个希望限制 withCredentials可正对XHR;...
  • Chrome从70版本开始,出现了...80版本开始默认SameSite=Lax,导致跨域Cookie传输收到限制。我们遇到的问题是从其他网站跳转回来的时候,地址栏在正常地址的基础上出现了JSESSIONID=XXXXXXXXX,导致原有session失效。...
  • 为了解释CSRF与SameSite的成因、关系与历史,我们首先需要对Cookie有一个基础的了解。 我们知道,HTTP请求本身是无状态的,正常来说,服务端收到请求后并不知道请求者是谁; 所以为了记录用户的标识信息,来提供更好...
  • Nginx新增SameSite属性的cookie
  • cookie SameSite属性

    2021-04-08 10:36:49
    cookie之SameSite属性 问题描述: 前端调取后端返回base64编码格式字符串验证码的接口,response返回set-Cookie Set-Cookie: laravel_session=eyJpdiI6IlNKbDdBeU5PdjBVOFJsYnpYSmRLRHc9PSIsInZh bHVlIjoiekdRc2...
  • 系统代码扫描报不安全错误 具有不安全、不正确或缺少samesite属性的cookie,请问如何解决这个问题。核心问题点在什么地方,能通过java代码修复吗?
  • 系统代码扫描报不安全错误 具有不安全、不正确或缺少samesite属性的cookie,请问如何解决这个问题。核心问题点在什么地方,能通过java代码修复吗?用的是weblogic,可以通过配置文件weblogic.xml设置吗?
  • 浏览器默认设置SameSite属性的作用

    千次阅读 2022-01-30 16:10:43
    文章目录系列文章目录一、CSRF 攻击是什么二、SameSite 属性 一、CSRF 攻击是什么 CSRF(Cross-site request forgery),中文名称:跨站请求伪造 CSRF攻击往往通过盗取你的 Cookie 信息,而Cookie 往往用来存储用户...
  • iframe、SameSite与CEF

    2021-06-09 14:17:26
    由于CEF(Chrome内核)的安全策略,在51版本以前、80版本以后,绝大多数情况下是禁止嵌入的iframe提交Cookie的(下文会列出哪些禁止),所以需要浏览器配置策略来允许iframe提交Cookie,这个策略就是SameSite。...
  • 如何在Chrome浏览器中临时修改SameSite=None和Secure
  • 在未来的Chrome版本中,只有当跨站请求设置为“SameSite=None”和“Secure”时,才会发送cookie。您可以在应用程序>存储> cookies下查看开发工具中的cookie,并在...
  • SameSite 属性

    千次阅读 2019-12-09 11:31:05
    在做前端获取接口数据时...A cookie associated with a cross-site resource at http://xx.xxx.xxx.xx/ was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with ...
  • Cookies的SameSite属性

    千次阅读 2021-04-19 12:57:41
    自Chrome 51版本开始,浏览器的 Cookies 新增了一个SameSite属性,用来防止 CSRF 攻击和信息泄漏,更多信息参考chrome Feature: 'SameSite' cookie attribute。 简单回顾什么是CSRF攻击 Cookies往往用来...
  • 跨域 SameSite secure

    2020-10-28 09:47:35
    解决方案: 方案一: 直接关闭 samesite 功能就行, 复制 chrome://flags/#same-site-by-default-cookies 到地址栏,设置 SameSite by default cookies 为 disabled,就能解决这个问题。 火狐浏览器 输入 about:...
  • 引入原因 浏览器安全性 防止跨站攻击CSRF等 废除第三方cookie cookie简介 ...在引入 SameSite 限制之前,cookie 存储在浏览器中时,它们被附加到每个HTTP web 请求,并通过设置 Cookie HTTP 响应

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 65,878
精华内容 26,351
关键字:

samesite