This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Testing for Session Management
Session Management Testing
At the core of any web-based application is the way in which it maintains state and thereby controls user-interaction with the site. Session Management broadly covers all controls on a user from authentication to leaving the application.
HTTP is a stateless protocol, meaning web servers respond to client requests without linking them to each other. Even simple application logic requires a user's multiple requests to be associated with each other across a "session”. This necessitates third party solutions – through either Off-The-Shelf (OTS) middleware and web-server solutions, or bespoke developer implementations. Most popular web application environments, such as ASP and PHP, provide developers with built in session handling routines. Some kind of identification token will typically be issued, which will be referred to as “Session IDs” or Cookies.
There are a number of ways a web-application may interact with a user. Each is dependant upon the nature of the site, the security and availability requirements of the application.
Whilst there are accepted best practices for application development, such as those outlined in the OWASP Guide to Building Secure Web Applications, it is important that application security is considered within the context of the provider’s requirements and expectations. In this chapter we describe the following items.
4.5.1 Analysis of the Session Management Schema
This paragraph describes how to analyse a Session Management Schema, with the goal to understand how the Session Management mechanism has been developed and if it is possible to break it
4.5.2 Cookie and Session Token Manipulation
Here it is explained how to test the security of session Token issued to the Client: cookie reverse engineering, and cookie manipulation
4.5.3 Exposed Session Variables
Session Tokens represent confidential informations because they tie the user identity with his own session. It's possible to test if the session token is exposed to this vulnerability.
4.5.4 Session Riding
4.5.5 HTTP Exploit
Then is described how to test for HTTP Exploit.
4.5.2 Weak Session Tokens (TO ELIMINATE)