你真的知道 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