CSRF、Cookie、Session和token之間不得不說得那些事兒

文章目錄

• 1. 前言
• 2. 什麼是CSRF？
• 3. 什麼是Cookie？有什麼用？機制？
• 4. 什麼是session？有什麼用？機制?
• 5. 什麼是token？有什麼用？它有什麼特點？為什麼能防止CSRF？
• 6. 總結
• 7. 參考文獻

1. 前言

web開發相關職位的面試中，經常會遇到CSRF、Cookie、Session和token。每次看了一些部落格之後，總是以為了解了，燃鵝事情并不是這樣。

強烈推薦大家先讀一讀這篇部落格，真的寫的很好。徹底了解cookie，session，token

2. 什麼是CSRF？

原文 安全|常見的Web攻擊手段之CSRF攻擊

CSRF攻擊的全稱是跨站請求僞造（ cross site request forgery)，是一種對網站的惡意利用。

簡單點講就是，惡意網站(攻擊者)盜用了你的身份，以你的名義向信任網站發送惡意請求。

CRSF能做的事情包括利用你的身份發郵件、發短信、進行交易轉賬等，甚至盜取你的賬号。圖檔來自什麼是CSRF？可能多數人都不清楚，沒事，一起來了解！！！

對上面的圖進行分析：

1. 使用者C通過浏覽器登陸并浏覽信任網站A；
2. 在使用者C的浏覽器中生成網站A的Cookie；
3. 使用者C通過浏覽器通路惡意網站B；
4. 在惡意網站B的一些HTML标簽或者js中有一些代碼，讓使用者C去通路網站A(發送使用者C對網站A的request)，進行一些惡意操作；例如：

   　銀行網站A，它以GET請求來完成銀行轉賬的操作，如：
   　http://www.mybank.com/Transfer.php?toBankId=11&money=1000危險網站B，它裡面有一段HTML的代碼如下：
   　<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
              

5. 此時，這個request請求會攜帶網站A的Cookie去請求網站A；
6. 網站A無法識别請求是否是使用者的請求，還是惡意網站盜用身份後的請求，是以會按照請求内容進行操作。

需要知道的就是，

在惡意網站的HTML或者JS代碼中會讓你去通路其它網站，你的浏覽器在通路網站的時候會自己攜帶該網站的Cookie去請求，然而網站對于使用者的認證資訊都在Cookie裡，是以才讓惡意網站有機可乘。

3. 什麼是Cookie？有什麼用？機制？

原文 深入了解Cookie

由于HTTP協定本身是無狀态的，也就是說同一個使用者前一次HTTP請求和後一次HTTP請求時互相獨立的，無法判斷後一次請求的使用者是不是剛才的使用者。為了記錄使用者的狀态，才有了Cookie。

Cookie實際上以key-value鍵值對的形式存儲了一些文本資訊資料，它将資料儲存在用戶端(浏覽器)。

當浏覽器(用戶端)登陸網站請求伺服器後，伺服器的response中傳回了Set-Cookie（與Cookie類似，也是鍵值對的一小段文本），浏覽器(用戶端)将這個Cookie儲存起來，當下次該浏覽器(用戶端)再請求此伺服器時，浏覽器(用戶端)把請求的網址連同該域的Cookie一同送出給伺服器。伺服器檢查該Cookie，以此來辨認使用者狀态。

1. 用戶端發送一個HTTP Request請求伺服器；
2. 伺服器方傳回一個HTTP Response給用戶端，其中有Set-Cookie的頭部；
3. 用戶端根據Set-Cookie将該網站的Cookie儲存下來；
4. 當再次請求該伺服器時，浏覽器用戶端會自動攜帶已經儲存的該網站的Cookie一同發送給伺服器；
5. 伺服器傳回HTTP Response；

Cookie中通常包含的資訊：

Cookie屬性	描述
Name	設定要儲存的 Key
Value	設定要儲存的 Value
Domain	生成該 Cookie 的域名，如Domain=“www.csdn.net”
Path	該 Cookie 是在目前的哪個路徑下生成的，如Path=/blog/
Expires/Max-Age	過期時間，超過該時間，則Cookie失效
Size	Cookie大小
HttpOnly	如果Cookie中設定了HttpOnly屬性，那麼通過js腳本将無法讀取到cookie資訊，這樣能有效的防止XSS攻擊，竊取Cookie内容，這樣就增加了Cookie的安全性
Secure	如果設定了這個屬性，那麼隻會在 HTTPS 連接配接時才會回傳該 Cookie
SameSite	如果連結來自外部站點，浏覽器不會将cookie 添加到已認證身份驗證的網站。

是以Cookie的作用就是儲存使用者狀态，讓伺服器能夠知道這一次請求的使用者是誰，他有哪些資訊。

需要注意的是，由于同源政策的存在，不同源的網站不能使用對方網站的Cookie，也即是不可以跨域名的，隐私安全機制禁止網站非法擷取其他網站的Cookie。

是以，在CSRF中惡意網站其實并不能擷取到信任網站的Cookie。

4. 什麼是session？有什麼用？機制?

Cookie和session是配套使用的。Cookie是将一些文本資訊以鍵值對的形式儲存在用戶端，而Session是将某些資訊儲存在伺服器端。因為HTTP協定是無狀态，Cookie是在用戶端實作狀态保持，Session是在伺服器端實作狀态保持，通過兩者的結合實作用戶端和伺服器連接配接的狀态保持。

那麼如何才能将Cookie對應到正确的Session呢？利用sessionid。

通常在資料庫中有一個seesion表，存放着所有的Session資料，大家都知道資料庫資料都有一個id，而sessionid就對應的這個id，是以通過浏覽器傳遞過來的Cookie，伺服器能找到對應id的Session實作連接配接的狀态保持。

例子來自 Session機制詳解

讓我們用幾個例子來描述一下cookie和session機制之間的差別與聯系。筆者曾經常去的一家咖啡店有喝5杯咖啡免費贈一杯咖啡的優惠，然而一次性消費5杯咖啡的機會微乎其微，這時就需要某種方式來紀錄某位顧客的消費數量。想象一下其實也無外乎下面的幾種方案：

1、該店的店員很厲害，能記住每位顧客的消費數量，隻要顧客一走進咖啡店，店員就知道該怎麼對待了。這種做法就是協定本身支援狀态。

2、發給顧客一張卡片，上面記錄着消費的數量，一般還有個有效期限。每次消費時，如果顧客出示這張卡片，則此次消費就會與以前或以後的消費相聯系起來。這種做法就是在用戶端保持狀态。

3、發給顧客一張會員卡，除了卡号之外什麼資訊也不紀錄，每次消費時，如果顧客出示該卡片，則店員在店裡的紀錄本上找到這個卡号對應的紀錄添加一些消費資訊。這種做法就是在伺服器端保持狀态。

5. 什麼是token？有什麼用？它有什麼特點？為什麼能防止CSRF？

原文 基于Token的身份驗證的原理

token其實就是一個令牌，用于使用者驗證的，token的誕生離不開CSRF。正是由于上面的Cookie/Session的狀态保持方式會出現CSRF，是以才有了token。

token的特點：

1. 無狀态、可擴充
2. 支援移動裝置
3. 跨程式調用
4. 安全

token的機制：

基于Token的身份驗證的過程如下:

1. 使用者登入校驗，校驗成功後就傳回Token給用戶端
2. 用戶端收到token後儲存在用戶端，token可以儲存在Cookies 或 Local Storage 或 Session Storage中。
3. 用戶端每次通路API是攜帶Token到伺服器端
4. 伺服器端采用filter過濾器校驗。驗證傳遞的token和算法生成的token是否一緻，校驗成功則傳回請求資料，校驗失敗則傳回錯誤碼

當我們在程式中認證了資訊并取得 token 之後，我們便能通過這個 token 做許多的事情。我們甚至能建立一個基于權限的token傳給第三方應用程式，這些第三方程式能夠擷取到我們的資料（當然隻限于該 token 被允許通路的資料）。

圖檔來自 基于Token的身份驗證的原理

一直困擾的一個問題就是，為什麼惡意網站不能利用使用者浏覽器中的token，而能利用Cookie呢？

這是因為，在信任網站的HTML或js中，會向伺服器傳遞參數token，不是通過Cookie傳遞的，若惡意網站要僞造使用者的請求，也必須僞造這個token，否則使用者身份驗證不通過。但是，同源政策限制了惡意網站不能拿到信任網站的Cookie内容，隻能使用，是以就算是token是存放在Cookie中的，惡意網站也無法提取出Cookie中的token資料進行僞造。也就無法傳遞正确的token給伺服器，進而無法成功僞裝成使用者了。

6. 總結

現在明白CSRF、Cookie、Session和token了嗎？

tom在村口tony師傅開的理發店那裡辦了一張理發夾(Cookie)，jerry從tom那裡盜取了這張理發夾之後(CSRF)，去到理發店，tony師傅在洗剪吹理發系統中(session)驗證發現是自己的理發夾，那麼jerry就能在tony師傅這兒剪發了。

後來，為了防止這種行為，tony師傅為理發夾增加了密碼(token)，就算jerry從tom那裡盜取了理發夾(CSRF)，但是jerry不知道理發夾的密碼(token)，那麼jerry去到理發店之後，tony師傅在洗剪吹理發系統中發現是本店的理發夾之後，還會要求jerry給出密碼(token)，這樣就阻止了jerry的這種行為(CSRF)。

惡意網站的js中有一些構造出來的信任網站的URL，當使用者觸發了這個js之後，這個使用者就請求了該URL了，然後就會根據這個URL進行操作，例如修改賬戶裡的錢，或者删除掉某些資料等，總之這是一種很不安全的行為。是以，在信任網站的js中額外傳遞了一個參數token（通常是根據Cookie來生成的）給後端，這個參數隻有在該信任網站的頁面中才能生成對應的token，而惡意網站通過構造信任網站的URL能夠僞造使用者的操作，但是由于

同源政策

的原因，惡意網站無法使用Cookie也就無法生成對應的token，無法逃避信任伺服器的驗證。

7. 參考文獻

[1] 安全|常見的Web攻擊手段之CSRF攻擊

[2] 徹底了解cookie，session，token

[3] 關于CSRF 和 csrftoken

[4] CSRF Token 的設計是否有其必要性？

[5] 為什麼CSRF Token寫在COOKIE裡面

[6] CSRF攻擊與防禦（寫得非常好）

[7] 什麼是CSRF？可能多數人都不清楚，沒事，一起來了解！！！

[8] 深入了解Cookie

[9] Session機制詳解

[10] token驗證機制

[11] 基于Token的身份驗證的原理