How To Test For Session Management Vulnerabilities

Testing For Session Management Vulnerabilities

If you are not already familiar with Session Management vulnerabilities, please see the article entitled “What is a Session Management Vulnerability ?“.

The Session Identifier Is Secret

First and foremost, applications seeking to establish and maintain sessions with users must ensure that all transfers of the session identifier token occur in encrypted form.  In practice, this usually means that the application exclusively uses HTTPS and that the cookie is marked as “secure” by setting the cookie’s “secure” flag.  Any transmission of the cookie over a non-secure channel or the failure to mark the cookie as secure represents a Session Management vulnerability.  Any other means of exposing the value of the session identifier token, such as its persistence in a file, or inclusion in a URL represents a Session Management vulnerability. Look for exposure, and if you find it you have detected a vulnerability.

The Session Identifier Must Be Random

Most modern applications use a framework such as J2EE, ASP .NET, PHP, etc. to generate session identifier token values.  Such frameworks will  ensure that session identifiers are generated using a cryptographically strong random number generator and produce sufficiently long strings that defy prediction.   An application that does not use a contemporary framework to generate its session identifier tokens, or one that generates its own values, must be further tested for predictable tokens.  There are tools that can be used to automate the analysis of the entropy of the values.   The Burp Suite includes a tool for testing the entropy of session identifer values, as does the OWASP Web Scarab web-proxy.  Note that entropy analysis is not likely to be a fruitful endeavor unless you strongly suspect that the algorithm is home-grown or the web-application framework is grossly out-of-date.

To detect Session Fixation, it is necessary to utilize a web-proxy to discern when the session identifier token is first communicated to the client browser. If this occurs prior to authentication, you must check whether it changes as the result of authentication.  Modern application servers such as Tomcat and ASP .NET will handle this properly, but older versions and other web-servers may not.  If the session identifier is the sole token used to identify the user (i.e. there is no additional “authentication token”), AND the session identifier is communicated to the client browser prior to user authentication, AND the value is not changed upon successful authentication, this represents a Session Fixation vulnerability.  Note that the J2EE uses a single session token to identify the session, whereas ASP .NET utilizes a second authentication token to represent successful authentication.

The Session Must End On Logout

To determine whether logout is being handled properly, perform the following sequence of tasks:

  • Log into the application
  • Perform any action that requires previous authentication, and capture that request using a web-proxy.
  • Logout of the application
  • Replay (i.e. resubmit) the captured request

If the application returns a response other than the login page or error message, this represents a Session Management vulnerability because the user can still interact with the application following logout.  Be sensitive to browser caching which can manifest false positives.

There Must Be An Inactivity Timeout

Although it is a matter of the application’s requirements, most applications should automatically log the user out after a predefined “inactivity interval”.   To determine if an inactivity timeout has been implemented, perform the following sequence of tasks:

  • Log into the application
  • Go get a cup of coffee, or lunch, or go home for the evening, etc.  (i.e. a time interval greater than the inactivity interval).
  • When you return, try to perform an activity that requires previous authentication.  If the action is successful, this represents a Session Management vulnerability, namely the failure to set an inactivity timeout.

Be aware that some, albeit few, applications do not feature inactivity timeouts by design.  In the absence of explicit requirements (or knowledge thereof) that prohibit an inactivity timeout, you can assume that there should be one.

Closing The Browser Means You’re Done

It is important to protect a user that might utilize your application and then close the browser without first logging out.  Without such protection, an attacker could open the browser, and replay a URL from the Browser History to re-animate the previous user’s session.  This is an easy scenario to test:

  • Log into the application
  • Perform an action that requires previous authentication, and capture the request in a web-proxy
  • Close and re-open the browser
  • Replay the captured request

If the request is not rejected, this behavior represents a Session Management vulnerability; namely the failure to properly terminate the session upon browser closure.

For insight into how to avoid or fix Session Management vulnerabilities, please see the article entitled “How To Prevent Session Management Vulnerabilities“.

About Affinity IT Security

We hope you found this article to be useful. Affinity IT Security is available to help you with your security testing and  train your developers and testers.  In fact, we train developers and IT staff how to hack applications and networks.

Perhaps it was a network scan or website vulnerability test that brought you here.  If so, you are likely researching how to find, fix, or avoid a particular vulnerability.  We urge you to be proactive and ensure that key individuals in your organization understand not only this issue, but also are more broadly aware of application security.

Contact us to learn how to better protect your enterprise.



Although every effort has been made to provide the most useful and highest quality information, it is unfortunate but inevitable that some errors, omissions, and typographical mistakes will appear in these articles. Consequently, Affinity IT Security will not be responsible for any loss or damages resulting directly or indirectly from any error, misunderstanding, software defect, example, or misuse of any content herein.