資訊專欄INFORMATION COLUMN
摘要：最近在用寫自己的博客，發(fā)現(xiàn)總是掉到的坑，于是就好好八一八這個(gè)小甜餅，沒想到居然還說很有意思的，每一個(gè)知識(shí)點(diǎn)都能拉出一條大魚，想想自己之前對(duì)，簡(jiǎn)直就是它認(rèn)識(shí)我，我只能叫出他的名字。
最近在用thinkjs寫自己的博客，發(fā)現(xiàn)總是掉到cookie的坑，于是就好好八一八這個(gè)小甜餅，沒想到居然還說很有意思的，每一個(gè)知識(shí)點(diǎn)都能拉出一條大魚，想想自己之前對(duì)cookie，簡(jiǎn)直就是它認(rèn)識(shí)我，我只能叫出他的名字。
我將基于我自己的理解，使用原生koa2 + mysql來簡(jiǎn)單演示一下一些cookie的處理方案，有什么出岔子的地方，希望大家友好指正
1、cookie介紹 1.1 項(xiàng)目中cookie的使用場(chǎng)景在實(shí)際的應(yīng)用場(chǎng)景中，Cookie被用來做得最多的一件事是保持身份認(rèn)證的服務(wù)端狀態(tài)。比如登錄狀態(tài)的判斷
1.2 為什么需要cookie呢？敲黑板，HTTP是無狀態(tài)協(xié)議，他不對(duì)之前發(fā)生過的請(qǐng)求和響應(yīng)的狀態(tài)進(jìn)行管理。也就是每次服務(wù)器接收到請(qǐng)求后，并不知道請(qǐng)求到底用戶是誰， 是否是登錄態(tài)，這樣服務(wù)端就懵逼了。cookie可以解決這個(gè)問題。如圖，cookie的實(shí)現(xiàn)過程如下(盜了個(gè)圖)：
客戶端向服務(wù)器發(fā)送HTTP Resuest
服務(wù)器接收到請(qǐng)求，在返回的HTTP Response響應(yīng)頭中加入set-cookie字段以及對(duì)應(yīng)的cookie值
客戶端接收到服務(wù)器的響應(yīng)，解析出頭部的set-cookie字段并將其中的cookie保存到本地
下次向服務(wù)器發(fā)送請(qǐng)求時(shí)， 會(huì)將cookie附加在HTTP請(qǐng)求的頭字段Cookie中
服務(wù)器收到請(qǐng)求，判斷cookie，便知道了發(fā)送請(qǐng)求的是客戶端是誰了
我是一個(gè)jser，通過原生nodejs和瀏覽器調(diào)試工具看到每一個(gè)服務(wù)器和瀏覽器交互的細(xì)節(jié)。代碼如下，歡迎交流并star：
https://github.com/LaputaGit/...
有興趣的可以了解一下，運(yùn)行一下代碼，代碼里面有詳細(xì)的注釋。
2、那么問題來了，你的cookie安全嗎首先，檢測(cè)你的項(xiàng)目使用cookie有沒有以下情況
能不能用js操作客戶端cookie？
對(duì)于Cookie的域（Domain）和路徑（Path）設(shè)置是如何制定策略的？為何這樣劃分？
在有SSL的應(yīng)用中，你的Cookie是否可以在HTTP請(qǐng)求和HTTPS請(qǐng)求中通用？這一條暫時(shí)放放不介紹
我個(gè)人對(duì)于cookie的安全是這么理解的，我覺得cookie不是為安全而生的，所以沒必要承擔(dān)安全的責(zé)任，很多人拿cookie來做登錄驗(yàn)證，包括我自己以前也這么搞過，而且搞得很簡(jiǎn)單。。。囧
來說一下cookie的安全性話題吧，談到"為了cookie更安全"，大概會(huì)做以下工作
設(shè)置httpOnly為true，來保證客戶端無法操作cookie
設(shè)置secure為true
cookie在服務(wù)器以各種方式加密后，生成token
比如，用戶發(fā)起登錄 -> 服務(wù)器根據(jù)客戶端的username, ip, expiration, useragent等組合信息，用可加密函數(shù)加密生成token，將此token保存到數(shù)據(jù)庫(kù)，并將token寫入cookie。
服務(wù)端驗(yàn)證流程: 客戶端發(fā)來請(qǐng)求 -> 服務(wù)器解析出cookie中的token信息 -> 將token解密，驗(yàn)證客戶端的username是否存在，如果存在 -> 驗(yàn)證token是否和數(shù)據(jù)庫(kù)中的token相同，如果相同 -> 驗(yàn)證token的有效期expiration，如果有效 -> 驗(yàn)證ip是否變化，如果有效 -> 驗(yàn)證user agent等 …我們可以把很多的選項(xiàng)加入到cookie的加密中。
或者，有一些方案是把敏感信息交有后端session來保存，但是數(shù)據(jù)仍然放在cookie中，通過http傳輸
問題來了，不管你是通過cookie加密，或者是通過session包裝敏感信息，這解決的是Cookie是可以被篡改的問題！這是個(gè)內(nèi)部問題，可以發(fā)送HTTP請(qǐng)求的不只是瀏覽器，很多HTTP客戶端軟件，比如postman, paw等等，都可以發(fā)送任意的HTTP請(qǐng)求，可以設(shè)置任何頭字段。 假如我們直接設(shè)置Cookie字段為authed=true并發(fā)送該HTTP請(qǐng)求， 服務(wù)器豈不是被欺騙了？這種攻擊非常容易，Cookie是可以被篡改的！
但是，這樣是不能保證數(shù)據(jù)的安全性的，基于HTTP的cookie的傳輸是明文的，可以通過抓包獲取數(shù)據(jù)，這個(gè)是傳輸層所決定的。這個(gè)才是cookie不安全的決定因素，不管你cookie如何加密，一旦我劫持到你的cookie，再把這個(gè)cookie原封不動(dòng)地發(fā)送到服務(wù)器，退一步來說，即使加密，有時(shí)也可以通過一些手段破解，只要符合服務(wù)器cookie驗(yàn)證的規(guī)則，那么這個(gè)cookie是"合法的"，自然就不安全了。
未完待續(xù)。。。后續(xù)會(huì)補(bǔ)上相關(guān)代碼示例
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://specialneedsforspecialkids.com/yun/11316.html
摘要：如圖圖顧名思義，，是級(jí)別的存儲(chǔ)。如筆者寫的一篇淺析文章聊一聊百度移動(dòng)端首頁前端速度那些事兒讀者們可以嘗試使用。 歡迎大家收看聊一聊系列，這一套系列文章，可以幫助前端工程師們了解前端的方方面面（不僅僅是代碼）：https://segmentfault.com/blog/frontenddriver 在web開發(fā)越來越復(fù)雜的今天，前端擁有的能力也越來越多。其中最重要的一項(xiàng)莫過于web存儲(chǔ)。...
摘要：所以今天，就和大家一起聊一聊前端的安全那些事兒。我們就聊一聊前端工程師們需要注意的那些安全知識(shí)。殊不知，這不僅僅是違反了的標(biāo)準(zhǔn)而已，也同樣會(huì)被黑客所利用。 歡迎大家收看聊一聊系列，這一套系列文章，可以幫助前端工程師們了解前端的方方面面（不僅僅是代碼）：https://segmentfault.com/blog... 隨著互聯(lián)網(wǎng)的發(fā)達(dá)，各種WEB應(yīng)用也變得越來越復(fù)雜，滿足了用戶的各種需求...
摘要：瀏覽器主要保存服務(wù)端發(fā)送給用戶瀏覽器和頁面調(diào)用所設(shè)置的小片數(shù)據(jù)。瀏覽器在磁盤上保存并且在下一次請(qǐng)求時(shí)發(fā)送給相同的服務(wù)器。也稱為會(huì)話，包含和兩部分，客戶端通過記錄會(huì)話標(biāo)識(shí)，服務(wù)端通過會(huì)話標(biāo)識(shí)找到對(duì)應(yīng)的。黑客可以通過注入和利用中的信息。 瀏覽器 cookie 主要保存服務(wù)端發(fā)送給用戶瀏覽器和頁面調(diào)用 document.cookie=? 所設(shè)置的小片數(shù)據(jù)。瀏覽器在磁盤上保存 cookie 并...
閱讀 3738·2021-09-09 09:33
閱讀 3024·2019-08-30 15:56
閱讀 3017·2019-08-30 15:56
閱讀 3307·2019-08-30 15:55
閱讀 499·2019-08-30 15:53
閱讀 2179·2019-08-30 15:52
閱讀 662·2019-08-28 18:16
閱讀 2391·2019-08-26 13:51
