上一篇說到《Spring MVC防御CSRF、XSS和SQL注入攻擊》，今天說說SessionID帶來的漏洞攻擊問題。首先，什么是Session Fixation攻擊和Session Hijacking攻擊問題? 說來話長，非常具體的解釋查看我這個pdf文件：《Session Fixation Vulnerability in Web-based Applications》。為什么會注意到這個問題？其實原來也知道session劫持的問題，但沒有注意，這幾天用IBM Ration AppScan掃描了web漏洞，發現一個嚴重的Session Fixation漏洞:"會話標識未更新。針對這個問題的解決方案: 始終生成新的會話，供用戶成功認證時登錄。防止用戶操縱會話標識。issue a new JSESSIONID cookie after login。請勿接受用戶瀏覽器登錄時所提供的會話標識。" 原來，用戶訪問我們的登錄頁面，Tomcat就會生成一個SessionID，加密后放到用戶瀏覽器Cookie中。當用戶登錄后，這個SessionID並沒有改變。更加糟糕的是，每次在同一台機器上，都使用同一個SessionID。這就造成了嚴重的Session Fixation和Session Hijacking漏洞。其實，如果Tomcat啟用了SSL，Tomcat的默認行為是：當用戶通過登錄后，生成一個新的SessionID。如果沒有配置SSL，手動讓Tomcat生成新的SessionID的方法是：
* Authenticate, first invalidate the previous Tomcat sessionID immediately
* This step is only required when NO SSL of Tomcat is applied!
*/
if (session!= null && !session.isNew()) {
session.invalidate();
}
/*
* Create the sessionID
* Actually if deploy this web site in Tomcat by SSL, by default a new SessionID will be generated
*
* */
HttpSession session = getRequest().getSession( true);
在后台登陸邏輯中，登陸前生成新的SessionID。
另外可以采用下面的CheckList：
- 查看sessionID生成策略，確保不可被猜測（Tomcat沒問題）
- 查看sessionID保存策略，確保不通過URL進行傳遞（通過URL傳遞的SessionID禁不起安全測試）
- 每次登錄更換sessionID（已解決，事實上Tomcat在SSL下默認也是這樣）
- Session Cookie 設置HttpOnly（Tomcat沒問題）
- Session Cookie 設置，特別是用戶IP, UserAgent...等更改強制session過期需要重新登錄（備用，防止Session保持攻擊）
Session Fixation攻擊
舉一個形象的例子，假設A有一輛汽車，A把汽車賣給了B，但是A沒有把鑰匙都交給B，自己還留了一把。這時候如果B沒有換鎖的話，A還是可以打開B的車的。在網站上，具體的攻擊過程是：攻擊者X首先獲取一個未經認證的SessionID，然后把這個SessionID交給用戶Y去認證，Y完成認證后，服務器並未更新此SessionID的值（注意是未改變SessionID，而不是Session），所以X可以直接憑借此SessionID登錄進Y的賬戶。X怎么拿到SessionID的？常用的方法有Xss攻擊（如果設置HttpOnly此方法無效）、網絡Sniff、本地木馬竊取、網絡嗅探等。解決Session Fixation攻擊的辦法就是在登錄完成后，重新生成不可以猜測的SessionID。ASP.NET的解決Session Fixation和Session Hijacking的問題
ASP.NET的解決Session Fixation和Session Hijacking的問題可以看這個和這個帖子。