Cookie ， Session ，Session 劫持簡單總結

cookie 機制：

Cookies 是 伺服器 在 本地機器 上存儲的 小段文本，並伴隨著 每一個請求，發送到 同一臺 伺服器。

網路伺服器 用 HTTP頭 向客戶端發送 Cookies。在客戶端，瀏覽器解析這些 cookies 並將它們保存成為一個本地文件，他會自動將同一臺伺服器的任何請求附上這些 cookies。

因為 HTTP 是一種無狀態的協議，而cookie機制採用的是在客戶端保持狀態的方案，session 是在服務端保持狀態的協議。Cookies是在用戶端的會話狀態的存貯機制，他需要用戶打開客戶端的cookie支持。

cookie的內容主要包括：名字，值，過期時間，路徑和域。路徑與域一起構成cookie的作用範圍。若不設置過期時間，則表示這個cookie的生命期為瀏覽器會話期間，關閉瀏覽器視窗，cookie就消失。這種生命期為瀏覽器會話期的cookie被稱為會話cookie。會話cookie一般不存儲在硬碟上而是保存在記憶體里，當然這種行為並不是規範規定的。若設置了過期時間，瀏覽器就會把cookie保存到硬碟上，關閉後再次打開瀏覽器，這些cookie仍然有效直到超過設定的過期時間。存儲在硬碟上的cookie可以在不同的瀏覽器進程間共用，比如兩個IE視窗。而對於保存在記憶體里的cookie，不同的瀏覽器有不同的處理方式。

　　而session機制採用的是一種在伺服器端保持狀態的解決方案。同時我們也看到，由於採用伺服器端保持狀態的方案在客戶端也需要保存一個標識，所以session機制可能需要藉助於cookie機制來達到保存標識的目的。而session提供了方便管理全局變數的方式。

　　session是針對每一個用戶的，變數的值保存在伺服器上，用一個sessionID來區分是哪個用戶session變數,這個值是通過用戶的瀏覽器在訪問的時候返回給伺服器，當客戶禁用cookie時，這個值也可能設置為由get來返回給伺服器。

　　就安全性來說：當你訪問一個使用session 的站點，同時在自己機子上建立一個cookie，建議在伺服器端的session機制更安全些，因為它不會任意讀取客戶存儲的信息。

session 機制

　　session機制是一種伺服器端的機制，伺服器使用一種類似於散列表的結構（也可能就是使用散列表）來保存信息。

　　當程式需要為某個客戶端的請求創建一個session時，伺服器首先檢查這個客戶端的請求里是否已包含了一個session標識（稱為session id），如果已包含則說明以前已經為此客戶端創建過session，伺服器就按照session id把這個session檢索出來使用（檢索不到，會新建一個），如果客戶端請求不包含session id，則為此客戶端創建一個session並且生成一個與此session相關聯的session id，session id的值應該是一個既不會重覆，又不容易被找到規律以仿造的字元串，這個session id將被在本次響應中返回給客戶端保存。

　　保存這個session id的方式可以採用cookie，這樣在交互過程中瀏覽器可以自動的按照規則把這個標識發揮給伺服器。一般這個cookie的名字都是類似於SEEESIONID。但cookie可以被人為的禁止，則必須有其他機制以便在cookie被禁止時仍然能夠把session id傳遞迴伺服器。

　　經常被使用的一種技術叫做URL重寫，就是把session id直接附加在URL路徑的後面。還有一種技術叫做表單隱藏欄位。就是伺服器會自動修改表單，添加一個隱藏欄位，以便在表單提交時能夠把session id傳遞迴伺服器。

　　Cookie與Session都能夠進行會話跟蹤，但是完成的原理不太一樣。普通狀況下二者均能夠滿足需求，但有時分不能夠運用Cookie，有時分不能夠運用Session。下麵經過比擬闡明二者的特性以及適用的場所。

　　1 .存取方式的不同

　　Cookie中只能保管ASCII字元串，假如需求存取Unicode字元或者二進位數據，需求先進行編碼。Cookie中也不能直接存取Java對象。若要存儲略微複雜的信息，運用Cookie是比擬艱難的。

　　而Session中能夠存取任何類型的數據，包括而不限於String、Integer、List、Map等。Session中也能夠直接保管Java Bean乃至任何Java類，對象等，運用起來十分便當。能夠把Session看做是一個Java容器類。

　　2 .隱私策略的不同

　　Cookie存儲在客戶端閱讀器中，對客戶端是可見的，客戶端的一些程式可能會窺探、複製以至修正Cookie中的內容。而Session存儲在伺服器上，對客戶端是透明的，不存在敏感信息泄露的風險。

　　假如選用Cookie，比較好的方法是，敏感的信息如賬號密碼等儘量不要寫到Cookie中。最好是像Google、Baidu那樣將Cookie信息加密，提交到伺服器後再進行解密，保證Cookie中的信息只要本人能讀得懂。而假如選擇Session就省事多了，反正是放在伺服器上，Session里任何隱私都能夠有效的保護。

　　3.有效期上的不同

　　使用過Google的人都曉得，假如登錄過Google，則Google的登錄信息長期有效。用戶不用每次訪問都重新登錄，Google會持久地記載該用戶的登錄信息。要到達這種效果，運用Cookie會是比較好的選擇。只需要設置Cookie的過期時間屬性為一個很大很大的數字。

　　由於Session依賴於名為JSESSIONID的Cookie，而Cookie JSESSIONID的過期時間默許為–1，只需關閉了閱讀器該Session就會失效，因而Session不能完成信息永世有效的效果。運用URL地址重寫也不能完成。而且假如設置Session的超時時間過長，伺服器累計的Session就會越多，越容易招致記憶體溢出。

　　4.伺服器壓力的不同

　　Session是保管在伺服器端的，每個用戶都會產生一個Session。假如併發訪問的用戶十分多，會產生十分多的Session，耗費大量的記憶體。因而像Google、Baidu、Sina這樣併發訪問量極高的網站，是不太可能運用Session來追蹤客戶會話的。

　　而Cookie保管在客戶端，不占用伺服器資源。假如併發閱讀的用戶十分多，Cookie是很好的選擇。關於Google、Baidu、Sina來說，Cookie或許是唯一的選擇。

　　5 .瀏覽器支持的不同

　　Cookie是需要客戶端瀏覽器支持的。假如客戶端禁用了Cookie，或者不支持Cookie，則會話跟蹤會失效。關於WAP上的應用，常規的Cookie就派不上用場了。

　　假如客戶端瀏覽器不支持Cookie，需要運用Session以及URL地址重寫。需要註意的是一切的用到Session程式的URL都要進行URL地址重寫，否則Session會話跟蹤還會失效。關於WAP應用來說，Session+URL地址重寫或許是它唯一的選擇。

　　假如客戶端支持Cookie，則Cookie既能夠設為本瀏覽器視窗以及子視窗內有效（把過期時間設為–1），也能夠設為一切閱讀器視窗內有效（把過期時間設為某個大於0的整數）。但Session只能在本閱讀器視窗以及其子視窗內有效。假如兩個瀏覽器視窗互不相干，它們將運用兩個不同的Session。（IE8下不同視窗Session相干）

　　6.跨域支持上的不同

　　Cookie支持跨功能變數名稱訪問，例如將domain屬性設置為“.biaodianfu.com”，則以“.biaodianfu.com”為尾碼的一切功能變數名稱均能夠訪問該Cookie。跨功能變數名稱Cookie如今被普遍用在網路中，例如Google、Baidu、Sina等。而Session則不會支持跨功能變數名稱訪問。Session僅在他所在的功能變數名稱內有效。

　　僅運用Cookie或者僅運用Session可能完成不了理想的效果。這時應該嘗試一下同時運用Cookie與Session。Cookie與Session的搭配運用在實踐項目中會完成很多意想不到的效果。

Session劫持

來自：ourjs 

鏈接：http://ourjs.com/detail/54f3f638232227083e00003b

Session劫持從Web Session控制機制處發動攻擊，通常是對Session令牌管理的剝奪。

因為HTTP通信使用許多不同的TCP連接，Web伺服器需要一個方法來識別每個用戶的連接。最有用的方法是當一個客戶端成功認證後，該Web伺服器向該客戶端瀏覽器發送令牌。Session令牌通常由可變長度的字元串組成，並且它可以以不同的方式存儲，如在URL中，在HTTP請求的cookie報頭中(request header)，或在HTTP請求中的其它報頭中，或者在HTTP請求的主體中。

Session劫持攻擊通過竊取或預測有效的Session令牌來獲得未經授權Web伺服器訪問許可權。

示例

例1 Session 代理人劫持

在這個例子中，我們可以看到，第一個攻擊者使用代理來捕捉一個有效的Session令牌稱為“SessionID”，然後他使用該有效Session令牌獲得未經授權的Web伺服器訪問許可權。

例2  跨站點腳本攻擊

攻擊者可以通過在客戶端上運行惡意代碼來獲取Session令牌。這個例子說明瞭如何攻擊者可以利用XSS攻擊竊取Session令牌。如果攻擊者發送惡意的JavaScript代碼到受害人訪問網站中或當受害者點擊鏈接時，JavaScript將運行攻擊者的註入腳本。如圖中所示，它可以顯示當前Sessioncookie的值;使用相同的技術則可能將此Session發送給攻擊者。

<SCRIPT>alert(document.cookie);</SCRIPT>

註* 防止Cookie被盜請參見： 提高NodeJS網站的安全性：Web伺服器防黑客攻擊技巧

Session ID的安全長度

Session ID應至少為128位長，以防止蠻力Session猜測攻擊。

在WebLogic中部署中描述到應指定至少給Session ID指定128位的長度。較短的Session ID使應用程式容易遭受蠻力Session猜測攻擊。如果攻擊者猜測到一個身份驗證的用戶Session ID，他可以接管用戶的Session。

猜測有效Session ID所需時間的預測公式：

(2^B + 1) / (2 * A * S)

其中：

• B是Session ID的位數（位元組位數）

• A是攻擊者可以每秒嘗試數

• S是有效的Session ID數量，及在任何給定時間內被猜到的數目

如果攻擊者操縱數千個僵屍電腦，他們可以嘗試每秒猜測數萬個SessionID這是合理的。如果該網站的人氣很高，訪問量很大，這種高流量的猜測可能在一段時間內被忽視。

上有效的Session ID是提供給被猜出的數量的下限是有活性的網站上，在任何給定時刻的用戶的人數。然而，放棄自己的Session，而不會記錄任何用戶將增加這個數字。 （這是有一個短期活動Session超時許多很好的理由之一。）

有64個位元組位的Session ID。對於一個大型網站，假設攻擊者可以每秒嘗試10000次的猜測，並且當前存在10000個有效的Session ID。基於這些假設，攻擊者成功地猜測到有效Session ID的時間將小於4分鐘。

現在假設一個128個位元組位的Session ID。同樣是一個訪問量非常大的網站，攻擊者可能會嘗試每秒10000次的猜測與可供猜到10000個有效的Session ID。根據這些假設，攻擊者在預期的時間內成功地猜出一個合法的Session ID將大於292年。