Talk:Session Fixation

From OWASP
Revision as of 03:01, 9 September 2009 by Rejeev (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Session Fixation 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 ( [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