session劫持技術

目錄：

0×00 應用程序認證設計背景
0×01 常規攻擊思路及缺陷
0×02 利用應用程序設計缺陷進行Session劫持的攻擊原理
0×03 Session劫持的大體思路及意義
0×04 如何防護這種攻擊

 

0×00 應用程序認證設計背景

一個應用程序在設計的過程當中，爲了實現對資源和請求進行管理，用戶信息認證是很是重要的一環。因爲HTTP請求的無鏈接性，通常的應用程序都是經過Cookie或者Session來完成認證工做，經過將加密的用戶認證信息存儲到Cookie中，或者經過賦予客戶端的一個Token，一般也就是所說的SessionId來在服務器端直接完成認證和取得用戶的身份信息，無論哪種方式，實際上在HTTP協議裏都是經過Cookie來實現的，不一樣的是Cookie可能能夠比較長期地存儲在客戶端上，而Session每每在會話結束以後服務器監視會話不處於活動狀態而予以銷燬。

0×01 常規攻擊思路及缺陷

咱們研究的web安全，每每不少時候其實就是在攻擊認證，包括很是流行的客戶端攻擊XSS，傳統的方法是咱們能夠截取Cookie來僞形成別人的身份來得到認證。各類應用程序爲了實現本身獨特的功能應用，在認證機制設計的時候並不一致，譬若有的徹底將認證信息（用戶密碼信息）加密存儲到客戶端裏，只要用戶密碼信息不修改，就能夠一直利用這個認證信息來登陸應用程序。也有的是將認證經過後應用程序賦予客戶端一個Token，這個Token存儲在Cookie裏，這樣當客戶端登陸的時候就能夠經過這個Token得到對應的身份，這樣只要這個Cookie不被刪除，就能夠永遠的處於登陸狀態。而另外的一些應用程序將Token放置到Session裏，當客戶端退出應用程序以後或者客戶端在一段時間無響應以後，服務器就銷燬這個Session，並且由於是Session裏，因此客戶端瀏覽器關閉以後，這個Session也從瀏覽器內存裏銷燬了。

咱們經常使用的跨站腳本攻擊很是經常使用的一個攻擊手法就是去攻擊應用程序的認證，而因爲服務器實現認證的時候存在的一些漏洞和機制的一些區別，攻擊成果也每每顯得不一樣。對於應用程序來說，爲了保證絕對的安全，服務器應該將Cookie和客戶端綁定，譬如將客戶端的加密IP也存儲到Cookie裏，若是發現Ip發生變化就能夠認爲是Cookie發生了泄漏，應該取消這個Cookie，可是這樣一來，用戶體驗就很是很差，因此通常的應用程序都沒有對Cookie作太多的策略，這就爲咱們的客戶端身份竊取提供了可乘之機。因此問題就集中到認證機制的處理上，對於第一種狀況，大多數的中小型應用程序的前臺都是使用的這種認證方式，只要得到了Cookie就能夠永久得到別人的身份。而第二種狀況也比較常見，譬如Google就是使用的這種機制，只要竊取了Cookie，別人只關閉應用程序也不退出應用程序的時候就能夠得到別人的身份（以前別人退出均可以得到別人的身份，後來他們作了改進）。剩下比較麻煩的就是第三種狀況最使人頭疼，由於是Session認證，因此別人退出或者關閉瀏覽器而與服務器的溝通結束以後，Session在必定時間內也被銷燬。可是咱們發現一些程序在設計的時候存在問題，可能致使咱們利用Session的機制在服務器上永久的產生一個後門（在某些設計不嚴的程序裏，可能修改密碼也不能消除掉這種後門），我這裏把它稱爲一種真正意義上的Session劫持。

0×02 利用應用程序設計缺陷進行Session劫持的攻擊原理

通常的Session劫持都是得到身份以後指望對方不要點擊退出，並且若是在這段時間裏沒有及時利用Session，Session也會由於本身的機制而進行自我銷燬，這樣獲取到的Session就失去了效果，這裏比較典型的應用有不少，譬如163郵箱，譬如baidu的認證機制。咱們能夠常常遇到這樣的狀況，我在一個瀏覽器裏開了webmail而後新打開一個瀏覽器開了webmail，而後我第一個瀏覽器退出了並不影響第二個的帳戶，二者互不影響，實際上是由於他們獲取到了兩個SessionId，這在應用程序裏多是做爲用戶體驗考慮的，可是正是這種機制存在巨大的安全漏洞。
Session信息是以一個SessionId或者表現爲臨時Cookie的Token的形式發送的，而咱們在實現了XSS的時候實際上是能夠操做Cookie的了，能夠想象，若是咱們賦給瀏覽器一個和Session Cookie名字相同而值不一樣的Cookie會怎麼樣？經過咱們的測試發現，實際上兩個Cookie都是被髮送出去的，在HTTP頭裏表現爲出現兩個同樣的COOKIE，那麼服務器會選擇哪一個Cookie做爲實際取得的COOKIE變量呢？咱們測試的時候發現其實是以第一個出現的COOKIE爲準的，而無論發送過來的是Session Cookie仍是Store Cookie，因此咱們就能夠利用Javascript改變客戶端的Session Token了。

0×03 Session劫持的大體思路及意義

這樣咱們的思路就很清晰，咱們要實現的是Session劫持，而不是傳統的Session竊取，咱們經過覆蓋這個Session Token爲一個無效值，服務器會認爲用戶身份爲未登陸，而後會要求用戶再次登錄，在這個時候咱們能夠竊取到有效的Session Token值。用戶再次登錄以後，他得到新的Session Token，而因爲應用程序的機制，以前的Session Token並無失效，這樣服務器上就存在兩個有效的Session Token了。咱們經過研究應用程序的Session超時機制和心跳包機制，就能夠長久地使這個Session有效。而接下來假設用戶很注意安全，他有退出應用程序的使用習慣，他銷燬了他的Session Token，可是仍然有一個Session Token被咱們掌握。這種方法的狠毒在於，即便用戶意識到Session Token被竊取，若是某些應用程序的設計有問題，即便用戶修改密碼，他也不能控制服務器註銷掉被咱們掌握的會話，他的Session永遠被咱們掌握了，他也永遠不知道這個Session Token是多少。

0×04 如何防護這種攻擊

咱們能夠看到，這種攻擊是因爲應用程序在設計的時候考慮不周形成的，咱們能夠在設計認證的時候就強行要求客戶端必須惟一，而且認證信息在多少天以後就過時的機制，可是很明顯這樣會和將COOKIE和ip綁定同樣，可能帶來很差的用戶體驗，如何在設計的時候意識到這個問題而且權衡應用和安全的平衡點纔是web應用程序設計者要考慮的難題。