Testing for Session Fixation (OTG-SESS-003) - Revision history

Andrew Muller: Andrew Muller moved page Testing for Session Fixation (OWASP-SM-003) to Testing for Session Fixation (OTG-SESS-003): Align with Common Numbering

2014-07-31T14:15:47Z

Andrew Muller moved page Testing for Session Fixation (OWASP-SM-003) to Testing for Session Fixation (OTG-SESS-003): Align with Common Numbering

Andrew Muller at 14:15, 31 July 2014

2014-07-31T14:15:27Z

Jane O'Connor: Final edit

2014-05-17T10:46:42Z

Final edit

Mmeucci at 14:49, 9 October 2012

2012-10-09T14:49:23Z

Rick.mitchell: /* Brief Summary */ - Minor correction to leadin..

2010-02-23T12:26:57Z

‎Brief Summary: - Minor correction to leadin..

D0ubl3 h3lix: /* References */

2010-01-31T05:57:14Z

‎References

Stanka: /* References */

2009-12-16T10:22:02Z

‎References

KirstenS: /* Gray Box testing and example */

2009-02-06T14:40:22Z

‎Gray Box testing and example

KirstenS: /* Brief Summary */

2009-02-06T13:45:41Z

‎Brief Summary

KirstenS: /* Description of the Issue */

2009-02-06T13:45:08Z

‎Description of the Issue

@@ Line 5: / Line 5: @@
 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.
@@ Line 16: / Line 15: @@
 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 ==
+=== Black Box Testing ===
 '''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 the tester requests the following:
@@ Line 85: / Line 84: @@
-== Gray Box Testing ==
+=== Gray Box Testing ===
 Talk with developers and understand if they have implemented a session token renew after a user successful authentication.
@@ Line 91: / Line 90: @@
 '''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.
@@ Line 99: / Line 103: @@
 * Chris Shiflett: http://shiflett.org/articles/session-fixation
 <br>

@@ Line 3: / Line 3: @@
 == 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).
 == 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.
 * 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 ==
+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.
 '''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
-We will obtain the following answer:
+They will obtain the following answer:
 <pre>
 HTTP/1.1 200 OK
@@ Line 29: / Line 34: @@
 Content-Language: en-US
 </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:
 <pre>
 POST https://www.example.com/authentication.php HTTP/1.1
@@ Line 48: / Line 57: @@
 Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in
 </pre>
-We observe the following response from the server:
 <pre>
 HTTP/1.1 200 OK
@@ Line 64: / Line 75: @@
 ...
 </pre>
-== 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>
 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 ==

← Older revision		Revision as of 14:49, 9 October 2012
Line 1:		Line 1:
−	{{Template:OWASP Testing Guide v3}}	+	{{Template:OWASP Testing Guide v4}}

	== Brief Summary ==		== Brief Summary ==

@@ Line 2: / Line 2: @@
 == 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. 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 ==

@@ Line 82: / Line 82: @@
 <br>
 '''Tools'''<br>
 * OWASP WebScarab: [[OWASP_WebScarab_Project]]

← Older revision	Revision as of 14:15, 31 July 2014
(No difference)