Session fixation - Revision history

Bill Sempf: Took out Risk Factors heading.

2014-08-14T19:32:27Z

Took out Risk Factors heading.

Mark Sienkiewicz: clarify that good session ids do not guard against this attack

2014-07-18T16:33:17Z

clarify that good session ids do not guard against this attack

Alan Jex: Added to subcategory "Exploitation of Authentication"

2011-12-06T22:29:31Z

Added to subcategory "Exploitation of Authentication"

KirstenS at 11:50, 23 April 2009

2009-04-23T11:50:22Z

KirstenS at 23:20, 7 April 2009

2009-04-07T23:20:16Z

KirstenS at 00:47, 17 February 2009

2009-02-17T00:47:00Z

KirstenS at 18:31, 27 October 2008

2008-10-27T18:31:57Z

KirstenS: /* Description */

2008-09-18T12:50:01Z

‎Description

KirstenS: /* Example 4 */

2008-09-15T01:06:39Z

‎Example 4

KirstenS: /* Example 3 */

2008-09-15T01:05:45Z

‎Example 3

← Older revision		Revision as of 19:32, 14 August 2014
Line 33:		Line 33:

	This method explores the server response to fix the Session ID in the victim's browser. Including the parameter Set-Cookie in the HTTP header response, the attacker is able to insert the value of Session ID in the cookie and sends it to the victim's browser.		This method explores the server response to fix the Session ID in the victim's browser. Including the parameter Set-Cookie in the HTTP header response, the attacker is able to insert the value of Session ID in the cookie and sends it to the victim's browser.
−
−	~~==Risk Factors==~~
−	~~TBD~~

@@ Line 8: / Line 8: @@
 ==Description==
-Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists of inducing a user to authenticate himself with a known session ID, and then hijacking the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim's browser use it.
+Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating a user, it doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists of obtaining a valid session ID (e.g. by connecting to the application), inducing a user to authenticate himself with that session ID, and then hijacking the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim's browser use it.
 The session fixation attack is a class of [[Session hijacking attack|Session Hijacking]], which steals the established session between the client and the Web Server after the user logs in. Instead, the Session Fixation attack fixes an established session on the victim's browser, so the attack starts before the user logs in.

← Older revision		Revision as of 22:29, 6 December 2011
Line 95:		Line 95:
	* http://www.derkeiler.com/pdf/Mailing-Lists/Securiteam/2002-12/0099.pdf		* http://www.derkeiler.com/pdf/Mailing-Lists/Securiteam/2002-12/0099.pdf

		+	==Categories==
		+	[[Category:Exploitation of Authentication]]
	[[Category:Attack]]		[[Category:Attack]]

← Older revision		Revision as of 11:50, 23 April 2009
Line 4:		Line 4:
	[[Category:OWASP ASDR Project]]		[[Category:OWASP ASDR Project]]

		+
		+	Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

	==Description==		==Description==

← Older revision		Revision as of 23:20, 7 April 2009
Line 3:		Line 3:
	<br>		<br>
	[[Category:OWASP ASDR Project]]		[[Category:OWASP ASDR Project]]
−	~~[[ASDR Table of Contents]]~~

@@ Line 3: / Line 3: @@
 <br>
 [[Category:OWASP ASDR Project]]
-[[ASDR Table of Contents]]__TOC__
+[[ASDR Table of Contents]]
 ==Description==
-Session Fixation is an attack that permits an attacker to hijack a valid user session. The attack explores a limitation in the way the web application manages the session ID, more specifically the vulnerable web application. When authenticating an user, it doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists of inducing a user to authenticate himself with a known session ID, and then hijack the user-validated session by the knowledge of the used session ID. The attacker has to provide a legitimate Web application session ID and try to make the victim's browser use it.
+The session fixation attack is a class of [[Session hijacking attack|Session Hijacking]], which steals the established session between the client and the Web Server after the user logs in. Instead, the Session Fixation attack fixes an established session on the victim's browser, so the attack starts before the user logs in.
 There are several techniques to execute the attack; it depends on how the Web application deals with session tokens. Below are some of the most common techniques:
@@ Line 18: / Line 17: @@
 '''• Session token in a hidden form field:'''
-In this method, the victim must be tricked to authenticate in the target Web Server, using a login form developed for the attacker. The form could be hosted in evil web server or directly in html formatted e-mail.
+In this method, the victim must be tricked to authenticate in the target Web Server, using a login form developed for the attacker. The form could be hosted in the evil web server or directly in html formatted e-mail.
 '''• Session ID in a cookie:'''
@@ Line 28: / Line 27: @@
 o <META> tag
-<META> tag also is considered a code injection attack, however, different from the XSS attack where undesirable scripts can be disabled, or the execution can be denied. The attack using this method becomes much more efficient because it's impossibility to disable the processing of these tags in the browsers.
+<META> tag also is considered a code injection attack, however, different from the XSS attack where undesirable scripts can be disabled, or the execution can be denied. The attack using this method becomes much more efficient because it's impossible to disable the processing of these tags in the browsers.
 o HTTP header response
@@ Line 36: / Line 35: @@
 ==Risk Factors==
 TBD
-[[Category:FIXME|need content here]]
 ==Examples ==
 ===Example 1===
-The example below explains a simple form the process of the attack and the expected results.
+The example below explains a simple form, the process of the attack, and the expected results.
 (1)The attacker has to establish a legitimate connection with the web server which (2) issues a session ID or, the attacker can create a new session with the proposed session ID, then, (3) the attacker has to send a link with the established session ID to the victim, she has to click on the link sent from the attacker accessing the site, (4) the Web Server saw that session was already established and a new one need not to be created, (5) the victim provides his credentials to the Web Server, (6) knowing the session ID, the attacker can access the user's account.
@@ Line 54: / Line 53: @@
 Client-side scripting
-The processes for the attack using the execution of scripts in the victim's browser are very similar to example 1, however, in this case, the Session ID does not appear as an argument of the URL, but inside of the cookie. To fix the value of the Session ID in the victim's cookie, the attacker could insert a Javascript code in the URL that will be executed in the victim's browser.
+The processes for the attack using the execution of scripts in the victim's browser are very similar to example 1, however, in this case, the Session ID does not appear as an argument of the URL, but inside of the cookie. To fix the value of the Session ID in the victim's cookie, the attacker could insert a JavaScript code in the URL that will be executed in the victim's browser.
   <nowiki> http://website.kom/<script>document.cookie=”sessionid=abcd”;</script></nowiki>

@@ Line 94: / Line 94: @@
 * http://en.wikipedia.org/wiki/Session_fixation
 * http://www.derkeiler.com/pdf/Mailing-Lists/Securiteam/2002-12/0099.pdf
 [[Category:Attack]]

@@ Line 24: / Line 24: @@
 o Client-side script
-Most browsers support the execution of client-side scripting. In this case, the aggressor could use attacks of code injection as the [[Cross-site scripting|XSS]] (Cross-site scripting) attack to insert a malicious code in the hyperlink sent to the victim and fix a Session ID in its cookie. Using the function document.cookie, the browser which executes the command becomes capable of fixing values inside of the cookie that it will use to keep a session between the client and the Web Application.
+Most browsers support the execution of client-side scripting. In this case, the aggressor could use attacks of code injection as the [[Cross-site Scripting (XSS)|XSS]] (Cross-site scripting) attack to insert a malicious code in the hyperlink sent to the victim and fix a Session ID in its cookie. Using the function document.cookie, the browser which executes the command becomes capable of fixing values inside of the cookie that it will use to keep a session between the client and the Web Application.
 o <META> tag

@@ Line 68: / Line 68: @@
 HTTP header response
-The insertion of the value of the SessionID in the cookie manipulating the server response can be made intercepting the packages exchanged between the client and the Web Application inserting the Set-Cookie parameter.
+The insertion of the value of the SessionID into the cookie manipulating the server response can be made, intercepting the packages exchanged between the client and the Web Application inserting the Set-Cookie parameter.
 <center>
@@ Line 75: / Line 75: @@
 Figure 2. Set-Cookie in the HTTP header response
 </center>
 ==Related [[Threat Agents]]==

@@ Line 61: / Line 61: @@
 <META> tag
-As well as client-side scripting, the codes injection must be made in the URL that will be sent to the victim.
+As well as client-side scripting, the code injection must be made in the URL that will be sent to the victim.
   <nowiki>http://website.kon/<meta http-equiv=Set-Cookie content=”sessionid=abcd”></nowiki>