精华内容
下载资源
问答
  • 一个PSR-15中间件,用SameSite Cookie保护您的网站 :cookie: 要求 PHP 7.2+或8.0+ 安装 composer require selective/samesite-cookie SameSite Cookie 相同站点的cookie(“仅第一方”或“第一方”)使服务器断言...
  • Cookie 的 SameSite 属性

    万次阅读 热门讨论 2019-10-09 14:06:01
    今天在做前后端分离姓名的时候...在未来的Chrome版本中,只有当跨站请求设置为“SameSite=None”和“Secure”时,才会发送cookie。您可以在应用程序>存储> cookies下查看开发工具中的cookie,并在https://www...

    今天在做前后端分离项目的时候遇到了这样一个问题。
    设置了与跨站点资源http://www.****.com/关联的cookie,但没有设置' SameSite '属性。在未来的Chrome版本中,只有当跨站请求设置为“SameSite=None”和“Secure”时,才会发送cookie。您可以在应用程序>存储> cookies下查看开发工具中的cookie,并在https://www.chromestatus.com/feature/5088147346030592和https://www.chromestatus.com/feature/5633521622188032查看更多详细信息。

    去查了资料后发现,因为 HTTP 协议是无状态的,所以很久以前的网站是没有登录这个概念的,直到网景发明 cookie 以后,网站才开始利用 cookie 记录用户的登录状态。cookie 是个好东西,但它很不安全,其中一个原因是因为 cookie 最初被设计成了允许在第三方网站发起的请求中携带,CSRF 攻击就是利用了 cookie 的这一“弱点”,防止 CSRF 攻击的办法已经有 CSRF token 校验和 Referer 请求头校验。为了从源头上解决这个问题,Google 起草了一份草案来改进 HTTP 协议,那就是为 Set-Cookie 响应头新增 SameSite 属性,它用来标明这个 cookie 是个“同站 cookie”,同站 cookie 只能作为第一方 cookie,不能作为第三方 cookie。
    Chrome 51 开始,浏览器的 Cookie 新增加了一个SameSite属性,用来防止 CSRF 攻击和用户追踪。

    SameSite 属性

    Cookie 的SameSite属性用来限制第三方 Cookie,从而减少安全风险。

    它可以设置三个值。

    • Strict
    • Lax
    • None

    Strict
    Strict最为严格,完全禁止第三方 Cookie,跨站点时,任何情况下都不会发送 Cookie。换言之,只有当前网页的 URL 与请求目标一致,才会带上 Cookie。

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

    这个规则过于严格,可能造成非常不好的用户体验。比如,当前网页有一个 GitHub 链接,用户点击跳转就不会带有 GitHub 的 Cookie,跳转过去总是未登陆状态。

    Lax
    Lax规则稍稍放宽,大多数情况也是不发送第三方 Cookie,但是导航到目标网址的 Get 请求除外。

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

    导航到目标网址的 GET 请求,只包括三种情况:链接,预加载请求,GET 表单。详见下表。

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

    设置了Strict或Lax以后,基本就杜绝了 CSRF 攻击。当然,前提是用户浏览器支持 SameSite 属性。

    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 会这样:有人在某个论坛里发了帖子“快看这个微博多搞笑 http://weibo.com/111111/aaaaaa”,结果下面人都回复“打不开啊”;如果你的网站是淘宝,用了 Strict 会这样:某微商在微博上发了条消息“新百伦正品特卖5折起 https://item.taobao.com/item.htm?id=1111111”,结果点进去顾客买不了,也就是说,这种超多用户的、可能经常需要用户从别的网站点过来的网站,就不适合用 Strict 了。

    假如你的网站有用 iframe 形式嵌在别的网站里的需求,那么连 Lax 你也不能用,因为 iframe 请求也是一种异步请求。或者假如别的网站有使用你的网站的 JSONP 接口,那么同样 Lax 你也不能用,比如天猫就是通过淘宝的 JSONP 接口来判断用户是否登录的。

    有时安全性和灵活性就是矛盾的,需要取舍。

    和浏览器的“禁用第三方 cookie”功能有什么区别?

    主流浏览器都有禁用第三方 cookie 的功能,它和 SameSite 有什么区别?我能总结 2 点:

    1. 该功能是由用户决定是否开启的,是针对整个浏览器中所有 cookie 的,即便有些浏览器可以设置域名白名单,那最小单位也是域名;而 SameSite 是由网站决定是否开启的,它针对的是某个网站下的单个 cookie。

    2. 该功能同时禁用第三方 cookie 的读和写,比如 a.com 发起了对 b.com 的请求,这个请求完全不会有 Cookie 请求头,同时假如这个请求的响应头里有 Set-Cookie: foo=1,foo 这个 cookie 也不会被写进浏览器里;而 SameSite 只禁用读,比如 b.com 在用户浏览器下已经写入了个 SameSite cookie foo,当 a.com 请求 b.com 时,foo 肯定不会被发送过去,但 b.com 在这个请求的响应里又返回了: Set-Cookie: bar=1; SameSite=Strcit,这个 bar 会成功写入浏览器的 cookie 里。

    怎样才算第三方请求?

    当一个请求本身的 URL 和它的发起页面的 URL 不属于同一个站点时,这个请求就算第三方请求。那么怎样算是同一个站点?是我们经常说的同源(same-origin)吗,cross-origin 的两个请求就不属于同一个站点?显然不是的,foo.a.com 和 bar.a.com 是不同源的,但很有可能是同一个站点的,a.com 和 a.com:8000 是不同源的,但它俩绝对是属于同一个站点的,浏览器在判断第三方请求时用的判断逻辑并不是同源策略,而是用了 Public Suffix List 来判断。

    后台语言的支持程度

    目前还没有哪个后台语言的 API 支持了 SameSite 属性,比如 php 里的 setcookie 函数,或者 java 里的 java.net.HttpCookie 类,如果你想使用 SameSite,需要使用更底层的 API 直接修改 Set-Cookie 响应头。Node.js 本来就没有专门设置 cookie 的 API,只有通用的 setHeader 方法,不过 Node.js 的框架 Express 已经支持了 SameSite。

    参考网址 https://blog.csdn.net/yanyang1116/article/details/56511009,
    https://www.jianshu.com/p/66f77b8f1759,
    https://www.cnblogs.com/ziyunfei/p/5637945.html,
    http://www.ruanyifeng.com/blog/2019/09/cookie-samesite.html。

    展开全文
  • chrome浏览器解决跨域请求SameSite方案

    万次阅读 热门讨论 2020-08-12 13:42:20
    在chrome浏览器地址栏输入chrome://flags并回车 在搜索栏中输入SameSite by default cookies搜索,并禁用如图中的两项设置 ,改为Disabled即可 点击右下键ReLaunch重启浏览器即可
    1. 在chrome浏览器地址栏输入chrome://flags并回车

    2. 在搜索栏中输入SameSite by default cookies搜索,并禁用如图中的两项设置
      ,改为Disabled即可

    3. 点击右下键ReLaunch重启浏览器即可关闭SameSite

    2021.07.09更新

    1. SameSite by default cookies在chrome91版本已经被移除了,网上有其他解决方案,大家自行搜索。
    2. 我不建议大家通过这种形式来解决跨域问题。跨域是一种浏览器行为,目前主要是有两种解决思路:
    • 避免出现跨域,即保持同域。开发阶段可以在前端页面做代理,通过前端域名将接口转向后端服务;部署时在nginx做代理,同样是通过同一个域名转发至后端接口服务。
    • 在请求中设置跨域头。在后端项目中做跨域配置,或者如果你有nginx,可以在代理时在响应头中设置跨域相关参数。实际上原理是一致的,都是响应头设置跨域参数而已。附上CSDN相关参数截图:

    csdn参数截图

    展开全文
  • samesite cookie安全特性

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

    2021-05-28 10:04:53
    为什么我的chrome关于<strong>SameSite by default cookies和<strong>Cookies without SameSite must be secure这两个设置找不到了,在线等~ <p><img alt="" height="677" src=...
  • 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 ...

    在做前端获取接口数据时发现控制台打印了这样一段信息:

    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 cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

     

     

    去查了资料后发现,因为 HTTP 协议是无状态的,所以很久以前的网站是没有登录这个概念的,直到网景发明 cookie 以后,网站才开始利用 cookie 记录用户的登录状态。cookie 是个好东西,但它很不安全,其中一个原因是因为 cookie 最初被设计成了允许在第三方网站发起的请求中携带,CSRF 攻击就是利用了 cookie 的这一“弱点”,防止 CSRF 攻击的办法已经有 CSRF token 校验和 Referer 请求头校验。为了从源头上解决这个问题,Google 起草了一份草案来改进 HTTP 协议,那就是为 Set-Cookie 响应头新增 SameSite 属性,它用来标明这个 cookie 是个“同站 cookie”,同站 cookie 只能作为第一方 cookie,不能作为第三方 cookie。
    Chrome 51 开始,浏览器的 Cookie 新增加了一个SameSite属性,用来防止 CSRF 攻击和用户追踪。

    SameSite 属性
    Cookie 的SameSite属性用来限制第三方 Cookie,从而减少安全风险。

    它可以设置三个值。

    Strict
    Lax
    None
    Strict
    Strict最为严格,完全禁止第三方 Cookie,跨站点时,任何情况下都不会发送 Cookie。换言之,只有当前网页的 URL 与请求目标一致,才会带上 Cookie。

    Set-Cookie: CookieName=CookieValue; SameSite=Lax;
    1
    这个规则过于严格,可能造成非常不好的用户体验。比如,当前网页有一个 GitHub 链接,用户点击跳转就不会带有 GitHub 的 Cookie,跳转过去总是未登陆状态。

    Lax
    Lax规则稍稍放宽,大多数情况也是不发送第三方 Cookie,但是导航到目标网址的 Get 请求除外。

    Set-Cookie: CookieName=CookieValue; SameSite=Lax;
    1
    导航到目标网址的 GET 请求,只包括三种情况:链接,预加载请求,GET 表单。详见下表。

    请求类型    示例    正常情况    Lax
    连接    <a href="..."></a>    发送 Cookie    发送 Cookie
    预加载    <link rel="prerender" href="..."/>    发送 Cookie    发送 Cookie
    GET 表单    <form method="GET" action="...">    发送 Cookie    发送 Cookie
    POST 表单    <form method="POST" action="...">    发送 Cookie    不发送
    iframe    <iframe src="..."></iframe>    发送 Cookie    不发送
    AJAX    $.get("...")    发送Cookie    不发送
    Image    <img src="...">    发送Cookie    不发送
    设置了Strict或Lax以后,基本就杜绝了 CSRF 攻击。当然,前提是用户浏览器支持 SameSite 属性。

    None
    Chrome 计划将Lax变为默认设置。这时,网站可以选择显式关闭SameSite属性,将其设为None。不过,前提是必须同时设置Secure属性(Cookie 只能通过 HTTPS 协议发送),否则无效。
    下面的设置无效。

    Set-Cookie: widget_session=abc123; SameSite=None
    1
    下面的设置有效

    Set-Cookie: widget_session=abc123; SameSite=None; Secure
    1
    该用哪种模式?
    该用哪种模式,要看你的需求。比如你的网站是一个少数人使用的后台管理系统,所有人的操作方式都是从自己浏览器的收藏夹里打开网址,那我看用 Strict 也无妨。如果你的网站是微博,用了 Strict 会这样:有人在某个论坛里发了帖子“快看这个微博多搞笑 http://weibo.com/111111/aaaaaa”,结果下面人都回复“打不开啊”;如果你的网站是淘宝,用了 Strict 会这样:某微商在微博上发了条消息“新百伦正品特卖5折起 https://item.taobao.com/item.htm?id=1111111”,结果点进去顾客买不了,也就是说,这种超多用户的、可能经常需要用户从别的网站点过来的网站,就不适合用 Strict 了。

    假如你的网站有用 iframe 形式嵌在别的网站里的需求,那么连 Lax 你也不能用,因为 iframe 请求也是一种异步请求。或者假如别的网站有使用你的网站的 JSONP 接口,那么同样 Lax 你也不能用,比如天猫就是通过淘宝的 JSONP 接口来判断用户是否登录的。

    有时安全性和灵活性就是矛盾的,需要取舍。

    和浏览器的“禁用第三方 cookie”功能有什么区别?
    主流浏览器都有禁用第三方 cookie 的功能,它和 SameSite 有什么区别?我能总结 2 点:

    该功能是由用户决定是否开启的,是针对整个浏览器中所有 cookie 的,即便有些浏览器可以设置域名白名单,那最小单位也是域名;而 SameSite 是由网站决定是否开启的,它针对的是某个网站下的单个 cookie。

    该功能同时禁用第三方 cookie 的读和写,比如 a.com 发起了对 b.com 的请求,这个请求完全不会有 Cookie 请求头,同时假如这个请求的响应头里有 Set-Cookie: foo=1,foo 这个 cookie 也不会被写进浏览器里;而 SameSite 只禁用读,比如 b.com 在用户浏览器下已经写入了个 SameSite cookie foo,当 a.com 请求 b.com 时,foo 肯定不会被发送过去,但 b.com 在这个请求的响应里又返回了: Set-Cookie: bar=1; SameSite=Strcit,这个 bar 会成功写入浏览器的 cookie 里。

    怎样才算第三方请求?
    当一个请求本身的 URL 和它的发起页面的 URL 不属于同一个站点时,这个请求就算第三方请求。那么怎样算是同一个站点?是我们经常说的同源(same-origin)吗,cross-origin 的两个请求就不属于同一个站点?显然不是的,foo.a.com 和 bar.a.com 是不同源的,但很有可能是同一个站点的,a.com 和 a.com:8000 是不同源的,但它俩绝对是属于同一个站点的,浏览器在判断第三方请求时用的判断逻辑并不是同源策略,而是用了 Public Suffix List 来判断。

    后台语言的支持程度
    目前还没有哪个后台语言的 API 支持了 SameSite 属性,比如 php 里的 setcookie 函数,或者 java 里的 java.net.HttpCookie 类,如果你想使用 SameSite,需要使用更底层的 API 直接修改 Set-Cookie 响应头。Node.js 本来就没有专门设置 cookie 的 API,只有通用的 setHeader 方法,不过 Node.js 的框架 Express 已经支持了 SameSite。

    参考网址 https://blog.csdn.net/yanyang1116/article/details/56511009,

    https://blog.csdn.net/yanyang1116/article/details/56511009
    https://www.jianshu.com/p/66f77b8f1759,
    https://www.cnblogs.com/ziyunfei/p/5637945.html,
    http://www.ruanyifeng.com/blog/2019/09/cookie-samesite.html。
     

    展开全文
  • 前后端分离Cookie sameSite坑 跨域之坑

    万次阅读 热门讨论 2019-01-22 15:18:09
    在前后端分离解决跨域问题过程中,利用CORS解决跨域问题,前后端按照规范处理了...SameSite Cookie 应该是一种新的cookie属性值,我看到很多大型网站如百度都没有用到, 他是防止 CSRF 攻击 具体可看 https://www.cnb...

    在前后端分离解决跨域问题过程中,利用CORS解决跨域问题,前后端按照规范处理了,但不管怎样session都是不一致,所以前端无法登陆无法在本地测试。查了几天资料,中间反反复复,最后要放弃的时候无意中看到一个大神的博客。

    本项目是使用spring-session-data-redis实现HTTP Session集中管理原理

     

    SameSite Cookie 应该是一种新的cookie属性值,我看到很多大型网站如百度都没有用到,
    他是防止 CSRF 攻击 具体可看 https://www.cnblogs.com/ziyunfei/p/5637945.html
    
    spring web 最新版默认生成为SameSite=Lax,奇怪的是用spring-session-data-redis 后 cookie新增了 SameSite这个字段,所以不能携带cookie进行跨域post访问,文档上也不表明什么时候开始的,坑的是默认为Lax也不能设置,
    遂现在将web版本降级

    因为服务端返回给客户端的set-cookie中带有samesite=lax,这就是问题的根源,它表示不能携带cookie进行跨域post访问,然而我们是需要携带cookie的

    解决办法:

    @Bean 
    public CookieSerializer httpSessionIdResolver(){ 
        DefaultCookieSerializer   cookieSerializer = new DefaultCookieSerializer();                                
        cookieSerializer.setCookieName("token"); 
        cookieSerializer.setUseHttpOnlyCookie(false); 
        cookieSerializer.setSameSite(null); 
        return cookieSerializer; 
    
    }
    

    使用的pom依赖

     <dependency>
                <groupId>org.springframework.session</groupId>
                <artifactId>spring-session-data-redis</artifactId>
                <version>2.1.1.RELEASE</version>
     </dependency>

    前端在与后台交互时也得做如下的配置(ajax请求)

    xhrFields: {
        withCredentials: true
    }

    它让ajax能够携带cookie请求,后端需要设置

    response.setHeader("Access-Control-Allow-Credentials", "true");

    允许cookie跨域,这样就大功告成!!!

    展开全文
  • django设置samesite

    2021-04-01 14:09:28
    较新版本的chrome会因samesite策略而禁止跨域的cookie 解决方法在项目中的setting.py设置: SESSION_COOKIE_SAMESITE = 'None' SESSION_COOKIE_SECURE = True 网上的方法都不行,看了一下官网的文档,注意要把...
  • 跨站cookies,SameSite

    万次阅读 2020-05-17 21:39:03
    Indicate whether to send a cookie in a cross-site request by specifying its SameSite attribute Because a cookie’s SameSite attribute was not set or is invalid, it defaults to SameSite=Lax, which will...
  • 谷歌: 1.谷歌浏览器打开chrome://flags/ ...2.搜索samesite 3.SameSiteby default cookies项设置为Disabled即可 IE: 1.打开ie设置——Internet选项 2.隐私——接受所有的Cookies(滚动条到最下方即可)
  • 谷歌关闭SameSite功能

    2021-07-27 17:08:18
    访问chrome://flags/ 搜索SameSite 关闭SameSite
  • 该存储库包含一个中间件,该中间件会自动为Django的旧版本(例如1.11.x,2.2.x或3.0.x)中的会话和csrf cookie设置SameSite属性。 Django 3.1.x不需要此模块,它为会话和csrf cookie引入了SameSite标志的完全支持...
  • ASP.NET Core Cookie SameSite.pdf
  • SameSite=None and Secure

    千次阅读 2020-07-30 14:53:18
    A cookie associated with a cross-site resource at ... A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies.
  • SameSite Cookie

    千次阅读 2019-01-22 15:47:51
    SameSite Cookie,防止 CSRF 攻击 因为 HTTP 协议是无状态的,所以很久以前的网站是没有登录这个概念的,直到网景发明 cookie 以后,网站才开始利用 cookie 记录用户的登录状态。cookie 是个好东西,但它很不安全,...
  • Chrome Cookie SameSite 设置 Chrome 51 开始,浏览器的 Cookie 新增加了一个SameSite属性,用来防止 CSRF 攻击和用户追踪。 Cookie 的SameSite属性用来限制第三方 Cookie,从而减少安全风险。 它可以设置三个值。 ...
  • 关于 chrome 80 后出现的 SameSite 问题

    万次阅读 2020-03-19 22:29:07
    Google 发布的 Chrome 80 中,在所有的 Cookie 中默认设置 SameSite=Lax 来屏蔽所有的第三方 Cookie,详见 Cookies default to SameSite=Lax;并拒绝所有的非 Secure 的Cookie 设为 SameSite=None,详见 Reject ...
  • Chrome 80 Cookie跨域 Samesite Lax 的错误

    万次阅读 2020-07-30 12:55:49
    本地局域网前后端分离的项目,前端是192.168.123.90,后端是192.168.123.2。今天早上发现用户登录报告登录失败(本质...设置cookie时提示:This set-cookie didn't specify a "SameSite" attribute and was defaulte
  • cookie SameSite属性

    2021-04-08 10:36:49
    cookie之SameSite属性 问题描述: 前端调取后端返回base64编码格式字符串验证码的接口,response返回set-Cookie Set-Cookie: laravel_session=eyJpdiI6IlNKbDdBeU5PdjBVOFJsYnpYSmRLRHc9PSIsInZh bHVlIjoiekdRc2...
  • Chrome游览器改变SameSite设置

    千次阅读 2020-11-07 23:36:21
    Chrome浏览器改变SameSite设置 Chrome 默认将没有设置SameSite设置为SameSite=Lax SameSite取值 Strict Strict完全禁止第三方Cookie,跨站点时,任何情况下都不会发送Cookie Lax Lax规则稍稍放宽,大多数情况也是不...
  • Cookie的SameSite属性

    2021-06-16 20:01:03
    SameSite 属性 Chrome 51 开始,浏览器的 Cookie 新增加了一个SameSite属性,用来防止 CSRF 攻击 和用户追踪(第三方恶意获取cookie),限制第三方 Cookie,从而减少安全风险。 SameSite属性可以设置三个值:...
  • 之前做的一个跨域调用的静态页面,反馈使用出现了问题,检查了一下发现Chorme显示这个消息:Indicate whether to send a cookie in a cross-site request by specifying its SameSite attribute 在网上Search了一下...
  • Cookie SameSite属性的扩展 自Chrome 80以来,此扩展程序正在调整Cookie SameSite属性问题。 注意:此扩展名是实验性的。 特征 将SameSite属性添加到Magento会话cookie中。 对于3DS付款,付款网关倾向于通过POST将...
  • This setcookie was blocked because it had the "samesite=none" attribute but did not have the "secure" attribute, which is required in order to use "same=none" SameSite SameSite 有3个可选值 : Str...
  • Chrome/Edge 91版本SameSite by default cookies被移除后的解决方案
  • Chrome浏览器改变SameSite设置
  • Cookies的SameSite属性

    2021-04-19 12:57:41
    自Chrome 51版本开始,浏览器的 Cookies 新增了一个SameSite属性,用来防止 CSRF 攻击和信息泄漏,更多信息参考chrome Feature: 'SameSite' cookie attribute。 简单回顾什么是CSRF攻击 Cookies往往用来...
  • 关于chrome浏览器samesite属性导致cookie跨域失效的可以阅读我之前的博客:《谷歌浏览器新版本Chrome 80默认SameSite导致跨域登录状态失效的问题》 谷歌浏览器85版本后会启动两个默认策略。 根据Cookies default ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 59,157
精华内容 23,662
关键字:

samesite