Python Web學習筆記之Cookie,Session,Token區別

標籤：ini   inter   視窗   one   序列   導致   dir   cookie   page   

 

一、Cookie,Session,Token簡介

# 這三者都解決了HTTP協議無狀態的問題

 　　session ID or session token is a piece of data that is used in network communications (often over HTTP) to identify a session, a series of related message exchanges. Session identifiers become necessary in cases where the communications infrastructure uses a stateless protocol such as HTTP. For example, a buyer who visits a seller‘s site wants to collect a number of articles in a virtual shopping cart and then finalize the shopping by going to the site‘s checkout page. This typically involves an ongoing communication where several webpages are requested by the client and sent back to them by the server. In such a situation, it is vital to keep track of the current state of the shopper‘s cart, and a session ID is one way to achieve that goal.

　　A session ID is typically granted to a visitor on his first visit to a site. It is different from a user ID in that sessions are typically short-lived (they expire after a preset time of inactivity which may be minutes or hours) and may become invalid after a certain goal has been met (for example, once the buyer has finalized his order, he cannot use the same session ID to add more items).

　　As session IDs are often used to identify a user that has logged into a website, they can be used by an attacker to hijack the session and obtain potential privileges. A session ID is often a long randomly-generated string to decrease the probability of obtaining a valid one by means of a brute-force search. Many servers perform additional verification of the client, in case the attacker has obtained the session ID. Locking a session ID to the client‘s IP address is a simple and effective measure as long as the attacker cannot connect to the server from the same address.

　　A session token is a unique identifier, usually in the form of a hash generated by a hash function that is generated and sent from a server to a client to identify the current interaction session. The client usually stores and sends the token as an HTTP cookie and/or sends it as a parameter in GET or POST queries. The reason to use session tokens is that the client only has to handle the identifier (a small piece of data which is otherwise meaningless and thus presents no security risk) - all session data is stored on the server (usually in a database, to which the client does not have direct access) linked to that identifier. There are many drawbacks of session id and it‘s not enough to fulfill the developer requirements.^{[vague] Many developers use other logic to identify the session}

 

1. Cookie機制

cookie機制是採用在用戶端保持狀態的方案.cookie的使用是由瀏覽器按照一定的原則在後台自動發送給伺服器的。瀏覽器檢查所有儲存的cookie，如果某個cookie所聲明的作用範圍大於等於將要請求的資源所在的位置，則把該cookie附在請求資源的HTTP要求標頭上發送給伺服器。

cookie的內容主要包括：名字、值、到期時間、路徑和域。路徑與域一起構成cookie的作用範圍。

若不設定到期時間，則表示這個cookie的生命期為瀏覽器會話期間，關閉瀏覽器視窗，cookie就消失。這種生命期為瀏覽器會話期的cookie被稱為會話cookie.會話cookie一般不儲存在硬碟上而是儲存在記憶體裡.若設定了到期時間，瀏覽器就會把cookie**儲存在硬碟**上，關閉後再次開啟瀏覽器，這些cookie仍然有效直到超過設定的到期時間。儲存在硬碟上的cookie可以在不同的瀏覽器進程間共用，比如兩個IE視窗。而對於儲存在記憶體裡cookie，不同的瀏覽器有不同的處理方式。

 

2. Session 機制

session機制是一種伺服器端的機制. 
用戶端對服務端請求時,服務端會檢查請求中是否包含一個session標識( 稱為session id ).

• 如果沒有,那麼服務端就產生一個隨機的session以及和它匹配的session id,並將session id返回給用戶端.
• 如果有,那麼伺服器就在儲存中根據session id 尋找到對應的session.

當瀏覽器禁止Cookie時,可以有兩種方法繼續傳送session id到服務端:第一種：URL重寫（常用），就是把session id直接附加在URL路徑的後面。第二種：表單隱藏欄位,將sid寫在隱藏的表單中。

 

3. Token機制

Token是使用者的驗證方式,最簡單的token組成:uid(使用者唯一的身份標識)、time(目前時間的時間戳記)、sign(簽名，由token的前幾位+鹽以雜湊演算法壓縮成一定長的十六進位字串，可以防止惡意第三方拼接token請求伺服器)。

使用基於 Token 的驗證方法，在服務端不需要儲存使用者的登入記錄。大概的流程是這樣的：1. 用戶端使用使用者名稱跟密碼請求登入2. 服務端收到請求，去驗證使用者名稱與密碼3. 驗證成功後，服務端會簽發一個 Token，再把這個 Token 發送給用戶端4. 用戶端收到 Token 以後可以把它儲存起來，比如放在 Cookie 裡或者 Local Storage 裡5. 用戶端每次向服務端請求資源的時候需要帶著服務端簽發的 Token6. 服務端收到請求，然後去驗證用戶端請求裡面帶著的 Token，如果驗證成功，就向用戶端返回請求的資料

 

二、cookie與session的區別

1、cookie資料存放在用戶端上，session資料放在伺服器上。

2、cookie不是很安全，別人可以分析存放在本地的COOKIE並進行COOKIE欺騙 
考慮到安全應當使用session。

3、session會在一定時間內儲存在伺服器上。當訪問增多，會比較佔用你伺服器的效能 
考慮到減輕伺服器效能方面，應當使用COOKIE

 

三、session與token的區別

作為身份認證 token安全性比session好，因為每個請求都有簽名還能防止監聽以及重放攻擊

Session 是一種HTTP儲存機制，目的是為無狀態的HTTP提供的持久機制。Session 認證只是簡單的把User 資訊儲存到Session 裡，因為SID 的不可預測性，暫且認為是安全的。這是一種認證手段。 但是如果有了某個User的SID,就相當於擁有該User的全部權利.SID不應該共用給其他網站或第三方.

Token,如果指的是OAuth Token 或類似的機制的話，提供的是 認證 和 授權 ，認證是針對使用者，授權是針對App。其目的是讓 某App有權利訪問 某使用者 的資訊。這裡的 Token是唯一的。不可以轉移到其它 App上，也不可以轉到其它 使用者 上。

 

四、會話管理機制中的漏洞

會話管理機制中存在的漏洞主要有兩類:1. 會話令牌產生過程中的薄弱環節2. 在整個生命週期過程中處理會話令牌的薄弱環節

 五、產生過程的薄弱環節1. 令牌有一定含義

一些會話令牌通過使用者名稱或者郵箱直接轉換而來,或者使用一些基本的資訊進行建立.這樣就很比較容易構建令牌.

常見的具有含義的令牌有以下資訊:賬戶使用者名稱應用程式用來區分賬戶的數位識別碼符使用者的姓/名電子郵件日期/時間戳記一個遞增/遞減的數字用戶端的IP地址

令牌也很有可能會經過XOR,Base64,轉化ASCII等方式先進行編碼的操作,再進而產生令牌.

 2. 令牌可預測

令牌可預測,主要是有這三個方面造成:隱含序列,時間依賴,產生的數字隨機性不強.

隱含序列:主要是指令牌是通過簡單的排列,然後進行編碼或者進行十六進位的加減法操作而得到,只要猜測出它的基本方法,就可以進行發現規律. 
時間依賴:令牌只根據時間的變換,使得令牌產生不同的偽隨機. 
隨機性不強:指令牌是通過簡單的線性同餘函數產生,如果正好該函數又是公開的,比如java的java.util.Random函數等.

 六、生命過程中的薄弱環節 1. 在網路上泄露令牌

當網站等以非機密的方式傳送會話令牌時,就很有可能會導致令牌被竊聽.比如使用非加密的HTTP的方式進行通訊.

需要注意的是,有些網站雖然部分頁面使用了HTTPS,但是還有部分頁面使用HTTP,那麼令牌就很有可能會在這些HTTP通訊的頁面中泄露.

 2. 在日誌中泄露令牌

主要原因可以是應用程式使用URL查詢字串,而不是使用HTTPCookie或者POST請求作為令牌的傳輸機制. 比如java web中,會在URL中後面帶有 http://xxx.com;jsessionid=xxx ;當這樣的URL寫進日誌或者其他記錄中,那麼sid就很容易被擷取.

當Cookie被禁止後,就很容易出現使用URL進行傳輸令牌.

 3. 會話終止易受攻擊

有些網站,在使用者退出後,它只通過set-Cookie等命令清除用戶端的令牌,而服務端的令牌沒有被刪除.也可能會出現使用者退出時,應用程式不與伺服器通訊,導致伺服器什麼操作都不做. 這些行為會導致當使用者再次提交該令牌時,還能夠與伺服器通訊.

 4. 用戶端暴露在令牌劫持的風險之中

攻擊者可能通過XSS攻擊使用者,擷取到使用者的Cookie,擷取令牌. 所以cookie中要注意設定HTTPOnly,這樣可以減緩XSS攻擊.

 

 

參考1

參考2

 

Python Web學習筆記之Cookie,Session,Token區別