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 "Testing for Session Fixation (OTG-SESS-003)"

From OWASP
Jump to: navigation, search
m (Andrew Muller moved page Testing for Session Fixation (OWASP-SM-003) to Testing for Session Fixation (OTG-SESS-003): Align with Common Numbering)
 
(15 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{Template:OWASP Testing Guide v3}}
+
{{Template:OWASP Testing Guide v4}}
 +
 
 +
== Brief Summary ==
 +
When an application does not renew its session cookie(s) after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie known by the attacker. In that case, an attacker could steal the user session (session hijacking).
  
'''This is a draft of a section of the new Testing Guide v3'''
 
  
== Brief Summary ==
 
When an application does not renew the cookie after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie known by the attacker.
 
<br>
 
== Description of the Issue ==
 
<br>
 
 
Session fixation vulnerabilities occur when:<br>
 
Session fixation vulnerabilities occur when:<br>
 
* A web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user.
 
* A web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user.
 
* An attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session.  
 
* An attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session.  
 +
 +
 
In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user's account through the active session.
 
In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user's account through the active session.
<br>
+
 
== Black Box testing and example ==
+
 
 +
Furthermore, the issue described above is problematic for sites that issue a session identifier over HTTP and then redirect the user to a HTTPS log in form. If the session identifier is not reissued upon authentication, the attacker can eavesdrop and steal the identifier and then use it to hijack the session.
 +
 
 +
==How to Test==
 +
=== Black Box Testing ===
 
'''Testing for Session Fixation vulnerabilities:''' <br>
 
'''Testing for Session Fixation vulnerabilities:''' <br>
The first step is to access to the domain to test, for example www.example.com. If we request the following:
+
The first step is to make a request to the site to be tested (example www.example.com). If the tester requests the following:
 
  GET www.example.com
 
  GET www.example.com
We will obtain the following answer:
+
They will obtain the following answer:
 
<pre>
 
<pre>
 
HTTP/1.1 200 OK
 
HTTP/1.1 200 OK
Line 30: Line 33:
 
Content-Language: en-US
 
Content-Language: en-US
 
</pre>
 
</pre>
We can notice that the application will set a new JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 on the client browser.<br>
+
 
Now, if we authenticate on the application, for example sending the following POST HTTPS:
+
 
 +
The application sets a new session identifier JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 for the client.  
 +
 
 +
 
 +
Next, if the tester successfully authenticates to the application with the following POST HTTPS:
 
<pre>
 
<pre>
 
POST https://www.example.com/authentication.php HTTP/1.1
 
POST https://www.example.com/authentication.php HTTP/1.1
Line 49: Line 56:
 
Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in
 
Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in
 
</pre>
 
</pre>
if we obtain an answer as the following:
+
 
 +
 
 +
The tester observes the following response from the server:
 
<pre>
 
<pre>
 
HTTP/1.1 200 OK
 
HTTP/1.1 200 OK
Line 65: Line 74:
 
...
 
...
 
</pre>
 
</pre>
we can understand that the application does not renew the user cookie after a successful authentication.
+
 
<br>
+
 
'''Result Expected:'''<br>
+
As no new cookie has been issued upon a successful authentication the tester knows that it is possible to perform session hijacking.
Now we can try to inject a valid cookie to a user (using a social engineering trick) and verify that it is possible to hijack the user session.
+
 
<br>
+
 
== Gray Box testing and example ==  
+
 
'''Testing for Topic X vulnerabilities:'''<br>
+
'''Result Expected:'''
Talk with developers and understand if they have implemented a session token renew after a user successful authentication.<br>
+
The tester can send a valid session identifier to a user (possibly using a social engineering trick), wait for them to authenticate, and subsequently verify that privileges have been assigned to this cookie.
'''Result Expected:'''<br>
+
 
The application should always first invalidating the existing session ID before authenticating a user and if the authentication is successful, provide another sessionID.
+
 
<br><br>
+
=== Gray Box Testing ===  
 +
Talk with developers and understand if they have implemented a session token renew after a user successful authentication.
 +
 
 +
 
 +
'''Result Expected:'''
 +
The application should always first invalidate the existing session ID before authenticating a user, and if the authentication is successful, provide another sessionID.
 +
 
 +
 
 +
==Tools==
 +
* JHijack - a numeric session hijacking tool - http://yehg.net/lab/pr0js/files.php/jhijackv0.2beta.zip
 +
* OWASP WebScarab: [[OWASP_WebScarab_Project]]
 +
 
 +
 
 
== References ==
 
== References ==
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
...<br>
+
* [[Session Fixation]]
'''Tools'''<br>
+
* ACROS Security: http://www.acrossecurity.com/papers/session_fixation.pdf
* OWASP WebScarab: [[OWASP_WebScarab_Project]]
+
* Chris Shiflett: http://shiflett.org/articles/session-fixation
 +
<br>

Latest revision as of 14:15, 31 July 2014

This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project

Brief Summary

When an application does not renew its session cookie(s) after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie known by the attacker. In that case, an attacker could steal the user session (session hijacking).


Session fixation vulnerabilities occur when:

  • A web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user.
  • An attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session.


In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user's account through the active session.


Furthermore, the issue described above is problematic for sites that issue a session identifier over HTTP and then redirect the user to a HTTPS log in form. If the session identifier is not reissued upon authentication, the attacker can eavesdrop and steal the identifier and then use it to hijack the session.

How to Test

Black Box Testing

Testing for Session Fixation vulnerabilities:
The first step is to make a request to the site to be tested (example www.example.com). If the tester requests the following:

GET www.example.com

They will obtain the following answer:

HTTP/1.1 200 OK
Date: Wed, 14 Aug 2008 08:45:11 GMT
Server: IBM_HTTP_Server
Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1; Path=/; secure
Cache-Control: no-cache="set-cookie,set-cookie2"
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html;charset=Cp1254
Content-Language: en-US


The application sets a new session identifier JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 for the client.


Next, if the tester successfully authenticates to the application with the following POST HTTPS:

POST https://www.example.com/authentication.php HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.example.com
Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1
Content-Type: application/x-www-form-urlencoded
Content-length: 57

Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in


The tester observes the following response from the server:

HTTP/1.1 200 OK
Date: Thu, 14 Aug 2008 14:52:58 GMT
Server: Apache/2.2.2 (Fedora)
X-Powered-By: PHP/5.1.6
Content-language: en
Cache-Control: private, must-revalidate, max-age=0
X-Content-Encoding: gzip
Content-length: 4090
Connection: close
Content-Type: text/html; charset=UTF-8
...
HTML data
...


As no new cookie has been issued upon a successful authentication the tester knows that it is possible to perform session hijacking.


Result Expected: The tester can send a valid session identifier to a user (possibly using a social engineering trick), wait for them to authenticate, and subsequently verify that privileges have been assigned to this cookie.


Gray Box Testing

Talk with developers and understand if they have implemented a session token renew after a user successful authentication.


Result Expected: The application should always first invalidate the existing session ID before authenticating a user, and if the authentication is successful, provide another sessionID.


Tools


References

Whitepapers