Session Management
由於網站型態的複雜，目前的網站都需要 Session 的機制來儲存使用者的一些連線資訊，
根據你上次連結或是閱讀網頁的偏好，給你適當的資訊內容
或是在你登入之後，保持登入的狀態一陣子，除非直到登出為止
如果沒有 session 的機制，則每次使用者都必須要重新輸入使用者登入資訊。
另外，像是購物網站，在使用者登入之前，使用者可以先瀏覽許多商品，並且放入購物車
等到確定要結帳時，再要求使用者登入的動作
因此，在使用者登入之前，網站要如何辨別並且保持該連線的相關資訊呢?
這些就是 Session Management 的範疇
Session Management 機制
最常見的一種方式為 token
HTTP Server 會透過 Cookie 發送 Token 給 Browser client
例如：Set-Cookie: ASP.NET_SessionId=ba2j2312s0sad4c213s5647
而Brwoser client 也會將該 cookie 回傳
Cookie: ASP.NET_SessionId=ba2j2312s0sad4c213s5647
透過 cookie token 的方式，讓 Web Server 來判別該使用者的連線
因此，如果該 Session Management 是使用者已經登入完後的狀態
Hacker 就有可能透過截取或是讀取 Cookie 的方式進一步存取受害者於該網站的敏感性資訊，例如購買紀錄、帳戶等等
Session Management 弱點
Session 的潛在風險分為兩大類：
1. Token 值的產生很容易被計算出來或是猜到，
例如：日期+ 流水號
例如：使用者帳號 + email address
例如：IP address + 時間郵戳
2. Token 整個生命週期的管理，產生、使用、登出、過期失效、不重複使用等
這些 token 有可能被用在下列功能
- 忘記密碼 Password時 ，寄送 email 給使用者
- Hidden form fields 網頁為防止 CSRF 所加入的一個網頁 token
- one-time access
- Remember Me
- 處理線上訂單
Session 替代方案
如果單純用 cookie 來傳送 token 很危險的話，那有什麼替代方案呢?
1. HTTP authentication
2. Sessionless state mechanisms
舉例來說，ASP.NET ViewState 透過整包加密過的 object’s data 來傳送
駭客攻擊步驟
1. 駭客會照正常的瀏覽網站方式，取得該網站的 Token，每次修改該 Token 一個字元，看看 Web Server 的反應
2. 用許多不同的使用者登入，來猜測 Token 產生的邏輯
利用類似的使用者名稱，間接推論使用者名稱與 Token 是否有邏輯上的關係
3. 觀察 token 編碼的方式， Base64, XOR 等，並分析 token 出現的字元與每個字元的出現頻率，例如 Base64編碼時，最常看到的字元為 == 結尾
防護建議
- 用接近亂數的方式產生比較大的數值，會是相對安全的 token
- Token 每個生命週期的管理，一定期間後該 Token 自動失效而且不能重複被使用
- 每一個網頁都必須要有 Token
- Web Server 要不斷檢查 token 的有效性與合法性
- Session timeout 終止。多半的銀行網站，都會在固定時間內，沒有任何動作就強迫登出。或是強迫使用者重新驗證。
- Http Cookie 屬性的設定 Secure and Http Only，設定 Secure 可確保cookie 只有在 https 加密的方式傳輸。設定 HTTP 確保該 cookie 不會被 JavaScript 程式任意讀取。
