一、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. 客戶端每次向服務端請求資源的時候需要帶着服務端簽發的 Token 6. 服務端收到請求，然后去驗證客戶端請求里面帶着的 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攻擊.