Talk:Session Fixation

Session Fixation Session Fixation is a security vulnerability prevalent 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 ( [1]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 <url> <cookie>. You will be able to see test1.jsp without login.

Session fixation is supposed to be fixed in WebLogic Server 10.3. However I have observed that it is present in latest version of WebLogic (Weblogic Server 10.3). I think they have fixed vulnerability WebLogic console only. WebLogic console being a web application it also vulnerable. However fundamental defect is in the authentication framework. That is not yet fixed. Please see the following blog entry for details [2]http://rejeev.blogspot.com/2009/09/session-fixation_08.html 

---

1. Do server side session invalidation

   I don't agree with the solution above, to invalidate the session in the JSP. It is still possible, to do the login from a fake page, e.g. from a XSSed page from the same server where the session still is valid.

   The session has to be renewed during the login request, right before the authentication. This way the response will have a "Set-Cookie" with a fresh and authenticated session. See: Sicherheit von Webanwendungen (from the German BSI, page 40).

2. Weblogic and session fixation

   In the weblogic changelog 10.3.1 I don't see the bugfix of session fixation in weglogic, as you stated in your blog. Has anyone a source? What exactly changed?

--Wimp 06:55, 30 March 2010 (UTC)