Tomcat的SessionID引起的Session Fixation和Session Hijacking問題

上一篇說到《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的問題可以看這個和這個文章。