Session的資訊安全設計原則、測試、個案與實作
這篇文章主要說明 Session 所帶來的資訊安全風險與安全設計相關議題。
由於 HTTP本身沒有狀態區別。因此如果要針對連線區別當下的狀態(例如：購物車、帳號密碼登入前與登入後等)，
這些狀態就會有所謂的 Session Management。最普遍 Session的做法就是使用 cookie。
Session處理不當也容易讓駭客有機會可以不需要知道帳號密碼而取得授權直接存取相關資源。
因此要如何設計一個比較安全的 Session Management 舊式這篇文章要討論的範圍。
Session Management 安全設計原則
- Session 必須要有一定期限的生命周期。(Expire 機制)
- 盡量利用原有架構 Session 管理的機制。(不要自己發明)
- 登入成功後的 Session ID 必須強制更換。
網站因為 Http 沒有 state的設計，所以為了要知道或是保存使用者的狀態通常會用下列方式建立Session
- Cookie這是最常見的方式。要注意的是 Cookie 對於 HttpOnly 與Secure的設定。
- Session ID in URL。將 session ID透過 URL 的方式傳遞。也就是 URL re-write。這種方式相對不安全。因為 URL的資訊都是明文傳遞，容易被第三者竊取。
- Hidden Token in HTMP tag。透過HTML 中的一些 Hidden Token 來傳遞 Session Token。這也是一個常見的做法。
Session 必須要有一定期限的生命周期。(Expire 機制)
CWE-613: Insufficient Session Expiration
一般網站在登入成功之後都會有 Remember Me 或是一段的時間內保持登入的狀態，
因此，駭客可能利用網路截取封包或是JavaScript Injection 等方式在公共網路(網路咖啡)，
將SessionID擷取進而獲取相關的授權。
或是利用公共電腦，透過瀏覽器直接按 Back 瀏覽歷史網頁，如果該網頁沒有適當的 session 與授權驗證機制，
駭客也會透過網頁的快取讀取歷史網頁或是透過尚未過期的 session 連線。
HTTP session hijacking
如何測試 Http Session 的有效性呢? 駭客是如何截取 Http SessionID?
其實只要用 FireFox 一個 addon “Firesheep“即可擷取網路上的 Http SessionID，FireSheep安裝：http://codebutler.github.io/firesheep/
相關的新聞個案
Facebook 案例: http://www.pcworld.com/article/209333/how_to_hijack_facebook_using_firesheep.html
Gmail 個案：
- https://productforums.google.com/forum/?hl=en#!category-topic/gmail/managing-settings-and-mail/95IVv5sz3Vo
- http://news.bbc.co.uk/2/hi/technology/6929258.stm
在Gmail 個案中，只要只用者的瀏覽器視窗是開啟的狀態，Gmail的登入session 就會永久有效。
建議session失效機制
這些資訊安全案例都是因為 SessionID 沒有設定適當的失效期限導致。那麼到底失效期限要設定多久呢?
分為兩種情況，一般來說可以設定如下：
- 30分鐘內如果都沒有任何其他的動作
- 登入後12小時，固定時間強制失效
為什麼系統要這樣設定呢? 因為大部分我們使用登入之後，極少人會點擊 “登出”，
我們會”假設”關閉瀏覽器就是”登出”，造成 SessionID處於一直沒有登出的狀態永久有效。
因此，SessionID 必須由後端伺服器設定定期失效機制。
Session ID 失效的機制通常必須跟系統管理員討論，根據這樣的架構設定在應用程式伺服器或是網站伺服器等。
Session 管理機制
為什麼說盡量用現有架構的 Session管理機制呢? 因為 session 中最重要的就是 token。
現有 Session 的機制通常比較成熟。如果自行開發因為Token 的亂數的複雜度不夠，經常會讓駭客很容易猜到 Token 邏輯關係。
舉例來說，較好的 SessionID 如下，很難從現有的 SessionID猜出下一個 SessionID的可能。
- SesisonID= 224b3666303552fd710867c8ac482a4
- SesisonID= 76a240fd7e228ee6e771a02d2c4921a
- SesisonID= ???????
不好的 SessionID機制如下，駭客很容易猜到SessionID產生的規則。因此可以透過這樣的方式取得有效的 Sessoin。
- SesisonID= 1234
- SesisonID= 1235
- SesisonID= ????
Apple實際個案 (Weak SessionID)
Apple 當時forgot password 的流程如下：
- iforgot.apple.com – enter Apple ID
- Select authentication method – “answer security questions”
- Enter date of birth
- Answer two security questions
- Enter new password
- Password is reset
這樣的流程出了什麼問題呢? 問題在於 Enter New Password 的頁面 URL 由AppleID 與生日所組成。
因此，只要知道特定用戶的 Apple ID 與生日就可以進行設定 new password 的動作。
像這樣由 AppleID 與生日組成的 Session ID的方式就會變成一個簡單的邏輯被駭客利用。
固定或是重複使用 Session ID
最後一種也是會導致資訊安全風險的部分: 固定、或是重複使用 Session ID。登入前與登入後的 Session ID 都相同。
建議的安全設計是在登入之後強制更換 Session ID。
如何測試得知呢?
如果該服務是利用 Cookie 存放 Session ID ，可以利用 FireFox 的 Tamper Data 得知 Cookie 的改變與設定的行為。
FireFox Addon Tamper Data 安裝：https://addons.mozilla.org/en-us/firefox/addon/tamper-data/reviews/
實際個案 Joomla 使用固定 SessionID
http://blog.taddong.com/2010/05/session-fixation-vulnerability-in.html
(Joomla fixed on version 1.5.16) 之前 Joomla 被發現就是 sessonID 固定。造成用 Joomla 開發的網站都會造成這樣的風險。
Session 安全設計原則
認證 Authorization 完之後系統核發一個Token保持認證成功的連線狀態，這個 Token 就是 SessionID
Session ID 的管理與安全重要性不亞於帳號密碼。因為取得認證 Session ID 相當於表示取得存取的權限。因此，安全設計上主要要注意下列幾點：
- Session 必須要有一定期限的生命周期。(Expire 機制)
- 盡量利用原有架構 Session 管理的機制。(不要自己發明)
- 登入成功後的 Session ID 必須強制更換。