cookie

单个域名下浏览器Cookie限制个数为多少

起因

去网上搜了下关于Cookie的介绍,看了好几篇都长得很一样,阉割一下内容不外乎说是"不同浏览器限制cookie数不同,大致在30-50这个范围,(前缀)浏览器允许Cookie多达4KB左右,包括名、值、等号"。

我还在上学那会儿,包括后面毕业后工作一段时间,我也没有特别去关注过这个话题,基本上如果面试官问到我了,也就把网上知道的这些讲了一下。

今年的遭遇给了我思考的时间特别多,最近我又重新去仔细读了下楼上那句话,我发现我读不懂了,第一个,我看的资料并不是特别权威的,也都是网上的博客帖子,对浏览器限制30-50个这个范围产生了一个质疑,是真的吗?第二个是允许多达4KB左右,就很迷糊,到底是一个域名下所有的Cookie加起来的值是4KB左右,还是说单独的Cookie的一个Name所表示的信息它可以是4KB左右,这让我很迷啊。

当浏览器全面禁用三方 Cookie

苹果公司前不久对 Safari 浏览器进行一次重大更新,这次更新完全禁用了第三方 Cookie,这意味着,默认情况下,各大广告商或网站将无法对你的个人隐私进行追踪。而微软和 Mozilla 等也纷纷采取了措施禁用第三方 Cookie,但是由于这些浏览器市场份额较小,并没有给市场带来巨大的冲击。

2017 年截至 2019 年底, Google 面临的罚款总额已经超过 93 亿欧元,其中一大原因便是侵犯用户数据隐私。迫于巨大压力,Google Chrome 官方团队前不久也宣布,为了提升用户隐私和安全,未来两年将完全禁用第三方 Cookie

在完全不能写入三方 Cookie 的情况下,将会对前端的数据读写方式,甚至是整个广告行业带来巨大影响。

Cookie 的意义

众所周知,HTTP 协议是无状态的协议,如果你在同一个客户端向服务器发送多次请求,服务器不会知道这些请求来自同一客户端。

这正是 HTTP 协议得以广泛应用的原因,试想一下,如果它是有状态协议,你必须要时刻与服务器建立链接,那么如果连接意外断开,整个会话就会丢失,重新连接之后一般需要从头开始;而如果是无状态协议,使得会话与连接本身独立起来,这样即使连接断开了,会话状态也不会受到严重伤害,保持会话也不需要保持连接本身。

如果 HTTP 协议只是用来访问静态文件,那不会有任何问题,但是如果你要为广大用户提供更好的服务,服务器就需要知道每个请求具体来自于哪个用户,比如你在逛淘宝的时候你只需要登录一次,当你发起一次购买请求,服务器就已经知道你登录过了,不会再让你进行登录。

所以 HTTP 协议需要占用浏览器的一小块存储,存储当前访问用户的一些

对于未来chrome80 samesite问题的兼容解决方案

未来chrome80会默认(SameSite: lax)在跨域请求的情况下不允许跨域携带cookie给后端,导致所有跨域场景下使用cookie进行鉴权的服务会受到影响。
网站可以选择显式关闭SameSite属性,将其设为None。不过,前提是必须同时设置Secure属性(Cookie 只能通过 HTTPS 协议发送),否则无效。
但是设置了SameSite为None, 很难保证在非chrome浏览器上一定是兼容的,所以基于兼容性考虑有两个方案:
1.采用两套cookie 例如原cookie中已经种入了session-id=xxxxx,可以维持不变,再额外种入另一个cookie session-id-2=xxxxx同时设置特性SameSite为none secure: true。这样可以兼容新旧版的所有浏览器。这样就要求后端取得时候判断session-id不存在,再取cookie session-id-2的值
2.JWT方案,统一把token放在header的authorization,就不存在跨域携带cookie的困扰了
第一个方案主要适配在于后端,前端基本不需要变动,第二个方案需要前后端做一定的改造,视情况而定

    

php设置samesite cookie,有效防止CSRF

php设置samesite cookie,支持所有PHP版本。

PHP 7.3 的setcookie函数已经支持samesite属性,但对于7.3以下版本,可以用以下函数代替:

<?php
$options = [
    'expires' => time()+18400,
    'domain' => 'localhost',
    'httponly' => false,
    'samesite' => 'Lax',
    'secure' => false,
    'path' => '/'
  ];

function samesite_setcookie($name, $value, array $options)
{
    $header = 'Set-Cookie:';
    $header .= rawurlencode($name) 
                

深入了解浏览器存储–从cookie到WebStorage、IndexedDB

前言

随着移动网络的发展与演化,我们手机上现在除了有原生 App,还能跑“WebApp”——它即开即用,用完即走。一个优秀的 WebApp 甚至可以拥有和原生 App 媲美的功能和体验。WebApp 优异的性能表现,有一部分原因要归功于浏览器存储技术的提升。cookie存储数据的功能已经很难满足开发所需,逐渐被WebStorage、IndexedDB所取代,本文将介绍这几种存储方式的差异和优缺点。

 一、Cookie

1.Cookie的来源

Cookie 的本职工作并非本地存储,而是“维持状态”。 因为HTTP协议是无状态的,HTTP协议自身不对请求和响应之间的通信状态进行保存,通俗来说,服务器不知道用户上一次做了什么,这严重阻碍了交互式Web应用程序的实现。在典型的网上购物场景中,用户浏览了几个页面,买了一盒饼干和两瓶饮料。最后结帐时,由于HTTP的无状态性,不通过额外的手段,服务器并不知道用户到底买了什么,于是就诞生了Cookie。它就是用来绕开HTTP的无状态性的“额外手段”之一。服务器可以设置或读取Cookies中包含信息,借此维护用户跟服务器会话中的状态。

我们可以把Cookie 理解为一个存储在浏览器里的一个小小的文本文件,它附着在 HTTP 请求上,在浏览器和服务器之间“飞来飞去”。它可以携带用户信息,当服务器检查 Cookie 的时候,便可以获取到客户端的状态。

在刚才的购物场景中,当用户选购了第一项商品,服务器在向用户发送网页的同时,还发送了一段Cookie,记录着那项商品的信息。当用户访问另一个页面,浏览器会把Cookie发送给服务器,于是服务器知道他之前选购了什么。用户继续选购饮料,服务器就在原来那段Cookie里追加新的商品信息。结帐时,服务器读取发送来的Cookie就行了。

2.什么是Cookie及应用场景

Cookie指某些网站为了辨别用户身份而储存在用户本地终端上的数据(通常经过加密)。 cookie是服务端生成,客户端进行维护和存储。通过cookie,可以让服务器知道请求是来源哪个客户端,就可以进行客户端状态的维护,比如登陆后刷新,请求头就会携带登陆时response header中的set-cookie,Web服务器接到请求时也能读出cookie的值,根据cookie值的内容就可以判断和恢复一些用户的信息状态。

如上图所示,Cookie 以键值对的形式存在

典型的应用场景有:

  • 记住密码,下次自动登录。
  • 购物车功能。
  • 记录用户浏览数据,进行商品(广告)推荐。

3.Cookie的原理及生成方式

Cookie的原理

第一次访问网站的时候,浏览器发出请求,服务器响应请求后,会在响应头里面添加一个Set-Cookie选项,将cookie放入到响应请求中,在浏览器第二次发请求的时候,会通过Cookie请求头部将Cookie信息发送给服务器,服务端会辨别用户身份,另外,Cookie的过期时间、域、路径、有效期、适用站点都可以根据需要来指定。

Cookie的生成方式主要有两种:

            

跨站请求伪造与 Same-Site Cookie

跨站请求伪造

跨站请求伪造(又被称为 CSRF 或者 XSRF ),它源自一个域网站向另一个域网站发起请求的简单功能。攻击者通过一些技术手段欺骗用户使用浏览器去访问一个自己曾经认证过的网站并执行一些敏感操作(如转账)。

一个域网站向另一个域的网站发起请求的方式有很多,例如点击一个超链接、加载静态资源、提交表单以及直接发起 ajax 请求等。如:

<a href="http://a.com/xx">点击有惊喜</a>    # 诱导用户点击

<img src="http://a.com/xx" >     # 浏览器默认加载资源 - 图片

<link href="http://a.com/xx" rel="stylesheet" >
        

跨站请求伪造已死!

跨站请求伪造已死!

在连续不断的被跨站请求伪造折磨了这么多年后,我们现在终于有了一个合理的解决方案。一个对网站拥有者没有技术负担、实施起来没有难度、部署又非常简单的方案,它就是 Same-Site Cookies。

和互联网历史一样悠久的跨站请求伪造

跨站请求伪造(又被称为 CSRF 或者 XSRF )似乎一直都存在着。它源自一个网站必须向另一个网站发出请求的简单功能。比如像在页面中嵌入下面的表单代码。

<form action="https://your-bank.com/transfer" method="POST" id="stealMoney">  
<input type="hidden" name="to" value="Scott Helme">  
<input type="hidden" name="account" value="14278935">  
<input type="hidden" name="amount" value="£1,000">复制代码

当你的浏览器载入这个页面之后,上面的表单将会由一个简单的 JS 片段来实现提交。

document.getElementById("stealMoney").submit();复制代码
        

再见,CSRF:讲解set-cookie中的SameSite属性

SameSite-cookies是一种机制,用于定义cookie如何跨域发送。这是谷歌开发的一种安全机制,并且现在在最新版本(Chrome Dev 51.0.2704.4)中已经开始实行了。SameSite-cookies的目的是尝试阻止CSRF(Cross-site request forgery 跨站请求伪造)以及XSSI(Cross Site Script Inclusion (XSSI) 跨站脚本包含)攻击。详细介绍可以看这一篇文章(https://tools.ietf.org/html/draft-west-first-party-cookies-06)。…