來聊一聊Cookie(小甜餅)，及其涉及到的web安全吧

最近在用thinkjs寫本身的博客，發現老是掉到cookie的坑，因而就好好八一八這個小甜餅，沒想到竟然還說頗有意思的，每個知識點都能拉出一條大魚，想一想本身以前對cookie，簡直就是它認識我，我只能叫出他的名字。

我將基於我本身的理解，使用原生koa2 + mysql來簡單演示一下一些cookie的處理方案，有什麼出岔子的地方，但願你們友好指正

一、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/...

有興趣的能夠了解一下，運行一下代碼，代碼裏面有詳細的註釋。

二、那麼問題來了，你的cookie安全嗎

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

1. 能不能用js操做客戶端cookie？
2. 對於Cookie的域（Domain）和路徑（Path）設置是如何制定策略的？爲什麼這樣劃分？
3. 在有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是"合法的"，天然就不安全了。

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