Tomcat的SessionID引起的Session Fixation和Session Hijacking問(wèn)題
今天說(shuō)說(shuō)SessionID帶來(lái)的漏洞攻擊問(wèn)題。首先，什么是Session Fixation攻擊和Session Hijacking攻擊問(wèn)題? 說(shuō)來(lái)話(huà)長(cháng)，非常具體的解釋查看我這個(gè)pdf文件：《Session Fixation Vulnerability in Web-based Applications》。為什么會(huì )注意到這個(gè)問(wèn)題？其實(shí)原來(lái)也知道session劫持的問(wèn)題，但沒(méi)有注意，這幾天用IBM Ration AppScan掃描了web漏洞，發(fā)現一個(gè)嚴重的Session Fixation漏洞:"會(huì )話(huà)標識未更新。針對這個(gè)問(wèn)題的解決方案: 始終生成新的會(huì )話(huà)，供用戶(hù)成功認證時(shí)登錄。防止用戶(hù)操縱會(huì )話(huà)標識。issue a new JSESSIONID cookie after login。請勿接受用戶(hù)瀏覽器登錄時(shí)所提供的會(huì )話(huà)標識。" 原來(lái)，用戶(hù)訪(fǎng)問(wèn)我們的登錄頁(yè)面，Tomcat就會(huì )生成一個(gè)SessionID，加密后放到用戶(hù)瀏覽器Cookie中。當用戶(hù)登錄后，這個(gè)SessionID并沒(méi)有改變。更加糟糕的是，每次在同一臺機器上，都使用同一個(gè)SessionID。這就造成了嚴重的Session Fixation和Session Hijacking漏洞。其實(shí)，如果Tomcat啟用了SSL，Tomcat的默認行為是：當用戶(hù)通過(guò)登錄后，生成一個(gè)新的SessionID。如果沒(méi)有配置SSL，手動(dòng)讓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沒(méi)問(wèn)題）
- 查看sessionID保存策略，確保不通過(guò)URL進(jìn)行傳遞（通過(guò)URL傳遞的SessionID禁不起安全測試）
- 每次登錄更換sessionID（已解決，事實(shí)上Tomcat在SSL下默認也是這樣）
- Session Cookie 設置HttpOnly（Tomcat沒(méi)問(wèn)題）
- Session Cookie 設置，特別是用戶(hù)IP, UserAgent...等更改強制session過(guò)期需要重新登錄（備用，防止Session保持攻擊）