小cookie，大智慧
Cookie是什么？cookies是你訪問網站時創建的數據片段文件，通過保存瀏覽信息，它們使你的在線體驗更加輕松。
使用cookies，可以使你保持在線登錄狀態，記錄你的站點偏好，并為你提供本地化支持。
First-party cookies or Third-party cookies
第一方cookie由你訪問的站點創建。該站點指的是地址欄顯示的站點;
第三方cookie是由其他站點創建的。這些站點擁有你當前訪問的網頁上部分資源，如廣告或圖像。
第一方/第三方cookie不是絕對的標簽，而是相對于用戶的上下文。
同一cookie可以是第一方也可以是第三方，這取決于用戶當時所在的網站。
為什么要提強調第三方cookie，這與下面的cookie的SameSite策略密切相關。
cookie的常規使用方式
web服務端發送給瀏覽器的cookie，瀏覽器會存儲并在下次請求原服務器的時候回發cookie。
在HTTP請求模型中以標頭的形式體現：Response中Set-Cookie標頭種植cookie；Request Cookie標頭攜帶(該請求允許攜帶的)cookies
HTTP/1.0 200 OK Content-type: text/html Set-Cookie: yummy_cookie=choco Set-Cookie: X-BAT-FullTicketId=TGT-969171-******; path=/; samesite=none; httponly[page content]Cookie標頭的內容是鍵值對(鍵值對才是具業務含義的cookie)；同名cookie覆蓋原鍵值，不同名cookie會追加到鍵值對。
GET /sample_page.html HTTP/1.1 Host: www.example.org Cookie: yummy_cookie=choco; X-BAT-FullTicketId=TGT-969171-****** “除了服務端響應時使用Set-Cookie標頭種植cookie，瀏覽器javascript也可以種植cookie
cookie的種植面積
Domain和Path屬性定義了cookie的寫入范圍：哪些url的請求可以攜帶該cookie。
Domain指定哪些host能被種植該cookie，如果沒有指定，默認是當前document location所在的host，不包含子域；如果指定了Domain，那么包括子域。
Path 指定能攜帶該cookie的具體url。"/" 是目錄分隔符，會匹配子目錄.
cookie的有效時長
一般情況下瀏覽器關閉，cookie失效；
可通過設置特定的Expires或者Max-Age為cookie設置相對較長的有效時間。
當設置了過期時間，這個設置的時間是相對于瀏覽器而言，而非服務器。
cookie與web安全息息相關
因為cookie是站點私有片段數據，與web上各種攻擊密切相關，如XSS,CSRF.
根據W3c的操作規范，種植cookie時可通過某些屬性限制cookie的使用方式。
發送cookie的物理安全
Secure指定了發送cookie的物理安全：要求以HTTPS形式回發cookie
“Chrome52+、Firefox52+已經支持Secure指令，再使用http請求已經不會攜帶Secure cookie。
即便是Secure指令， 敏感信息也不要放在cookie中， 因為他們天生就不安全，https并不能提供足夠有效的安全防護。
誰能訪問cookie？
web上能訪問cookie的物件有兩種：
瀏覽器請求
JavaScript
HttpOnly指示cookie將不能通過JavaScript的document.cookie編程接口訪問，這樣可以緩解對跨站點腳本（XSS）的攻擊。
如：訪問會話在瀏覽器留置的認證cookie就沒有必要暴露給JavaScript，可對其設置HttpOnly指令 Set-Cookie: X-BAT-TicketId=TGT-969171-******; Expires=Wed, 21 Oct 2020 07:28:00 GMT; Secure; HttpOnly哪些瀏覽器請求能合法攜帶cookie？
首先科普一下重要的web HTTP知識：
對頁面資源的請求，依據請求發起者的源Origin與資源的源Origin的相等關系，被劃分為4類。
Http請求中Sec-Fetch-Site標頭指示了這個屬性：
| cross-site | 請求的發起源與資源源完全不一樣 |
| same-origin | 請求的發起源與資源源完全一樣 |
| same-site | 請求的發起源與資源源不完全一樣，位于同一頂級域名下二級域名 |
| none |
Q1. 源Origin、站Site、域Domain傻傻分不清楚？
觀察www.cnblog.com任意一篇博文的network，看動圖!
在博客頁面www.cnblog.com/xxx/p/110.htm上發起的
www.cnblogs.com/xxx/ajax/Follow/GetFollowStatus.aspx是same-origin請求
blog-static.cnblogs.com/files/shwee/clock.js是same-site請求
www.google-analytics.com/r/collect?v=1&_v=j81&a=38982783&t=pageview&_s=1是cross-site請求
Q2. 聊cookie為什么要提到Sec-Fetch-Site標頭?
答：B站頁面在請求A站資源時能否攜帶A站cookie（第三方cookie）不僅是一個道德問題；技術上還牽涉web安全(CSRF)。
針對以上的請求類型，瀏覽器針對cookie有SameSite屬性，提供針對跨站點請求偽造攻擊（CSRF）的保護。
在服務端Set-Cookie種植cookie時，SmmeSite屬性值可指示瀏覽器是否可在后續的“同一站點”或“跨站點”請求中攜帶這些cookie
Set-Cookie: X-BAT-TicketId=TGT-969171-******; path=/; samesite=none; httponly有如下枚舉值：
Lax ：?對同源、頂級域的請求才可以攜帶cookie （等價于same-site）
Strict: 對同源請求才可以使攜帶cookie （等價于same-origin）
None：?對于cookie的使用無限制，隨便使用
最新的IEEF cookie SameSite策略：
敦促瀏覽器版本遷移，使cookie的SameSite默認= Lax
如果需要跨域發送cookie，請使用None枚舉值選擇無SameSite限制, None指令需要搭配Secure指令
Tip：None枚舉值是標準新增枚舉值，一些舊瀏覽器不識別這個枚舉值，可能導致一些問題.
總之，IEEF配合瀏覽器給cookie的存取、使用、傳輸、規定了一套策略，環環相扣，促進了web上cookie的平衡應用。
總結本文輸出
第一方cookie vs 第三方cookie的認定：取決于訪客所處的上下文
cookie的常規用法
根據源Origin、站Site、域Domain，請求被劃分為4大類，關注HTTPSec-Fetch-Site標頭
服務器在種植cookie時，可對cookie設置SameSite屬性，故SameSite作用對象是cookie
SameSite屬性決定了后續的跨域/跨站請求是否可以攜帶B站cookie，緩解了CSRF攻擊
https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-Fetch-Site
https://web.dev/samesite-cookies-explained
推薦閱讀
●?程序員應對瀏覽器同源策略的姿勢
●?臨近年關，修復ASP.NET Core因瀏覽器內核版本引發的單點登錄故障
●?ASP.NET Core跨平臺技術內幕
●?TPL Dataflow組件應對高并發,低延遲要求
●?實例解讀Docker Swarm
●?基于docker-compose的Gitlab CI/CD實踐&排坑指南
???轉載是一種動力，分享是一種美德? ??~~..~~
如果你覺得文章還不賴，您的鼓勵是原創干貨作者的最大動力，讓我們一起激濁揚清。
總結
以上是生活随笔為你收集整理的小cookie，大智慧的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 使用BeetleX构建基础的SSL网络通
- 下一篇： 一文读懂常用开源许可证