This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Session fixation"

From OWASP
Jump to: navigation, search
(→‎Related Vulnerabilities)
Line 1: Line 1:
 
{{Template:Attack}}
 
{{Template:Attack}}
  
−
{{Template:Stub}}
+
==Description==
 +
 
 +
The session fixation is an attack that permits hijack a valid user session. The attack explore a limitation in the way the web application manage the session ID, more specifically the vulnerable web application, when authenticate an user, doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists in 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. So the attacker has to provide a legitimate Web application session ID and try to make the victim browser to use it.
 +
 
 +
The session fixation attack is considered a class of session hijacking, but, instead to steal the established session between the client and the Web Server after the user log in. Instead the session fixation attack, fixes an established session on the victim browser so the attack starts before the user log in.
 +
 
 +
There are some techniques to execute the attack, it depends on how the Web application deals with session token, below are some of the most common techniques:
 +
 
 +
'''• Session token in the URL argument:'''
 +
Session ID is sent to the victim in a hyperlink and the victim have to access the site through the malicious URL.
 +
'''
 +
• 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.
 +
 
 +
'''• Session ID in a cookie:'''
  
−
==Description==
+
o Client-side script
 +
 
 +
Most of browsers support the execution of client-side scripting, in this case, the aggressor could use attacks of code injection as the XSS attack (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 execute the command become capable to fix values inside of the cookie that it will be used to keep a session between the client and the Web Application.
 +
 +
o <META> tag
 +
 
 +
<META> tag also is considered a code injection attack, however, different of the XSS attack where scripts undesirable can be disabled or deny the execution, the attack using this method becomes much more efficient for the impossibility to disable the processing of these tags in the browsers.
 +
 
 +
o HTTP header response
 +
 
 +
This method explores the server response to fix the Session ID in the victim browser. Including the parameter Set-Cookie in the HTTP header response, the attacker is capable to insert the value of Session ID in the cookie and sends it to the victim browser.
 +
 
 +
== Severity ==
 +
 
 +
High
 +
 
 +
== Likelihood of exploitation ==
  
−
This article should cover attacks where the attacker forces the victim to use a chosen session identifier.
+
Medium to High
  
 
==Examples ==
 
==Examples ==
 +
===Example 1===
 +
The example below has the intention to explain 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 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.
 +
 +
<center>
 +
 +
https://www.owasp.org/images/9/9c/Fixation.jpg
 +
 +
Figure 1. Simple example of Session Fixation attack.
 +
</center>
 +
 +
 +
 +
===Example 2===
 +
Client-side scripting
 +
 +
The processes for the attack using the execution of scripts in the victim browser are very similar with the 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 cookie, the attacker could insert a Javascript code in the URL that will be executed in the victim browser.
 +
 +
<nowiki> http://website.kom/<script>document.cookie=”sessionid=abcd”;</script></nowiki>
 +
 +
===Example 3===
 +
<META> tag
 +
 +
As well as client-side scripting, the codes 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>
 +
 +
===Example 4===
 +
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.
 +
 +
<center>
 +
 +
https://www.owasp.org/images/e/ed/Fixation2.jpg
 +
 +
Figure 2. Set-Cookie in the HTTP header response
 +
</center>
 +
 +
== External References==
 +
 +
*http://www.acros.si/papers/session_fixation.pdf
 +
*http://en.wikipedia.org/wiki/Session_fixation
 +
*http://www.derkeiler.com/pdf/Mailing-Lists/Securiteam/2002-12/0099.pdf
  
 
==Related Threats==
 
==Related Threats==
 +
 +
[[:Category:Authorization]]
  
 
==Related Attacks==
 
==Related Attacks==
 +
 +
* [[XSS Attacks]]
 +
* [[Session hijacking attack]]
  
 
==Related Vulnerabilities==
 
==Related Vulnerabilities==
  
−
[[Session Trapping]]
+
[[:Category:Session Management Vulnerability]]
  
 
==Related Countermeasures==
 
==Related Countermeasures==
 +
 +
*[[Session Fixation Protection]]
 +
 +
 +
 +
[[Category:Session Management]]
  
 
[[Category:Attack]]
 
[[Category:Attack]]

Revision as of 12:08, 6 November 2007

This is an Attack. To view all attacks, please see the Attack Category page.


Description

The session fixation is an attack that permits hijack a valid user session. The attack explore a limitation in the way the web application manage the session ID, more specifically the vulnerable web application, when authenticate an user, doesn’t assign a new session ID, making it possible to use an existent session ID. The attack consists in 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. So the attacker has to provide a legitimate Web application session ID and try to make the victim browser to use it.

The session fixation attack is considered a class of session hijacking, but, instead to steal the established session between the client and the Web Server after the user log in. Instead the session fixation attack, fixes an established session on the victim browser so the attack starts before the user log in.

There are some techniques to execute the attack, it depends on how the Web application deals with session token, below are some of the most common techniques:

• Session token in the URL argument: Session ID is sent to the victim in a hyperlink and the victim have to access the site through the malicious URL. • 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.

• Session ID in a cookie:

o Client-side script

Most of browsers support the execution of client-side scripting, in this case, the aggressor could use attacks of code injection as the XSS attack (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 execute the command become capable to fix values inside of the cookie that it will be used to keep a session between the client and the Web Application.

o <META> tag

<META> tag also is considered a code injection attack, however, different of the XSS attack where scripts undesirable can be disabled or deny the execution, the attack using this method becomes much more efficient for the impossibility to disable the processing of these tags in the browsers.

o HTTP header response

This method explores the server response to fix the Session ID in the victim browser. Including the parameter Set-Cookie in the HTTP header response, the attacker is capable to insert the value of Session ID in the cookie and sends it to the victim browser.

Severity

High

Likelihood of exploitation

Medium to High

Examples

Example 1

The example below has the intention to explain 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 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.

Fixation.jpg

Figure 1. Simple example of Session Fixation attack.


Example 2

Client-side scripting

The processes for the attack using the execution of scripts in the victim browser are very similar with the 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 cookie, the attacker could insert a Javascript code in the URL that will be executed in the victim browser. 

 http://website.kom/<script>document.cookie=”sessionid=abcd”;</script>

Example 3

<META> tag

As well as client-side scripting, the codes injection must be made in the URL that will be sent to the victim. 

http://website.kon/<meta http-equiv=Set-Cookie content=”sessionid=abcd”>

Example 4

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.

Fixation2.jpg

Figure 2. Set-Cookie in the HTTP header response

External References

Related Threats

Category:Authorization

Related Attacks

Related Vulnerabilities

Category:Session Management Vulnerability

Related Countermeasures

Retrieved from "https://wiki.owasp.org/index.php?title=Session_fixation&oldid=23144"