一片Cookie走天下

阿新 • • 發佈：2020-09-21

概念

Cookie是服務端傳送到使用者瀏覽器並且儲存到本地的一小塊資料，它會在瀏覽器下次向同一伺服器發起請求時，被攜帶到伺服器上。

為什麼有cookie

因為HTTP協議是無狀態的(HTTP協議是無狀態的協議。一旦資料交換完畢，客戶端與伺服器端的連線就會關閉，再次交換資料需要建立新的連線。這就意味著伺服器無法從連線上跟蹤會話。)，即伺服器不知道使用者上一次做了什麼，這嚴重阻礙了互動式Web應用程式的實現。在典型的網上購物場景中，使用者瀏覽了幾個頁面，買了一盒餅乾和兩瓶飲料。最後結帳時，由於HTTP的無狀態性，不通過額外的手段，伺服器並不知道使用者到底買了什麼。所以Cookie就是用來繞開HTTP的無狀態性的“額外手段”之一。伺服器可以設定或讀取Cookies中包含資訊，藉此維護使用者跟伺服器會話中的狀態。在剛才的購物場景中，當用戶選購了第一項商品，伺服器在向用戶傳送網頁的同時，還發送了一段Cookie，記錄著那項商品的資訊。當用戶訪問另一個頁面，瀏覽器會把Cookie傳送給伺服器，於是伺服器知道他之前選購了什麼。使用者繼續選購飲料，伺服器就在原來那段Cookie裡追加新的商品資訊。結帳時，伺服器讀取傳送來的Cookie就行了。 Cookie另一個典型的應用是當登入一個網站時，網站往往會請求使用者輸入使用者名稱和密碼，並且使用者可以勾選“下次自動登入”。如果勾選了，那麼下次訪問同一網站時，使用者會發現沒輸入使用者名稱和密碼就已經登入了。這正是因為前一次登入時，伺服器傳送了包含登入憑據（使用者名稱加密碼的某種加密形式）的Cookie到使用者的硬碟上。第二次登入時，如果該Cookie尚未到期，瀏覽器會發送該Cookie，伺服器驗證憑據，於是不必輸入使用者名稱和密碼就讓使用者登入了。

以上內容是維基百科對Cookie的解釋,為什麼有Cookie? 說白了：因為瀏覽器與人需要一種互動，Cookie則實現了這種互動;伺服器通過向用戶傳送Cookie給予了使用者某種“許可權”,這好比是一張門票,當瀏覽器攜帶著“門票”向伺服器發起請求時,伺服器通過驗證“門票”資訊就可以賦予使用者某種“許可權”。接下來我用註冊與登陸的示例來簡單地介紹下 Cookie的具體應用場景。

基本原理

當瀏覽器向伺服器傳送請求的時候，伺服器會將少量的資料以 set-cookie 訊息頭的方式傳送給客戶端，瀏覽器一般會自動將 cookie 資料進行儲存，當客戶端再次訪問伺服器時，會將這些資料以 cookie 訊息頭的方式傳送給伺服器，服務端就可以根據 cookie 訊息頭來判別使用者的身份或進行一些特別的處理並返回響應。

生存期

從 cookie 的工作原理上可以知道 cookie 資訊主要是儲存在客戶端的狀態，而 cookie 在客戶端的生存期則主要由屬性 max-age 決定， max-age 屬性以秒為單位表示 cookie 的存活時間為 max-age 秒；當然 cookie 還有一個屬性 expires 其作用和 max-age 是一樣的這在後續會進行詳細說明。

預設情況下 cookie 只是暫時存在的，他們儲存的值只在瀏覽器會話期間存在，當用戶關閉瀏覽器視窗後這些值也會隨之銷燬（生成的 cookie 臨時儲存於瀏覽器記憶體中）
max-age 為正數: cookie 會在 max-age 秒之後被銷燬（會將狀態儲存於 cookie 檔案中並存儲於本地硬碟中）

max-age 為負數時: cookie 只在瀏覽器會話期間存在，當用戶關閉瀏覽器視窗後這些值也會隨之銷燬（生成的 cookie 臨時儲存於瀏覽器記憶體中）
max-age 為 0 時: cookie 將被立即銷燬

Cookie細節

cookie編碼

在tomcat 8 之前 cookie中不能直接儲存中文資料。需要將中文資料轉碼---一般採用URL編碼(%E3)

在tomcat 8 之後，cookie支援中文資料。特殊字元還是不支援，建議使用URL編碼儲存，URL解碼解析。

舉個例子
在伺服器中的Servlet判斷是否有一個名為lastTime的cookie

有：不是第一次訪問
1. 響應資料：歡迎回來，您上次訪問時間為:2020年7月31日11:50:20
2. 寫回Cookie：lastTime=2020年7月31日11:50:20
沒有：是第一次訪問
1. 響應資料：您好，歡迎您首次訪問
2. 寫回Cookie：lastTime=2020年7月31日11:50:20

@WebServlet("/cookieTest")
public class CookieTest extends HttpServlet {
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // 設定響應的訊息體的資料格式以及編碼
        response.setContentType("text/html;charset=utf-8");
        // 1.獲取所有Cookie
        Cookie[] cookies = request.getCookies();
        boolean flag = false;//沒有cookie為lastTime
        // 2.遍歷cookie陣列
        if(cookies != null && cookies.length > 0){
            for (Cookie cookie : cookies) {
                // 3.獲取cookie的名稱
                String name = cookie.getName();
                // 4.判斷名稱是否是：lastTime
                if("lastTime".equals(name)){
                    // 有該Cookie，不是第一次訪問
                    flag = true;//有lastTime的cookie
                    // 設定Cookie的value
                    // 獲取當前時間的字串，重新設定Cookie的值，重新發送cookie
                    Date date  = new Date();
                    SimpleDateFormat sdf = new SimpleDateFormat("yyyy年MM月dd日 HH:mm:ss");
                    String str_date = sdf.format(date);
                    System.out.println("編碼前："+str_date);
                    // URL編碼
                    str_date = URLEncoder.encode(str_date,"utf-8");
                    System.out.println("編碼後："+str_date);
                    cookie.setValue(str_date);
                    // 設定cookie的存活時間
                    cookie.setMaxAge(60 * 60 * 24 * 30);// 一個月
                    response.addCookie(cookie);
                    // 響應資料
                    // 獲取Cookie的value，時間
                    String value = cookie.getValue();
                    System.out.println("解碼前："+value);
                    // URL解碼：
                    value = URLDecoder.decode(value,"utf-8");
                    System.out.println("解碼後："+value);
                    response.getWriter().write("<h1>歡迎回來，您上次訪問時間為:"+value+"</h1>");
                    break;
                }
            }
        }
        if(cookies == null || cookies.length == 0 || flag == false){
            // 沒有，第一次訪問
            // 設定Cookie的value
            // 獲取當前時間的字串，重新設定Cookie的值，重新發送cookie
            Date date  = new Date();
            SimpleDateFormat sdf = new SimpleDateFormat("yyyy年MM月dd日 HH:mm:ss");
            String str_date = sdf.format(date);
            System.out.println("編碼前："+str_date);
            // URL編碼
            str_date = URLEncoder.encode(str_date,"utf-8");
            System.out.println("編碼後："+str_date);
            Cookie cookie = new Cookie("lastTime",str_date);
            // 設定cookie的存活時間
            cookie.setMaxAge(60 * 60 * 24 * 30);//一個月
            response.addCookie(cookie);
            response.getWriter().write("<h1>您好，歡迎您首次訪問</h1>");
        }

    }
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        this.doPost(request, response);
    }
}

cookie共享問題

瀏覽器的同源政策規定，兩個網址，只要域名相同，埠相同，就可以共享Cookie 注意，這裡不需要協議相同。

1.假設在一個tomcat伺服器中，部署了多個web專案，那麼在這些web專案中cookie能不能共享？

預設情況下cookie不能共享

setPath(String path):設定cookie的獲取範圍。預設情況下，設定當前的虛擬目錄

如果要共享，則可以將path設定為"/"

2.不同的tomcat伺服器間cookie共享問題？

setDomain(String path):如果設定一級域名相同，那麼多個伺服器之間cookie可以共享

setDomain(".baidu.com"),那麼tieba.baidu.com和news.baidu.com中cookie可以共享

舉個例子:

@WebServlet("/cookieDemo5")
public class CookieDemo5 extends HttpServlet {
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        //1.建立Cookie物件
        Cookie c1 = new Cookie("msg","你好");
        //設定path，讓當前伺服器下部署的所有專案共享Cookie資訊
        c1.setPath("/");

        //3.傳送Cookie
        response.addCookie(c1);
    }

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        this.doPost(request, response);
    }
}

cookie注意點

Cookie在客戶端，儲存不敏感的資料，可能有安全問題，需要藉助加密技術遮蔽敏感資料。並且大小不能超過4k,很多瀏覽器都限制一個站點最多儲存20個cookie。HTTP是一個無狀態協議，因此Cookie的最大的作用就是儲存sessionId用來唯一標識用。

Cookie儲存的是字串。

一次可以傳送多個cookie。

http協議下cookie是明文傳遞的，https協議下cookie是密文傳遞的。

子域名可以訪問根域名的cookie，反之則不可以。

不同瀏覽器的 Cookie 不共享。

瀏覽器得到 Cookie 之後，每次請求都要帶上 Cookie，無形中增加了流量。

Windows 的 Cookie 儲存在C盤的一個資料夾中。

Cookie屬性

name

cookie的名字，Cookie一旦建立，名稱便不可更改。可以是除了控制字元 (CTLs)、空格 (spaces) 或製表符 (tab)之外的任何 US-ASCII 字元。同時不能包含以下分隔字元： ( ) < > @ , ; : \ " / [ ] ? = { }。

value

cookie值是可選的，如果存在的話，那麼需要包含在雙引號裡面。支援除了控制字元（CTLs）、空格（whitespace）、雙引號（double quotes）、逗號（comma）、分號（semicolon）以及反斜線（backslash）之外的任意 US-ASCII 字元。

domain 和 path 屬性

domain 指定了該 cookie 所屬的域名，預設情況下，domain 會被設定為建立該 cookie 時所在的域名；而 path 則指定了該 cookie 所屬的路徑； domain 和 path 兩者一起來限制了該 cookie 允許被哪些 URL 訪問，當我們請求某個資源（URL）時只有當該 URL 域名能夠同時被 domain 和 path 屬性匹配時，瀏覽器才會將此 cookie 新增到該請求的 cookie 頭部中。

domain 的匹配是根據請求 URL 中的域名從後向前進行匹配， path 的匹配則是根據 URL 中的路徑按照路徑的匹配規則判斷 URL 中的路徑是否包含 path, 例如：

domain 屬性	path 屬性	請求 URL	請求是否包含 cookie	描述
auth.com	/	b.auth.com/a/d	是	-
b.auth.com	/a	b.auth.com/a/b	是	-
b.auth.com	/b	b.auth.com/a/b	否	path 屬性不匹配，路徑 /a/b 不包含 /b
b.auth.com	/c	b.auth.com/a/b	否	path 屬性不匹配，路徑 /a/b 不包含 /c
a.auth.com	/	b.auth.com/a/b	否	domain 不匹配

expires/max-age

首先需要知道清楚 expires 是 http/1.0 協議中的屬性，在新的 http/1.1 協議之後 expires 已經由 max-age 選項代替，兩者的作用都是限制 cookie 的有效時間。

expires 屬性指定一個具體的到期時間，到了指定時間以後，瀏覽器就不再保留這個 cookie 。它的值是 UTC 格式，可以使用 Date.prototype.toUTCString() 進行格式轉換。而 max-age 屬性則是指定從現在開始 cookie 存在的秒數，比如 60 * 60 * 24 * 365 （即一年）。過了這個時間以後，瀏覽器就不再保留這個 cookie 。如果同時指定了 expires 和 max-age，那麼 max-age 的值將優先生效。如果沒有指定 expires 或 max-age 屬性，那麼這個 cookie 就是 Session Cookie，即它只在本次對話存在，一旦使用者關閉瀏覽器視窗，瀏覽器將不會再保留這個 cookie 。如果同時指定了Expires和Max-Age，那麼Max-Age的值將優先生效。

secure

該屬性只是一個標記而沒有值。包含 secure 選項的 cookie 只有在當請求是 HTTPS 或者其他安全協議時，才能被髮送至伺服器。預設情況下， cookie 不會帶 secure 選項(即為空)。所以預設情況下，不管是 HTTPS 協議還是 HTTP 協議的請求，cookie 都會被髮送至服務端。但要注意一點，secure 選項只是限定了在安全情況下才可以傳輸給服務端，但並不代表你不能看到這個 cookie。同時需要注意的是，如果想在客戶端即網頁中通過 js 去設定 secure 型別的 cookie，必須保證網頁是 https 協議的。在http協議的網頁中是無法設定 secure 型別 cookie 的。

httpOnly

httpOnly 背後的意思是告之瀏覽器該 cookie 絕不能通過 JavaScript 的 document.cookie 屬性訪問。設計該特徵意在提供一個安全措施來幫助阻止通過 JavaScript 發起的跨站指令碼攻擊 (XSS) 竊取 cookie 的行為, 一旦設定這個標記，通過 documen.coookie 則不能再訪問該 cookie。

sameSite

sameSite-cookies 是一種機制，用於定義 cookie 如何跨域傳送，其目的主要是為了嘗試阻止 CSRF （Cross-site request forgery 跨站請求偽造）以及 XSSI （Cross Site Script Inclusion (XSSI) 跨站指令碼包含）攻擊。

CSRF攻擊簡述: CSRF 攻擊主要是盜用使用者資訊併發送惡意請求的一種攻擊方式，比如說某使用者登入一個完全網站 A， A 站點返回一個能夠標識使用者身份的 cookie，當用戶無意中訪問一個惡意網站 B, B 站點向 A 站點發起惡意請求，這時請求中將會帶上具有使用者身份標識的 cookie。

XSSI攻擊簡述: XSSI 是 XSS 的一種形式，假設網站 A 有一個指令碼用於讀取使用者的私人賬戶資訊，攻擊者可以在自己的惡意網站包含這個指令碼，當網站 A 的使用者訪問攻擊者的網站時該網站將載入該指令碼並帶上使用者身份標識（cookie）該指令碼將讀取使用者的私人賬戶資訊，這時使用者的資訊可能就會發生洩露。

sameSite 屬性可能值： 為 cookie 設定 sameSite 屬性時需要給其定義一個值（如果沒有設定值，預設是Strict），值可以是 Lax 或者 Strict

strict： 當 sameSite 屬性值為 strict 時，將禁止傳送所有第三方連結的 cookies，比如有 cookie ( domain = a.com, sameSite = strict ), 那麼在其他網站請求 a.com 時都不會帶上該 cookie

lax： 當 sameSite 屬性值為 lax 時，只會在使用危險 HTTP 方法傳送跨域 cookie 的時候進行阻止，例如 POST 方式。比如有 cookie ( domain = a.com, sameSite = lax ), 那麼在其他網站通過 POST 方式請求 a.com 時都不會帶上該 cookie。

前端通過 document.cookie 設定 cookie，設定多個 cookie 則需要編寫多條 document.cookie = '...'，如果需要對 cookie 進行修改建立一條相同名稱的 cookie 即可對 cookie 進行替換。

// 建立多條 cookie 並設定 path 和 domain 以及 max-age 屬性
   document.cookie = 'name1=value1;path=/;domain=127.0.0.1;max-age=30';
   document.cookie = 'name2=value2;path=/;domain=127.0.0.1;max-age=30';
   document.cookie = 'name3=value3;path=/;domain=127.0.0.1;max-age=30';

   /**
     * 通用方法： 設定&emsp;cookie 方法
     * @param {String} name     cookie 名稱
     * @param {String} value    cookie 值
     * @param {Number} maxAge   cookie 存活時間（maxAge秒， 預設儲存 30 天）
   */
function setCookie({
     name,
     value,
     maxAge
}) {
     maxAge = maxAge || 30 * 24 * 60 * 60 * 1000;
     // escape： 對字串進行編碼
     document.cookie = `${name}=${escape (value)};max-age=${maxAge}`;
}

前端可直接通過 document.cookie 獲取 cookie。

// 列印 cookie
console.log(document.cookie); // name1=value1; name2=value2; name3=value3

/**
 * 通用方法： 將 cookie 轉為物件 {anme: value}
 * @return {Object} {name, value}
 */
function getCookieObj() {
  let cookieArr = document.cookie.split(";");
  let obj = {};
  cookieArr.forEach( v => {
    let arr = v.split("=");
    obj[arr[0]] =  unescape(arr[1]);
  });
  return obj
}

前端並沒有直接的 api 可以直接實現對 cookie 的刪除，可以通過將 cookie 的 max-age 屬性設定 0 來實現對 cookie 的刪除。

// 刪除 cookie
document.cookie = 'name3=value3;max-age=0';

/**
 * 通用方法： 刪除 cookie 方法
 * @param {String} name     cookie 名稱
 */
function delCookie({ name }) {
  document.cookie = `${name}=;max-age=0`;
}

@WebServlet("/cookieDemo3")
public class CookieDemo3 extends HttpServlet {
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        //1.建立Cookie物件
        Cookie c1 = new Cookie("msg","hello");
        Cookie c2 = new Cookie("name","zhangsan");
        //2.傳送Cookie
        response.addCookie(c1);
        response.addCookie(c2);
    }

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        this.doPost(request, response);
    }
}

刪除cookie

@WebServlet("/cookieDemo4")
public class CookieDemo4 extends HttpServlet {
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        //1.建立Cookie物件
        Cookie c1 = new Cookie("msg","setMaxAge");
        //2.設定cookie的存活時間
        //c1.setMaxAge(30);//將cookie持久化到硬碟，30秒後會自動刪除cookie檔案
        //c1.setMaxAge(-1);
        //c1.setMaxAge(300);
        c1.setMaxAge(0);//刪除Cookie
        //3.傳送Cookie
        response.addCookie(c1);
    }

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        this.doPost(request, response);
    }
}

1、CSRF是什麼

CSRF，中文名叫跨站請求偽造，發生的場景就是，使用者登陸了a網站，然後跳轉到b網站，b網站直接傳送一個a網站的請求，進行一些危險操作，就發生了CSRF攻擊！

這時候，懂得這個CSRF了嗎？我認為一部分同學依然不懂，因為我看過太多這樣的描述了！

因為有這麼一些疑惑，為什麼在b網站可以仿造a網站的請求？Cookie不是跨域的嗎？什麼條件下，什麼場景下，會發生這樣的事情？

這時候，我們要注意上面我對cookie的定義，在傳送一個http請求的時候，攜帶的cookie是這個http請求域的地址的cookie。也就是我在b網站，傳送a網站的一個請求，攜帶的是a網站域名下的cookie！很多同學的誤解，就是覺得cookie是跨域的，b網站傳送任何一個請求，我只能攜帶b網站域名下的cookie。

當然，我們在b網站下，讀取cookie的時候，只能讀取b網站域名下的cookie，這是cookie的跨域限制。所以要記住，不要把http請求攜帶的cookie，和當前域名的訪問許可權的cookie混淆在一起。

還要理解一個點：CSRF攻擊，僅僅是利用了http攜帶cookie的特性進行攻擊的，但是攻擊站點還是無法得到被攻擊站點的cookie。這個和XSS不同，XSS是直接通過拿到Cookie等資訊進行攻擊的。

2、Cookie相關特性

在CSRF攻擊中，就Cookie相關的特性：

1、http請求，會自動攜帶Cookie。

2、攜帶的cookie，還是http請求所在域名的cookie。

3、Cookie如何應對的 CSRF攻擊？

明白了CSRF的本質，就能理解如何防禦CSRF的攻擊。

方案一：放棄Cookie、使用Token！

由於CSRF是通過Cookie偽造請求的方式，欺騙伺服器，來達到自己的目的。那麼我們採取的策略就是，不使用Cookie的方式來驗證使用者身份，我們使用Token！

Token的策略，一般就是登陸的時候，服務端在response中，返回一個token欄位，然後以後所有的通訊，前端就把這個token新增到http請求的頭部。

這是當前，最常用的防禦CSRF攻擊的策略。

方案二：SameSite Cookies

前端在發展，Cookie也在進化，Cookie有一個新的屬性——SateSite。能夠解決CSRF攻擊的問題。

它表示，只能當前域名的網站發出的http請求，攜帶這個Cookie。

當然，由於這是新的cookie屬性，在相容性上肯定會有問題。

方案三：服務端Referer驗證

我們傳送的http請求中，header中會帶有Referer欄位，這個欄位代表的是當前域的域名，服務端可以通過這個欄位來判斷，是不是“真正”的使用者請求。

也就是說，如果b網站偽造a網站的請求，Referer欄位還是表明，這個請求是b網站的。也就能辨認這個請求的真偽了。

不過，目前這種方案，使用的人比較少。可能存在的問題就是，如果連Referer欄位都能偽造，怎麼辦？

1、XSS是什麼

XSS是由於不安全的資料引起的，有可能是表單提交的資料，有可能是頁面路徑的引數問題。

CSRF是通過偽造http請求，來達到自己的攻擊目的。但是XSS是通過盜取使用者的敏感資訊而達到攻擊的目的。比如本地儲存、使用者密碼、cookie等等。

比如這個不安全的資料，是一個script標籤，那這個script就可以連結任意的js檔案，瀏覽器本地就會執行這個js，那通過js我們能做的東西就太多了：

比如document.cookie，獲取使用者資訊。

比如通過localStorage，獲取本地儲存的敏感資訊（token）。

然後只要是這個頁面展示的任何資訊，我都可以獲取。

方案一：http-only

Cookie有一個http-only屬性，表示只能被http請求攜帶。

假如你的網站遭受到XSS攻擊，攻擊者就無法通過document.cookie得到你的cookie資訊。

方案二：正則校驗

我們瞭解到，XSS是由於不安全的資料引起的，這些資料的來源，一個重要的渠道就是提交表單，注入到資料庫。所以針對前端，我們需要把表單資料進行正則驗證，通過驗證之後，才能提交資料。

對於服務端，也應該對接受的資料，進行規則校驗，不符合規則的資料不應該入庫。從介面層面，保證資料安全。

方案三：資料轉義

如果無法保證資料庫的資料都是安全的，前端能做的事情就是，把所有需要展示到頁面的資料，進行轉義，比如遇到script標籤，直接replace處理。或者遇到標籤標識‘<’以及‘>’這類特殊字元，新增‘\’進行處理。

Token 的意思是“令牌”，是服務端生成的一串字串，作為客戶端進行請求的一個標識。Token 機制和 Cookie 和 Session 的使用機制比較類似。

1、cookie可以引起csrf攻擊，token在保持使用者會話的時候好一點。

2、由於http請求攜帶cookie，當cookie過大的時候，會增大http請求的頻寬。

3、cookie的特性，導致了cookie面對CSRF攻擊的時候，很不安全。

Cookie優化

從安全方面，儘量的使用token，進行會話保持。

從http請求的角度，儘可能讓cookie的資訊少一點，從而使得http請求的體積更小。

由於cookie的一個常用的作用，是保持使用者會話的，所以僅僅在介面請求的時候，使用cookie。

載入其他資源，比如圖片、js、css檔案等等，可以託管到CDN上，這樣就不會攜帶cookie，CDN的策略也使得資源載入更快。

Cookie的分類

會話級別Cookie：

所謂會話級別Cookie，就是在瀏覽器關閉之後Cookie就會失效。

持久級別Cookie：

儲存在硬碟的Cookie，只要設定了過期時間就是硬碟級別Cookie。

好的，現在cookie儲存在了客戶端，當我們去請求一個URL時，瀏覽器會根據這個URL路徑將符合條件的Cookie放在請求頭中傳給伺服器。

因為儲存在客戶端，容易被客戶端篡改，使用前需要驗證合法性
不要儲存敏感資料，比如使用者密碼，賬戶餘額
使用 httpOnly 在一定程度上提高安全性
儘量減少 cookie 的體積，能儲存的資料量不能超過 4kb
設定正確的 domain 和 path，減少資料傳輸
cookie 無法跨域
一個瀏覽器針對一個網站最多存 20 個Cookie，瀏覽器一般只允許存放 300 個Cookie
移動端對 cookie 的支援不是很好，而 session 需要基於 cookie 實現，所以移動端常用的是 token

參考

參考：https://juejin.im/post/6844904102544031757

連結：https://juejin.im/post/6844903662909833229

連結https://baike.baidu.com/item/cookie/1119?fr=aladdin

連結：https://juejin.im/post/6844904034181070861

一片Cookie走天下

概念 Cookie是服務端傳送到使用者瀏覽器並且儲存到本地的一小塊資料，它會在瀏覽器下次向同一伺服器發起請求時，被攜帶到伺服器上。

中國廠商開發出 Lightning 輸出口充電器，蘋果使用者也能一根線走天下

感謝網友肖戰割割的線索投遞！

Win10系統開始選單上一片空白如何解決

在win10專業版系統中，預設情況下我們開啟開始選單的話會顯示已經安裝的所有應用，但是有些使用者卻遇到開啟開始選單上出現一片空白的情況，該怎麼辦呢，現在給大家講解一下Win10系統開始選單上一片空白的具體解決步

段譽身具凌波微波，動無常則，若危若安，一次能走一級臺階或者兩級臺階，他要爬一段30級的山路，問有多少種走法？分析如何計算，然後程式設計解答。進階問題：當他輕功熟練度提升，一次最多可以走三級，那就結果有什麼變化？後來走火入魔了，不能走一級，只能走二或三級，又有什麼變化？

題目段譽身具凌波微波，動無常則，若危若安，一次能走一級臺階或者兩級臺階，他要爬一段30級的山路，問有多少種走法？分析如何計算，然後程式設計解答。

一片Cookie走天下

概念

為什麼有cookie

基本原理

生存期

Cookie細節

cookie編碼

cookie共享問題

cookie注意點

Cookie屬性

name

value

domain 和 path 屬性

expires/max-age

secure

httpOnly

sameSite

前端操作 cookie

建立 cookie

獲取 cookie

刪除 cookie

服務端操作 cookie

設定 cookie

刪除cookie

Cookie 和 CSRF 的關係

1、CSRF是什麼

2、Cookie相關特性

3、Cookie如何應對的 CSRF攻擊？

Cookie 和 XSS 的關係

1、XSS是什麼

2、Cookie 如何應對 XSS攻擊

Cookie 和 Token對比

Cookie優化

Cookie的分類

會話級別Cookie：

持久級別Cookie：

使用 cookie 時需要考慮的問題

參考

參考：https://juejin.im/post/6844904102544031757

連結：https://juejin.im/post/6844903662909833229

連結https://baike.baidu.com/item/cookie/1119?fr=aladdin

連結：https://juejin.im/post/6844904034181070861

相關推薦