最近在用thinkjs寫自己的博客，發現總是掉到cookie的坑，于是就好好八一八這個小甜餅，沒想到居然還說很有意思的，每一個知識點都能拉出一條大魚，想想自己之前對cookie，簡直就是它認識我，我只能叫出他的名字。

我將基于我自己的理解，使用原生koa2 + mysql來簡單演示一下一些cookie的處理方案，有什么出岔子的地方，希望大家友好指正

1、cookie介紹

1.1 項目中cookie的使用場景

在實際的應用場景中，Cookie被用來做得最多的一件事是保持身份認證的服務端狀態。比如登錄狀態的判斷

1.2 為什么需要cookie呢？

敲黑板，HTTP是無狀態協議，他不對之前發生過的請求和響應的狀態進行管理。也就是每次服務器接收到請求后，并不知道請求到底用戶是誰， 是否是登錄態，這樣服務端就懵逼了。cookie可以解決這個問題。如圖，cookie的實現過程如下(盜了個圖)：

• 客戶端向服務器發送HTTP Resuest
• 服務器接收到請求，在返回的HTTP Response響應頭中加入set-cookie字段以及對應的cookie值
• 客戶端接收到服務器的響應，解析出頭部的set-cookie字段并將其中的cookie保存到本地
• 下次向服務器發送請求時， 會將cookie附加在HTTP請求的頭字段Cookie中
• 服務器收到請求，判斷cookie，便知道了發送請求的是客戶端是誰了

我是一個jser，通過原生nodejs和瀏覽器調試工具看到每一個服務器和瀏覽器交互的細節。代碼如下，歡迎交流并star：

https://github.com/LaputaGit/...

有興趣的可以了解一下，運行一下代碼，代碼里面有詳細的注釋。

2、那么問題來了，你的cookie安全嗎

首先，檢測你的項目使用cookie有沒有以下情況

能不能用js操作客戶端cookie？

對于Cookie的域（Domain）和路徑（Path）設置是如何制定策略的？為何這樣劃分？

在有SSL的應用中，你的Cookie是否可以在HTTP請求和HTTPS請求中通用？這一條暫時放放不介紹

我個人對于cookie的安全是這么理解的，我覺得cookie不是為安全而生的，所以沒必要承擔安全的責任，很多人拿cookie來做登錄驗證，包括我自己以前也這么搞過，而且搞得很簡單。。。囧

來說一下cookie的安全性話題吧，談到"為了cookie更安全"，大概會做以下工作

• 設置httpOnly為true，來保證客戶端無法操作cookie
• 設置secure為true
• cookie在服務器以各種方式加密后，生成token

比如，用戶發起登錄 -> 服務器根據客戶端的username, ip, expiration, useragent等組合信息，用可加密函數加密生成token，將此token保存到數據庫，并將token寫入cookie。

服務端驗證流程: 客戶端發來請求 -> 服務器解析出cookie中的token信息 -> 將token解密，驗證客戶端的username是否存在，如果存在 -> 驗證token是否和數據庫中的token相同，如果相同 -> 驗證token的有效期expiration，如果有效 -> 驗證ip是否變化，如果有效 -> 驗證user agent等 …我們可以把很多的選項加入到cookie的加密中。

或者，有一些方案是把敏感信息交有后端session來保存，但是數據仍然放在cookie中，通過http傳輸

問題來了，不管你是通過cookie加密，或者是通過session包裝敏感信息，這解決的是Cookie是可以被篡改的問題！這是個內部問題，可以發送HTTP請求的不只是瀏覽器，很多HTTP客戶端軟件，比如postman, paw等等，都可以發送任意的HTTP請求，可以設置任何頭字段。 假如我們直接設置Cookie字段為authed=true并發送該HTTP請求， 服務器豈不是被欺騙了？這種攻擊非常容易，Cookie是可以被篡改的！

但是，這樣是不能保證數據的安全性的，基于HTTP的cookie的傳輸是明文的，可以通過抓包獲取數據，這個是傳輸層所決定的。這個才是cookie不安全的決定因素，不管你cookie如何加密，一旦我劫持到你的cookie，再把這個cookie原封不動地發送到服務器，退一步來說，即使加密，有時也可以通過一些手段破解，只要符合服務器cookie驗證的規則，那么這個cookie是"合法的"，自然就不安全了。

未完待續。。。后續會補上相關代碼示例

總結

以上是生活随笔為你收集整理的来聊一聊Cookie(小甜饼)，及其涉及到的web安全吧的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。