Testing Cookie Based Session Management

A solid understanding of session management is a critical skill for assessing web applications. These principles are the basis for many other test cases related to privilege escalation and access control. Because of this, we recommend all new testers dedicate time to ensure they are proficient in these fundamentals. In this article we have some key goals here to learn and review the following:

• Identify and confirm session tokens
• Understand the session management framework
• Avoid pitfalls of assumption and false positives

Understanding how the application identifies users

HTTP is a stateless protocol, meaning the protocol itself does not have the capability to manage or identify which request comes from which user. For applications that require authenticated access, the application itself must perform this access control. For most web based applications, cookie based session management is used to identify users and the HTTP requests that originate from them. Below is a high level overview of this scheme:

1. A user submits a login and password.
2. The server validates credentials and returns a session token for successful logins.
3. The user’s web browser stores this token and then includes the token with every request.
4. The application validates the token upon each request. It also should verify the role and permissions of the user and ensure the request conforms to those permissions.

Finding the session token

A penetration tester must have a strong understanding of what cookies are used by the application to identify users. To do this we will observe requests we know are used in an authenticated context. We then must use a process of elimination of removing or tampering with token values to find the session token(s).

Note: The most common mistake we see new pentesters make is to assume the session tokens are the cookies named with “SessionID” in their name. A tester should never make this assumption.

Step 1 – Find an authenticated request

We must select a request which returns data belonging to the authenticated user. We do this so we know without a doubt that the application is using at least one token in this request to identify the user. In this example we login to Dropbox with a test account and look for an API endpoint that returns data belonging to us. In this case we see the endpoint recents/check_files_in_root_collection which shows our file listing.

Using Burp we will right click and ‘Send to Repeater’.

Step 2 – Tamper with cookie values and observe failures

We will make a note of all cookies sent in the request and tamper with the values of each individually and record which requests fail. Using this process of elimination, we can see which tokens are required for the request to be successful. In many cases, these will be one cookie required to make successful authenticated requests; this cookie would be the only session cookie. However in some cases there will be multiple tokens required; in this case they will all be considered session tokens in which they must collectively meet security requirements.

Step 3 – Understand frameworks and backend technology

We also want to use this process to understand what frameworks may be in use by the application. Although a pentester should never rely on names alone, cookie names can provide valuable clues to application components used in the stack.

Next steps

We are almost ready to use these skills in a penetration test, but we first must cover a few more formalities before jumping in. Next in the series we will cover test cases for session cookie configuration in testing for secure cookie configuration.