Testing for Session puzzling (OTG-SESS-008) - Revision history

Nawwar: /* Summary */ typo: by -> but

2015-08-17T18:50:59Z

‎Summary: typo: by -> but

Andrew Muller at 13:18, 8 August 2014

2014-08-08T13:18:51Z

Andrew Muller: Andrew Muller moved page Testing for Session puzzling (OTG-SESS-010) to Testing for Session puzzling (OTG-SESS-008)

2014-08-08T11:58:13Z

Andrew Muller moved page Testing for Session puzzling (OTG-SESS-010) to Testing for Session puzzling (OTG-SESS-008)

Andrew Muller at 14:27, 31 July 2014

2014-07-31T14:27:33Z

Jane O'Connor: Final edit

2014-05-17T17:24:34Z

Final edit

Irene Abezgauz: minor addition to description, minor edits

2014-04-22T21:42:51Z

minor addition to description, minor edits

Davide Danelon at 16:41, 7 March 2014

2014-03-07T16:41:47Z

Davide Danelon at 16:41, 7 March 2014

2014-03-07T16:41:17Z

Andrew Muller at 13:29, 14 November 2013

2013-11-14T13:29:22Z

Andrew Muller: Andrew Muller moved page Testing for Session puzzling (OWASP-SESS-010) to Testing for Session puzzling (OTG-SESS-010): Clean up of new OTG numbering scheme

2013-11-14T13:26:03Z

Andrew Muller moved page Testing for Session puzzling (OWASP-SESS-010) to Testing for Session puzzling (OTG-SESS-010): Clean up of new OTG numbering scheme

@@ Line 4: / Line 4: @@
 == Summary ==
-Session Variable Overloading (also known as Session Puzzling) is an application level vulnerability which can enable an attacker to perform a variety of malicious actions, including by not limited to:
+Session Variable Overloading (also known as Session Puzzling) is an application level vulnerability which can enable an attacker to perform a variety of malicious actions, including but not limited to:
 * Bypass efficient authentication enforcement mechanisms, and impersonate legitimate users.
 * Elevate the privileges of a malicious user account, in an environment that would otherwise be considered foolproof.

@@ Line 35: / Line 35: @@
 The most effective way to detect these vulnerabilities is via a source code review.
@@ Line 46: / Line 41: @@
 * Session Puzzles: http://puzzlemall.googlecode.com/files/Session%20Puzzles%20-%20Indirect%20Application%20Attack%20Vectors%20-%20May%202011%20-%20Whitepaper.pdf
 * Session Puzzling and Session Race Conditions: http://sectooladdict.blogspot.com/2011/09/session-puzzling-and-session-race.html

@@ Line 2: / Line 2: @@
-== Brief Summary ==
+== Summary ==
 Session Variable Overloading (also known as Session Puzzling) is an application level vulnerability which can enable an attacker to perform a variety of malicious actions, including by not limited to:
@@ Line 12: / Line 12: @@
 This vulnerability occurs when an application uses the same session variable for more than one purpose. An attacker can potentially access pages in an order unanticipated by the developers so that the session variable is set in one context and then used in another.
@@ Line 22: / Line 21: @@
 For example - an authentication bypass attack vector could be executed by accessing a publicly accessible entry point (e.g. a password recovery page) that populates the session with an identical session variable, based on fixed values or on user originating input.
+==How to Test==
-== Black Box Testing ==
+=== Black Box Testing ===
 This vulnerability can be detected and exploited by enumerating all of the session variables used by the application and in which context they are valid. In particular this is possible by accessing a sequence of entry points and then examining exit points. In case of black box testing this procedure is difficult and requires some luck since every different sequence could lead to a different result.
-===Examples===
+====Examples====
 A very simple example could be the password reset functionality that, in the entry point, could request the user to provide  some identifying information such as the username or the e-mail address. This page might then populate the session with these identifying values, which are received directly from the client side, or obtained from queries or calculations based on the received input. At this point there may be some pages in the application that show private data based on this session object. In this manner the attacker could bypass the authentication process.
-== Gray Box testing and example ==
+=== Gray Box testing ===
 The most effective way to detect these vulnerabilities is via a source code review.
-==Prevention==
+==Remediation==
 Session variables should only be used for a single consistent purpose.

@@ Line 4: / Line 4: @@
 == Brief Summary ==
-Session Variable Overloading (also known as Session Puzzling) is an application level vulnerability which can enable an attacker to perform a variety of malicious actions not limited to:
+Session Variable Overloading (also known as Session Puzzling) is an application level vulnerability which can enable an attacker to perform a variety of malicious actions, including by not limited to:
 * Bypass efficient authentication enforcement mechanisms, and impersonate legitimate users.
 * Elevate the privileges of a malicious user account, in an environment that would otherwise be considered foolproof.
-* Skip over qualifying phases in multiphase processes, even if the process includes all the commonly recommended code level restrictions.
+* Skip over qualifying phases in multi-phase processes, even if the process includes all the commonly recommended code level restrictions.
 * Manipulate server-side values in indirect methods that cannot be predicted or detected.
 * Execute traditional attacks in locations that were previously unreachable, or even considered secure.
 == Description of the Issue ==
-This vulnerability occurs when an application uses the same session variable for more than one purpose.
+This vulnerability occurs when an application uses the same session variable for more than one purpose. An attacker can potentially access pages in an order unanticipated by the developers so that the session variable is set in one context and then used in another.
-== Black Box Testing and Examples ==
+For example, an attacker could use session variable overloading to bypass authentication enforcement mechanisms of applications that enforce authentication by validating the existence of session variables that contain identity–related values, which are usually stored in the session after a successful authentication process. This means an attacker first accesses a location in the application that sets session context and then accesses privileged locations that examine this context.
 ===Examples===
-A very simple example could be the password reset functionality that, in the entry point, could request to the user some identifying information as the username or the e-mail. This page might then populate the session with these identifying values, which are received directly from the client side, or obtained from queries or calculations based on the received input. At this point there may be some pages, in the application, that show private data based on this session object. In this manner the attacker could bypass the authentication process.
+A very simple example could be the password reset functionality that, in the entry point, could request the user to provide  some identifying information such as the username or the e-mail address. This page might then populate the session with these identifying values, which are received directly from the client side, or obtained from queries or calculations based on the received input. At this point there may be some pages in the application that show private data based on this session object. In this manner the attacker could bypass the authentication process.
 == Gray Box testing and example ==
 The most effective way to detect these vulnerabilities is via a source code review.
 ==Prevention==
 Session variables should only be used for a single consistent purpose.
 ==References==

@@ Line 14: / Line 14: @@
 This vulnerability occurs when an application uses the same session variable for more than one purpose.
-An attacker can potentially access pages in an order unanticipated by the developers so that the session variable is set one one context and then used in another.
+An attacker can potentially access pages in an order unanticipated by the developers so that the session variable is set in one context and then used in another.
 For example an attacker could use session variable overloading to bypass authentication enforcement mechanisms
 of applications that enforce authentication by validating the existence of session
-variables that contain identity–related values, which are usually stored in the session after a successful authentication process.
+variables that contain identity–related values, which are usually stored in the session after a successful authentication process. This means an attacker first accesses a location in the application that sets session context and then accesses privileged locations that examine this context. For example - an
-The authentication bypass attack vector could be executed by accessing a publicly
+authentication bypass attack vector could be executed by accessing a publicly
 accessible entry point (e.g. a password recovery page) that populates the session with
 an identical session variable, based on fixed values or on user originating input.
@@ Line 25: / Line 25: @@
 == Black Box Testing and Examples ==
-This vulnerability can be detected and exploited enumerating all of the session variables used by the application and in which context they are valid. In particular this is possible by accessing a sequence of entry points. In case of black box test, obviously, this procedure is difficult and require also luck since every different sequence could leads to a different result.
+This vulnerability can be detected and exploited by enumerating all of the session variables used by the application and in which context they are valid. In particular this is possible by accessing a sequence of entry points and then examining exit points. In case of black box testing, obviously, this procedure is difficult and requires some luck since every different sequence could lead to a different result.
 ===Examples===
-A very simple example could be the password reset functionality that, in the entry point, could request to the user some indentifying information as the username or the e-mail. This page might then populate the session with these identifying values, which are received directly from the client side, or obtained from queries or calculations based on the received input. At this point there may be some pages, in the application, that show private data based on this session object. In this manner the attacker could bypass the authentication process.
+A very simple example could be the password reset functionality that, in the entry point, could request to the user some identifying information as the username or the e-mail. This page might then populate the session with these identifying values, which are received directly from the client side, or obtained from queries or calculations based on the received input. At this point there may be some pages, in the application, that show private data based on this session object. In this manner the attacker could bypass the authentication process.
 == Gray Box testing and example ==

← Older revision	Revision as of 11:58, 8 August 2014
(No difference)

← Older revision	Revision as of 13:26, 14 November 2013
(No difference)