上一篇说到《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的问题可以看这个和这个帖子。
http://www.cnblogs.com/Mainz/archive/2012/11/09/2762456.html