This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit

Testing for Session puzzling (OTG-SESS-008)

Revision as of 16:41, 7 March 2014 by Davide Danelon (talk | contribs)

Jump to: navigation, search
This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: Back to the OWASP Testing Guide Project:

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:

  • 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.
  • 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. 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.

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. The 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.

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.


A very simple example could be the password reset functionality that, in the initial 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.

Gray Box testing and example

The most effective way to detect these vulnerabilities is via a source code review.


Session variables should only be used for a single consistent purpose.