Talk:Session Fixation - Revision history

Laurent.B: Formatting...

2015-03-19T14:27:23Z

Formatting...

Wimp: Disagreement of where to invalidate a session; Question to Weblogic an session fixation

2010-03-30T06:55:28Z

Disagreement of where to invalidate a session; Question to Weblogic an session fixation

Rejeev: Session Fixaton in WebLogic Server 10.3 and Tomcat 6.0.20

2009-09-09T08:01:40Z

Session Fixaton in WebLogic Server 10.3 and Tomcat 6.0.20

New page

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 ( [http://rejeev.googlepages.com/SimpleWebApp1.war]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
[http://rejeev.blogspot.com/2009/09/session-fixation_08.html]http://rejeev.blogspot.com/2009/09/session-fixation_08.html

← Older revision		Revision as of 06:55, 30 March 2010
Line 43:		Line 43:
	Please see the following blog entry for details		Please see the following blog entry for details
	[http://rejeev.blogspot.com/2009/09/session-fixation_08.html]http://rejeev.blogspot.com/2009/09/session-fixation_08.html		[http://rejeev.blogspot.com/2009/09/session-fixation_08.html]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: [https://www.bsi.bund.de/cae/servlet/contentblob/476464/publicationFile/30642/WebSec_pdf.pdf Sicherheit von Webanwendungen] (from the German BSI, page 40).
		+
		+	2) Weblogic and session fixation
		+
		+	In the [http://download.oracle.com/docs/cd/E12839_01/web.1111/e13852/toc.htm 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?
		+
		+	--[[User:Wimp\|Wimp]] 06:55, 30 March 2010 (UTC)

@@ Line 1: / Line 1: @@
 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 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:
-) 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.
+# 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.
-) 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.
+# 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.
-) 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.
+# 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.
-) 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).
+# 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. )
@@ Line 12: / Line 12: @@
 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:
-	<%
+<code>
-	<form action="j_security_check" method="POST" name="login">
+  <% session.invalidate(); %>
-		<input type="input" name="j_username" />
+</code>
 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.
@@ Line 30: / Line 32: @@
 Sample application to demonstrate the vulnerability
-) Download the SimpleWebApp1 ( [http://rejeev.googlepages.com/SimpleWebApp1.war]http://rejeev.googlepages.com/SimpleWebApp1.war )
+# Download the SimpleWebApp1 ( [http://rejeev.googlepages.com/SimpleWebApp1.war]http://rejeev.googlepages.com/SimpleWebApp1.war )
-) Configure a WebLogic or Tomcat server
+# Configure a WebLogic or Tomcat server
-) Create a user called "user1" in weblogic
+# Create a user called "user1" in weblogic
-) Create a user called "user1" and role called "user1" in Tomcat
+# Create a user called "user1" and role called "user1" in Tomcat
-) Deploy the application in WebLogic or tomcat
+# Deploy the application in WebLogic or tomcat
-) Access test2.jsp (http://localhost:7001/SimpleWebApp1/test2.jsp)
+# Access test2.jsp (http://localhost:7001/SimpleWebApp1/test2.jsp)
-) Note the cookie (use LiveHttpHeaders with firefox)
+# Note the cookie (use LiveHttpHeaders with firefox)
-) Access test1.jsp (http://localhost:7001/SimpleWebApp1/test1.jsp). You will be asked to log in, log in.
+# Access test1.jsp (http://localhost:7001/SimpleWebApp1/test1.jsp). You will be asked to log in, log in.
-) 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.
+# 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.
@@ Line 46: / Line 48: @@
 ---
-) Do server side session invalidation
+# 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.
-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: [https://www.bsi.bund.de/cae/servlet/contentblob/476464/publicationFile/30642/WebSec_pdf.pdf Sicherheit von Webanwendungen] (from the German BSI, page 40).
-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: [https://www.bsi.bund.de/cae/servlet/contentblob/476464/publicationFile/30642/WebSec_pdf.pdf Sicherheit von Webanwendungen] (from the German BSI, page 40).
+# Weblogic and session fixation
+#: In the [http://download.oracle.com/docs/cd/E12839_01/web.1111/e13852/toc.htm 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?
 --[[User:Wimp|Wimp]] 06:55, 30 March 2010 (UTC)