cookie
cookie 的含义
- HTTP是无状态的协议(对于事物处理没有记忆能力，每次客户端和服务端会话完成时，服务端不会保存任何会话信息）：每个请求都是完全独立的，服务端无法确认当前访问者的身份信息，无法辨认上一次的请求发送者和这一次的发送者是不是同一个人。所以服务器与浏览器为了进行会话跟踪，就必须主动的去维护一个状态，这个状态用于告知服务器前后两个请求的是否来自同一个浏览器。这个状态可以通过cookie或者session去实现。
- cookie存储在客户端 ：cookie是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器在下次向同一服务器请求时携带这些数据。
- cookie是不可跨域的：每个cookie都会绑定单一的域名，无法在别的域名下获取使用，一级域名和二级域名之间是允许共享使用的
cookie 的属性
| 属性 | 说明 |
|---|---|
| name=value | 键值对，设置 Cookie 的名称及相对应的值，都必须是字符串类型 。 - 如果值为 Unicode 字符，需要为字符编码。- 如果值为二进制数据，则需要使用 BASE64 编码。 |
| domain | 指定cookie所属域名，默认是当前域名 |
| path | 指定 cookie 在哪个路径（路由）下生效，默认是 '/' 。 如果设置为 /abc，则只有 /abc 下的路由可以访问到该 cookie，如：/abc/read。 |
| maxAge | 以秒为单位设置多少秒之后过期。若为负数，cookie为临时cookie，关闭浏览器即失效；若为0，表示删除cookie。优先级大于expires |
| expires | 过期时间，在设置的某个时间点后该 cookie 就会失效。 |
| sameSite | 网站安全三本柱之一，不会让Cookie去任何危险的地方 |
| httpOnly | 网站安全三本柱之一，只要有我在的地方，别想找到cookie |
| secure | 网站安全三本柱之一，所有与cookie来源不同的请求都别想成功 |
cookie 的网站安全三本柱
secure
- 该cookie是否仅被使用安全协议传输。安全协议有HTTPS,SSL等，在网络上传输数据之前先将数据加密。
- 当 secure 值为 true 时，cookie 在 HTTP 中是无效，在 HTTPS 中才有效。
httpOnly - XSS 之敌
XSS：一般指的是攻击者在有XSS攻击漏洞中的网站植入恶意程序，最常用的攻击方式是，在网站中执行document.cookie并将结果传送给攻击者。
- 若给某个cookie设置了httpOnly属性，则无法通过JS脚本(document.cookie)读取到该cookie的信息，但还是可以通过Application中手动修改cookie，所以在一定程度上可以防止XSS攻击，不是绝对的安全。
sameSite - CSRF之敌
CSRF：一般指攻击者跨domain向网站发出请求，而网站无条件信任cookie而没有再确认或以其他方式验证，只知道这个request带着某个使用者的cookie，便接受了请求。
而sameSite这个属性的特性，浏览器会检查request的来源是否与发布cookie的来源相同，限制第三方cookie的发送场景
sameSite的属性可以进行三种设定
- Strict：完全禁止第三方cookie，跨站点时，任何情况下都不会发送cookie，常用于银行或是购物网站等有现金交易的网站上；
- Lax：默认值。 Lax限制了大多数的第三方请求，但Lax会允许Get请求。 除了下面三种情况外，不发送第三方 Cookie
- 链接：
<a href="..."></a> - 预加载请求：
<link rel="prerender" href="..."/> - GET 表单：
<form method="GET" action="...">
- 链接：
- None：跨站都发送cookie，如果在网站上想要将SameSite的值设定为None的话，网站中的Secure必须要是开启的， None的设定才会生效，算是浏览器为了网站的安全性上做的一些小限制
谷歌8.0新版iframe嵌套跨域请求cookie丢失问题
- 解决方案1： 将sameSite属性值设为None，同时将secure设置为true，即这就需要后端服务应使用https协议访问
- 解决方案2： 设置sameSite = None，会有CSRF风险，所以，可以用token代替cookie方式作为验证；
session
session 的含义
- session是另一种记录服务器和客户端会话状态的机制。
- session是基于cookie实现的，session存储在服务器端，sessionId会被存储到客户端的cookie中。
- session认证流程
- 用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的session;
- 请求返回时将此session的唯一标识信息sessionId返回给浏览器
- 浏览器接收到服务器返回的sessionId信息后，会将此信息存入到cookie中，同时cookie记录sessionId属于哪个域名
- 当用户再次访问服务器的时候，请求会自动判断此域名下是否存在cookie信息，若存在自动将cookie信息发送给服务端，服务端会从cookie中获取sessionId，再根据sessionId查找对应的session信息。若没有找到说明用户没有登录或者登录失败，若找到session证明用户已经登陆可执行后面的操作。
即sessionId是连接cookie和session的一道桥梁。
cookie 和 session 的区别
- 安全性： session 比 cookie 安全，session 是存储在服务器端，相对安全一些，cookie 是存储在客户端，信息容易被窃取。
- 存取值的类型不同：cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，session 可以存任意数据类型。
- 有效期不同： cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，session 一般失效时间较短，客户端关闭（默认情况下）或者 session 超时都会失效。
- 存储大小不同： 单个 cookie 保存的数据不能超过 4K，session 可存储数据远高于 cookie，但是当访问量过多，会占用过多的服务器资源。
cookie的相关问题
- cookie 怎么是怎么做到 http only的，http only主要是防御什么问题；
- cookie 假设在iframe中如何去处理，samesite 又是什么；
- cookie 和session是如何工作的；
- jwt和cookie如何来区分应用；
