Final edit
← Older revision
Revision as of 10:46, 17 May 2014
Line 3:
Line 3:
== Brief Summary ==
== 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).
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).
+
== Description of the Issue ==
== Description of the Issue ==
Line 8:
Line 9:
* 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.
−
Furthermore, the issue described above is problematic for sites which issue a session identifier over HTTP and then redirect the user to a HTTPS login form. If the session identifier is not reissued upon authentication, the identifier may be eavesdropped and may be used by an attacker to hijack the session.
−
== 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.
+
+
+
== Black Box
Testing
==
'''Testing for Session Fixation vulnerabilities:''' <br>
'''Testing for Session Fixation vulnerabilities:''' <br>
−
The first step is to make a request to the site to be tested (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 29:
Line 34:
Content-Language: en-US
Content-Language: en-US
</pre>
</pre>
−
We observe that the
application sets a new session identifier JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 for the client.
<br>
+
−
Next, if
we
successfully
authenticate
to the application with 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 48:
Line 57:
Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in
Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in
</pre>
</pre>
−
We observe
the following response from the server:
+
+
+
The tester observes
the following response from the server:
<pre>
<pre>
HTTP/1.1 200 OK
HTTP/1.1 200 OK
Line 64:
Line 75:
...
...
</pre>
</pre>
−
As no new cookie has been issued upon a successful authentication we know that it is possible to perform session hijacking.
−
<br>
−
'''Result Expected:'''<br>
−
We 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.<br>
−
== Gray Box
testing and example
==
+
−
Talk with developers and understand if they have implemented a session token renew after a user successful authentication.
<br>
+
As no new cookie has been issued upon a successful authentication the tester knows that it is possible to perform session hijacking.
−
'''Result Expected:'''
<br>
+
+
+
+
'''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.
The application should always first invalidate the existing session ID before authenticating a user, and if the authentication is successful, provide another sessionID.
−
<br><br>
+
== References ==
== References ==