OWASP WEB會話管理備忘單 閱讀筆記

https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_ID_Properties

會話簡介

HTTP是一種無狀態的協議，每一對請求和響應與其餘的web交互是相互獨立的，若是要跟蹤用戶的訪問狀態，就須要引入會話機制，對用戶的訪問序列進行管理。

會話管理，將認證和訪問控制（也叫受權）鏈接起來，在認證以前可能有未認證的會話，在訪問控制以後，要有會話銷燬機制。

一旦認證的會話創建，會話ID就至關於最強的認證手段， 等同於用戶名和密碼。

泄露、捕獲、預測、和暴力破解將致使會話ID被劫持，這樣攻擊者能夠假冒用戶操做web。

 

會話ID屬性

爲了保持用戶認證狀態和跟蹤用戶操做狀態，web應用程序在提供用戶會話ID，在會話建立時候，會話ID被用戶和應用程序共享，並在會話存續期間內被每一個HTTP請求發送，會話ID是name=value的名值對。爲了實現安全會話ID的目的，會話ID的生成必須知足以下屬性。

會話ID名稱指紋

會話ID名稱不能提供極端的描述性，也不能提供非必要的詳細信息，關於此ID的目的和含義。

例如一些開發框架提供的會話ID的名稱，暴漏了技術和編程語言，例如PHPSESSID (PHP), JSESSIONID (J2EE), CFID & CFTOKEN (ColdFusion), ASP.NET_SessionId (ASP .NET)，

建議修改這些名稱爲更通用的名稱，例如ID

會話ID長度

會話ID長度必須足夠長，以阻止暴力破解攻擊，攻擊者可遍歷全部會話ID，以驗證合法ID的存在性。

建議會話ID長度至少128bit，16字節長度。

會話ID信息熵

會話ID必須不可預測，即足夠的隨機，防止猜想攻擊。攻擊者可以經過統計技術，預測和猜想合法會話ID。爲實現這個目的，僞隨機生成器必須被使用。

會話ID值必須提供64bit以上的信息熵，若是一個好的僞隨機生成數被使用， 此值被估計爲會話ID長度的一半。

會話ID值

會話ID值必須是無心義的，以防止信息泄露攻擊。攻擊者能夠解碼會話ID，提取用戶、會話和web應用內部工做的信息。

推薦使用加密hash函數，建立密碼式的會話ID，例如sha。

會話管理實現

HTTP協議中有多重實現會話狀態維持的機制，cookies，URL重寫，GET請求中參數，POST請求中隱含表單域。

cookie最流行。

框架內建的會話管理實現

建議使用業界成熟的框架，J2EE, ASP .NET, PHP，由於它們通過安全軟件的測試，和社區的修復，被證實是安全的，

可是框架過去也是存在弱點的，因此建議使用最新的版本，並修復知名的漏洞。

傳輸層安全

爲了防止會話ID交換過程當中，在網絡流量中被竊取或者泄露，有必要使用HTTPS進行會話交互，不只僅在認證過程，用戶私密信息傳遞過程。

cookie的secure屬性，應該被使用，確保cookie信息經過https鏈接傳遞。

加密通訊也能夠防止某種形式的會話固定攻擊（session fixation），這種攻擊在會話傳輸過程當中，截取並操做會話，將預約的會話ID注入到用戶的web瀏覽器。

如下最佳實踐關注保護會話ID，並幫助將https集成到web應用中：

一、web應用不該該支持https和http訪問之間的切換，由於此切換會將會話ID暴漏在網絡數據中。

二、web應用不該該在相同域名下，支持https和http對不一樣資源的訪問，由於未加密的通道會泄露會話ID.

3  web應用不該該在相同的域名下，支持公用資源訪問和私有資源訪問， 建議使用不一樣域名訪問， 公用資源訪問使用一個域名只支持 80端口， 私有資源訪問使用另外一個域名只支持443端口。

重要地強調下，https不能防止會話ID預測、暴力破解、客戶端篡改和固化。

然而，經過網絡流量抓取和泄露會話ID仍然是當前最盛行的攻擊手段。

cookies

基於cookie的會話ID交換機制提供了多重安全功能，以cookie屬性的形式，能被用於保護會話ID交換過程。

secure屬性

secure屬性指導瀏覽器，只在https鏈接中發送cookie信息。

會話保護機制是必須的對於防止中間人攻擊，須要確保攻擊者不能簡單從瀏覽器的網絡抓獲會話ID.

單純強制規定web應用只能使用https鏈接，不能根本上保護會話ID不泄露，瀏覽器可能被欺騙使用爲加密的鏈接發送請求，從而以明文方式發送會話ID.

httponly屬性

httponly屬性規定此cookie不能被腳本訪問，例如document.cookie. 此種保護是必須的，對於防止會話ID被XSS攻擊手段竊取。

domain和path屬性

domain屬性規定瀏覽器只能發送cookie到本domain和全部子domain的主機上，若是此屬性未被設置，將默認爲原始服務器。

path屬性規定瀏覽器只能發送cookie到本路徑和全部子路徑上，若是此屬性未被設置，將默認爲請求資源並設置cookie的路徑。

建議設置這兩個屬性爲窄的和嚴格約束的範圍，這種方法，domain屬性不該該設置（保證cookie屬於原始服務器），path屬性應該儘可能嚴格設置爲使用它的web應用的路徑。

expire和max-age屬性

會話管理機制，利用cookie實現，分爲兩種，一種爲持久的，另一種爲非持久型的，

若是設置了expire或者max-age屬性，則cookie在瀏覽器端被存儲到磁盤上，直到超期。

典型，對於認證以後的會話ID，通常爲非持久的，這樣有個好處，若是瀏覽器實例關閉，則會話ID丟失，會話就至關於失效了，這樣可儘可能減小黑客獲取會話ID的時間窗口。

會話ID生命週期

會話ID生成和驗證： 允許性和嚴格會話管理

有兩種類型的會話管理機制，一種允許性 一種嚴格性

允許性會話，能夠接受客戶端指定的內容做爲會話ID，嚴格性只接受web應用本身生成的會話ID

儘管現代都採用嚴格型管理，可是程序員須要保證在特性狀況下，程序中沒有允許性狀況出現，

web應用不該該接受一個它沒有產生過的會話ID,當收到這樣一個會話ID後，它須要提供一個新的本身產生的會話ID，遇到這種狀況，應用應該檢測爲 可疑活動，一個告警應該產生。

管理會話ID像任意其餘的用戶輸入

會話ID跟其餘用戶輸入同樣，須要通過後臺的校驗和驗證，因爲會話的管理機制，會話ID從客戶端的請求中獲取，get post url參數或者cookie，因此客戶端的發送須要通過校驗。

若是服務器端不校驗會話ID，就處理相應請求，攻擊者就會利用web弱點，例如若是會話ID存儲在數據庫中，他嘗試SQL注入。

更新會話ID在權限級別修改後

會話ID應該被更新或者產生，在用戶會話級別改變。

最多見的狀況是， 當用戶從未認證的狀態切換到認證狀態，會話ID必須改變，在認證過程。

其餘常見場景，包括 密碼改變， 權限改變， 用戶級別改變（從普通用戶切換爲管理員），

對於web應用的關鍵資源，當請求到達後，須要將以前的會話ID失效，併產生一個新的會話ID給客戶端，此爲關鍵資源的受權管理機制。

當使用多cookie時候的考慮

若是web應用使用cookie做爲會話ID交換機制， 而且多個cookie被設置到給定的會話中，則web應用必須驗證全部的cookie，而後容許訪問用戶會話。

很是常見現象是， 用戶未登陸時候，會話非配一個會話ID給用戶， 當用戶登錄後， 分配一個新的用戶ID給用戶， 這兩個cookie之間的關係就被肯定， 若是不校驗兩個cookie，則攻擊者頗有可能使用 未登陸的cookie訪問已經登錄受權的資源。

 

會話超期

爲了減小攻擊者攻擊時間，攻擊者發送攻擊或者劫持會話， 必須設置會話超時時間，對於每個會話。

不足夠的會話超時，增長其餘基於會話攻擊的暴漏程度， 攻擊者能夠攻擊或者劫持還生效的會話ID.

越是少的會話時間段，越是少的時間，讓攻擊者攻擊。可是對於用戶體驗，也須要考慮均衡，不能爲了安全，讓用戶常常遇到超時現象，不停登錄。

對於高風險值的會話，通常設置超時時間爲 二到五分鐘， 低風險值會話設置爲 十五到半小時。

當會話超期，應用須要主動銷燬客戶端和服務器段的會話ID，後臺的銷燬動做更加關鍵。

 

自動會話超期

idle timeout

無請求超時時間，爲自從上一次頁面訪問以後， 到這個超時時候， 須要銷燬全部超期的會話。

此機制，能夠限制攻擊者猜想到正確會話ID的可能性。

可是若是用戶劫持此會話， idle timeout則不生效， 會話能夠被攻擊者一直更新， 致使此會話一直生效。

absolute timeout

絕對超時時間，定義了會話的最大可活動時間段， 時間一到，無論用戶時候活動， 都須要將當前會話銷燬，要求用戶從新提供認證信息。

此機制，可以限制攻擊者攻擊和劫持會話的時間， 冒充用戶的時間。

renewal timeout

更新超時時間， 是在此超時時間後， 會話ID將自動更新， 在用戶會話過程當中，與會話活動和超時無關。

新的會話ID產生後， 老的會話ID非馬上失效， 等待新的ID第一次被請求後， 則新ID生效，老的ID失效。

這種場景，減小一個給定會話ID的生存時間，同時不影響用戶的會話的生存週期，

減小攻擊者劫持會話的時間。

手動會話超期機制

web應用應該提供機制， 對於安全敏感的用戶， 則能夠主動操做退出會話。

退出按鈕

web應用應該提供可見的易於訪問的退出按鈕， 在任何資源頁面上， 讓用戶可隨時退出。

 

Web內容緩存

會話超期後， 客戶端可能仍是存在服務器發送回來的資源， 須要保證這些資源的的緩存類型爲 不緩存

同時若是根據緩存策略， 有些內容須要緩存，可是請保證會話ID必定不能緩存。

推薦：

Cache-Control: no-cache="Set-Cookie, Set-Cookie2

 

額外的客戶端保護對會話管理機制

客戶端的保護機制，能夠加強安全性， 雖然前端的保護，通常爲js校驗和驗證， 極爲有限， 對於有經驗的攻擊者能夠繞過，可是對於入侵者， 能夠增長其難度。

initial login timeout

對於登錄頁面， 也須要設置超時時間， 若是超時時間達到， 則須要將登錄頁面刷新， 從新獲取新的會話ID

這樣能夠減小會話攻擊， 若是前面一個攻擊者，使用錯誤用戶名和密碼登錄失敗, 記住了會話ID，而後一個合法用戶過來登錄，其登錄使用的仍是同一個會話ID， 這樣非法用戶就會使用相同的會話ID，仿冒合法用戶執頁面操做。

 

強迫會話登出，當瀏覽器窗口關閉

使用js能夠檢測到瀏覽器窗口的關閉事件， 當事件發生， 能夠模仿用戶退出動做，主動銷燬當前會話，

讓後臺會話狀態能夠跟前臺一同銷燬。

 

關閉瀏覽器跨tab會話

用戶在一個tab中登錄， 若是用戶想在另一個新開的tab訪問， 則使用js使得訪問爲未登錄狀態。

這種方法，對cookie不適用， 由於cookie對不一樣tab是公用的。

 

自動客戶端退出

使用js代碼在全部頁面實現， 一旦會話超期， 自動跳轉到登錄頁面， 這樣後臺會話跟着前臺一併消失。

好處是， 用戶能夠認識到，前臺超時意味着後臺也超期， 是一體的，安全得很。

同時， 能夠避免用戶填寫大量表單， 而後點提交後， 數據丟失的用戶不易用問題。

 

會話攻擊檢測

會話ID猜想和暴力破解檢測

攻擊者爲了猜想和暴力破解會話ID，其必然會經過同一個IP，將發動屢次請求，使用不一樣的會話ID嘗試。

若是發現同一個IP上會話嘗試太多， 則將此IP攻擊者告警 或者 鎖定。

檢測會話ID異常

當合法會話發生操做的時候， 經過web程序內部邏輯檢測異常， 有助於防範攻擊，存在的cookie被刪除，或者修改

會話ID在另一個用戶上重用， 例如使用user-agent來輔助檢測。

記錄會話生存週期

會話的建立、銷燬， 以及執行重要的動做， 以及會話ID更新。

併發會話登錄

併發登錄是設計的策略， 若是不支持，須要採起有效的動做，當新的會話校驗後， 或者隱式銷燬掉前一個會話，或者詢問用戶是否要銷燬。

若是支持， 建議提供用戶隨時均可以使用的， 多用戶併發訪問的校驗、檢測和告警功能。

支持用戶手動遠程結束會話， 跟蹤帳戶活動歷史，記錄多個客戶端的 IP USER-AGENT 時間、耗時

 

會話管理WAF

當web應用的代碼不能修改， 則引入web application firewall