运行着个简单的demo后，打开login.jsp，使用firebug或chrome会发现，即使没有登录，我们也会有一个JSESSIONID,这是由服务器端在会话开始是通过set-cookie来设置的匿名SessionId
可以发现，登录前和登录后的JSESSIONID并没有改变，那么这就是一个固定SessionID的漏洞（详见《黑客攻防技术宝典-web实战》第七章）
黑客登录建设银行，建设银行会给黑客返回一个sessionIDA
然后黑客引诱用户使用自己的正常的用户和密码去登录建设银行，登录之后用户的信息都放在了session之中，登录之后回话的sessionIDA没有发生变化
然后黑客使用sessionIDA操作，就可以操作用户的信息了，伪造请求，访问登录后的资源。
在用户登录使该JSESSIONID称为已登录的ID后，攻击者就可以利用这个ID伪造请求访问登录后的资源
漏洞分析处理
出现该问题的主要原因是登录控制使用的固定的SessionID，登录前与登录后的SessionID是一样的。这样就使得攻击者可以简单的伪造一个SessionID诱使用户使用该SessionID登录，即可获取登录权限。如果配合XSS漏洞，则更加可以轻易获取登录权限。避免这一漏洞的方法主要有两种：
1.在登录后重置sessionID
在登录验证成功后，通过重置session，是之前的匿名sessionId失效，这样可以避免使用伪造的sessionId进行攻击。代码如下
解决的办法如下：
1.在登录后重置sessionID
在登录验证成功后，通过重置session，是之前的匿名sessionId失效，这样可以避免使用伪造的sessionId进行攻击。代码如下
s1：黑客登录之后，首先判断当前的session是否存在，现在getsession方法参数默认是true，表示通过jsessionID查找session是否存在，如果存在session存在就使用原来的session，如果不存在就创建一个session。黑客第一次登录现在不存在session，就创建一个黑客session，在session中把黑客的用户信息存储到session中，并且新生成了一个cookerid为：sessionIDA，现在黑客就有了sessionIDA
s3：现在黑客诱导正常用户使用正常的用户名和密码去登录操作，正常用户使用用户名和密码登录的时候，携带的也是sessionIDA这个jsessionID，在后端通过过jsessionID查找session已经存在了，就把当前的用户信息就存到了黑客的黑客session中，攻击者就可以以用户的信息进行操作了
s4：然后黑客攻击者就可以利用这个sessionIDAID伪造请求访问正常用户登录后的资源
如何解决上面问题了可以通过使用用户登录后充值sessionid，或者设置httponly属性 来预防
s1：黑客登录之后，首先判断当前的session是否存在，现在参数设置成false，表示不存在session就不创建直接返回null，如果参数为true，如果当前session不存在重新创建一个session返回，如果存在session执行session.invalidate方法将原来的session销毁掉。然后在重新创建一个session，重新生成一个jsessionID
正常用户登录成功之后，利用黑客的利用sessionIDA去查找session的时候发现黑客的session已经存在了，首先把黑客的session给消除了，然后自己在创建一个新的session，让用户登录前和登录后的jessionID不一样，这样黑客就无法进行攻击了。
getSession(boolean create)意思是返回当前reqeust中的HttpSession ，如果当前reqeust中的HttpSession 为null，当create为true，就创建一个新的Session，否则返回null；
第二种解决办法
2.设置httpOnly属性
httponly是微软对cookie做的扩展,该值指定 Cookie 是否可通过客户端脚本访问, 解决用户的cookie可能被盗用的问题,减少跨站脚本攻击
主流的大多数浏览器已经支持此属性。httpOnly是cookie的扩展属性，并不包含在servlet2.x的规范里，因此一些javaee应用服务器并不支持httpOnly，针对tomcat，>6.0.19或者>5.5.28的版本才支持httpOnly属性，具体方法是在conf/context.xml添加httpOnly属性设置