Session Fixation in WebLogic and Tomcat

Session Fixation is a security vulnerability prevelant in Authentication framework available in most of the Web Servers (WebLogic Server 10.3, Tomcat 6.0.20, ASP.NET).
Session Fixation works as follows:
1) Alice (attacker) access a unprotected resource (http://vulnerableApp/unprotected.jsp). In most of the web servers a new session is created now, even if you are not logged in. A session cookie is set and sent with the response.
2) Alice notes down the session cookie sent by the web server. She can do that using some HTTP monitoring tool like LiveHttpHeader for FireFox. copy that cookie string to a different computer. Alice change the browser page to something else (www.google.com). Keep the browser window open. Leaves the computer.
3) Bob (victim) uses the computer to access a protected resource from the same web application (http://vulnerableApp/protected.jsp). He uses the same browser windows (which is kept open). He loges in using his username/password. WebServer now uses the same session cookie for logged in session. Bob continue using the application for next 30 minutes.
4) Alice access the protected resource from the application (http://vulnerableApp/protected.jsp) using the saved cookie from another machine. He can use some Java client to do so. Now she is able to access the protected resource with Bob's credentials. Alice will be able to access all protected resources until Bob logs out. If Bob leaves the computer by closing the browser (without explicit logout), then alice will be able to use the resource forever (or untill next server re-start).
This vulnerability is there if you are using most of the Web Servers (WebLogic, Tomcat not tested any other server heard ASP.NET is also having session fixation bug. )
Solution:
If you are using Form based authentication, call session.invalidate() in the login page. This will create new session cookie. See the sample login page below:

<%
session.invalidate();
%>
<form action="j_security_check" method="POST" name="login">
<input type="input" name="j_username" />
<input type="password" name="j_password" />
<input type="submit" name="submit" value="Log in" />
</form>

If you are BASIC authentication, you are at risk unless the web server handles it correctly (most web servers don't handle it). Ideally authentication framework in the web server should have called session.invalidate() before authentication.
Don't use BASIC authentication in your application.
Sample application to demonstrate the vulnerability
1) Download the SimpleWebApp1 ( http://rejeev.googlepages.com/SimpleWebApp1.war )
2) Configure a WebLogic or Tomcat server
3) Create a user called "user1" in weblogic
4) Create a user called "user1" and role called "user1" in Tomcat
5) Deploy the application in WebLogic or tomcat
6) Access test2.jsp (http://localhost:7001/SimpleWebApp1/test2.jsp)
7) Note the cookie (use LiveHttpHeaders with firefox)
8) Access test1.jsp (http://localhost:7001/SimpleWebApp1/test1.jsp). You will be asked to log in, log in.
9) Now try access the test1.jsp using the TestSessionFixation.java provide inside the war. Usage: java rejeev.sessionfixation.TestSessionFixation . You will be able to see test1.jsp without login.
Oracle has supposed to fix this issue in WebLogic Server 10.3. However I have observed that latest version of WebLogic Server (10.3) has this issue. I think they have mistaken this issue as an issue in thier admin console (admin cosole being a web application that is also vulnerable). However fundemental vulnerability is in the authentication framework.