你真的知道 Cookie 吗？ SameSite 、 Secure 、 HttpOnly

这两天（已是一个多月前了） SF 上面不少 cookie 的问题，而后还有个 cookie 相关的付费问答。
因此我们今天来这么一节，废话多说点，先说说大致问题方向。

1. 跨域如何携带 cookie
2. chrome 80 版本增强隐私。SameSite=Lax 为默认值，禁止了一部分场景携带 cookie。

Cookie

用于服务端辨别用户身份，储存在用户本地的数据。
能够解决客户端与服务端会话状态的问题，这个状态是指后端服务的状态而非通信协议（HTTP）的状态。

Cookie 值的存储

域名下的 cookie 通常来讲是最大是 4KB。固然你们也不会真的放这么多。

Name / Value

存储是以 Name=Value 的形式。

Domain / Path 做用域

Domain 是限制域名，设置为 www.lilnong.top 的话，cors.lilnong.top 就获取不到了。
Path 是限制路径，若是设置为 /cors 的话，/api 下的请求就不会携带该 cookie。

Expires / Max-Age 有效性

Expires 是当前 Cookie 的过时时间，默认是会话级别。

Max-Age 是当前 Cookie 通过多少秒失效。

1. 大于 0 是计算通过多少秒失效
2. 等于 0 是会话级别，关闭浏览器就失效
3. 小于 0 是指 cookie 无效，当即删除

Max-Age 的优先级比 Expires 更高。

HttpOnly 安全性

设置之后客户端脚本就没法经过 document.cookie 等方式获取。
有助于避免 XSS 攻击。

Secure 安全性

设置之后客户端只有 HTTPS 协议下才会发送给服务端。
使用 HTTPS 安全协议，能够保护 Cookie 在浏览器和 Web 服务器间的传输过程当中不被窃取和篡改。

SameSite 安全性

能够设置 Cookie 在什么场景下会被发送。从而屏蔽跨站时发送 cookie，用于阻止跨站请求伪造攻击（CSRF）。

SameSite 能够设置下面三个值：

1. Strict 只容许同站请求携带 Cookie。好比 lilnong.top 跳转到 www.lilnong.top/cors/，就属于同站。
2. Lax（chrome 80 后的默认值） 容许部分第三方请求场景 携带Cookie。

3. None（chrome 80 前的默认值） 不管是否跨站都会发送 Cookie。必须同时加上 Secure 属性，不然无效，也就是说只支持 HTTPS。

   IOS 12 的 Safari 以及老版本的一些 Chrome 会把 SameSite=none 识别成 SameSite=Strict，因此服务端必须在下发 Set-Cookie 响应头时进行 User-Agent 检测，对这些浏览器不下发 SameSite=none 属性

接下来咱们来比对一下跨站的各个场景，Demo 晚点给吧。

场景类型	场景备注	Strict	Lax	None
连接	<a href>	不发	发	发
预加载	<link rel="prerender">	不发	发	发
get 表单	<form method="get">	不发	发	发
post 表单	<form method="post">	不发	不发	发
iframe	<iframe src>	不发	不发	发
AJAX	<a href>	不发	不发	发
图片	<img src>	不发	不发	发
script	jsonp

查看 Cookie

1. 开发者工具 -> application -> Storage -> Cookies -> 选择对应的域名
   
2. document.cookie 这里只能获取到容许获取 (HTTPOnly) 的。
3. 去本地文件中查看。由于他是持久化的，因此存放在磁盘上。一些优化管家能够删除垃圾（缓存文件）。

设置 Cookie

1. 响应头中的 Set-Cookie，这个属于最经常使用的方式。
   Set-Cookie: key1=value1; path=path; domain=domain; max-age=max-age-in-seconds; expires=date-in-GMTString-format; secure; httponly; SameSite=None
2. document.cookie="key=value" 这种是前端设置 cookie 。

概念解释

「 同站 (same-site)、跨站 (cross-site)」与「 第一方 (first-party)、第三方 (third-party)」这两个概念是等价的。
可是和 浏览器同源策略（SOP） 中的「 同源 (same-origin)、跨域 (cross-origin)」是彻底不一样的概念

同站和跨站

同站是指二级域名+顶级域名，相等便可。
好比 www.lilnong.top 解析一下就是 主机名.二级域名.顶级域名，因此判断规则仍是比较松的。

eTLD 表示有效顶级域名，注册于 Mozilla 维护的公共后缀列表（ Public Suffix List）中，例如，.com、.co.uk、.github.io 等。
eTLD+1 表示，有效顶级域名+二级域名，例如 taobao.com 等。

同源和跨域

同源策略的同源是指两个 URL 的协议/主机名/端口一致。

域名	备注（请求 https://www.lilnong.top）
https://www.lilnong.top	（同源）同协议、同主机、同端口
http://www.lilnong.top	（跨域）不一样协议
https://www.lilnong.top:8081	（跨域）不一样端口
http://www.lilnong.top:8081	（跨域）不一样协议、不一样端口
https://cors.lilnong.top	（跨域）不一样主机

总结

1. 基于上面关于 Cookie 的介绍咱们能够知道，Chrome 跨站时 Cookie 会由于 SameSite 的设置致使异常。
2. 跨域时要携带 Cookie 时，咱们还要注意 withCredentials 的设置。而后就是清除 cookie，重启浏览器了。

微信公众号：前端linong

参考文章

1. 浏览器系列之 Cookie 和 SameSite 属性
2. public_suffix_list
3. PUBLIC SUFFIX LIST
4. Cookie 的 SameSite 属性
5. 当浏览器全面禁用三方 Cookie