Difference between revisions of "Testing for Session Fixation (OTG-SESS-003)"

Jump to: navigation, search
Line 80: Line 80:
* OWASP WebScarab: [[OWASP Webscarab Project]]
* OWASP WebScarab: [[OWASP_WebScarab_Project]]

Revision as of 10:19, 14 August 2008

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here

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 knowed by the attacker.

Description of the Issue

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.

Black Box testing and example

Testing for Session Fixation vulnerabilities:
The first step is to access to the domain to test, for example www.example.com. If we request the following:

GET www.example.com

We 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

We can notice that the application will set a new JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 on the client browser.
Now, if we authenticate on the application, for example sending 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: Gecko/20080702 Firefox/
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


if we obtain an answer as the following:

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

we can understand that the application does not renew the user cookie after a successful authentication.
Result Expected:
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.

Gray Box testing and example

Testing for Topic X vulnerabilities:
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 invalidating the existing session ID before authenticating a user and if the authentication is successful, provide another sessionID.