AppSec Cheat Sheet: Session Management

Session Management Testing – Cookies

The Cheat Sheet section is for quick reference and to make sure steps don’t get missed.
The Learn section is for those who have never touched the topic before.
The Implement section is for more detailed descriptions of each Cheat Sheet item.

Cheat Sheet

Learn

To understand why sessions are used, and more importantly, why the security around them is so important, we need to first discuss Hypertext Transfer Protocol, or HTTP. HTTP is the language of the Web, and is what is being used when navigating websites and other web services. It is client-server oriented, meaning a client (e.g. a web browser) requests a resource from a server, and the server responds with that resource.

Another interesting thing about HTTP is that it is stateless. Which means each request is independent and unrelated to any request that comes before or any that come after. This differs from another protocol like SSH, which maintains a persistent connection between the client and server after authentication.

If client-server architecture or this stateless nature of HTTP is something you need more detailed material on, Mozilla has an excellent overview of the of the protocol that can be found here.

From a security perspective, this client-server and stateless setup creates a problem when the web begins to be used for anything private. A user could prove who they are by logging in and authenticating to a web application, their bank for instance. However, because no state is maintained between requests, the server will have no knowledge of whose account subsequent requests are for.

So, the server needs some way to keep track of users to ensure that the request is coming from someone who is both authenticated and authorized to access the requested resource. One way this is done is with cookies.

They look like something like this:

JSESSIONID=HnhJKSDm0IKIRCemctC2owXT1qlqiGJYWFBc7x_C

Cookies are data that the browser receives from the server and then sends the data as a part of each request to the server going forward. The server associates that bit of data with a user; therefore, every request that includes that cookie is presumed to be coming from the same user. Tracking users and their associated cookies is called ‘session management’ and allows sensitive data or functionality to be presented to only the correct, authenticated, and authorized users.

So, the importance of proper session management should be evident, as well as why it is a critical component to assess during penetration testing. Without it, private data cannot be transferred securely over the web, and any flaws in these mechanisms may allow unauthorized access to sensitive resources.

At the heart of session management testing is understanding why the application is or isn’t allowing access to a particular resource. Testing will involve identifying the answer to this, and whether that decision can be influenced by attackers.

Implement

The overall objective while attacking session management is to find a way to forge new session tokens to gain unauthorized access to an account or data. Following these steps will allow many impactful flaws to be revealed that are often overlooked.

Identify Session Token(s)

The first step will be to determine what the session token is. To do this, a sensitive request must be found and tokens removed one at a time until the minimum cookies required are present.

For a sensitive request, select one that returns business critical data that is restricted to authenticated users or data specific to the user, like a profile page.

Send this request again, through Repeater for instance, removing cookies until you get a failure to return data. For example, if you have a series of 200 OK responses and removing a cookie results in a 403 Unauthorized response, that’s a good indicator you’ve found a sensitive cookie.

Also, keep an eye on any other changes, like response length. If something sensitive is different in the response, that may indicate some other access control issue. Some cookies are used to restrict access to a tenant, perhaps removing such a cookie allows unrestricted access as an example.

Multiple cookies may be required to make an authenticated request, so when a failure is encountered, go back a step and skip over that sensitive cookie that was just found. Continue removing cookies one by one until either another failure is encountered or every cookie has been tested.

If multiple tokens are identified, further testing will be needed to understand if all tokens are always needed or if certain tokens apply to certain functionality. Additionally, other questions should be investigated, namely will forging one token only grant access to some functionality but not all? Is one token weaker than another? Can any security flaws be found by removing one of the tokens at a certain point in a process? These open-ended questions will be unique to the environment, but useful to keep in mind.

It may be worth noting that if you’ve removed all cookies and still can access the data, either that data is accessible without authentication, or cookies are not the session management mechanism in use. Other methods, like Authorization headers, will be covered in another post.

Every web application environment is going to be different, but this step is intended to answer the question we asked earlier: How does the application know who I am and whether I’m supposed to access this specific data or functionality? Once we know how it’s tracking us, we can then zero in on that mechanism and verify it works as intended or find a way around it.

Uniqueness

Session tokens should be unique for each user on each login. Testing for this characteristic will involve multiple logins to compare session tokens to ensure the same token is not issued for different logins.

If individual users are receiving the same token on every login, this constitutes a static token that, if compromised, will allow an attacker to maintain access to the application. Access may be permitted indefinitely without a means of revoking the token.

Cryptographically Random and Unpredictable

The session token should be random and unpredictable. If it is not, it may be possible to forge new tokens, gaining unauthorized access to another account or data.

Cleartext or Recognizable Pattern

Session token values are sometimes cleartext values or values that have a recognizable pattern, and the token should be manually reviewed to determine this. Although not common, this has been seen on production applications.

Consider a token like this:

014523|aaron|trustedsec|1|0

These separate parts of the token may correspond to user ID, username, tenant, role, or something along those lines, and modifying those parts may allow access to something that should have been protected.

Here’s a session token used by Damn Vulnerable Web App (https://github.com/digininja/DVWA).

Although the value 1743516676 is a lot of numbers to brute-force sequentially, the value is merely the current timestamp. Recognizing this pattern limits the number of characters that will need to be modified to find a valid session token.

Simple Obfuscation

Tokens may also be obfuscated using various encodings. Attempt to decode tokens using a variety of schemes to identify valid, readable data within the token.

Take for instance the following token.

MDE0NTIzfGFhcm9ufHRydXN0ZWRzZWN8MXww

This value may not have an immediately obvious pattern, but is merely the first example token Base64 encoded. The Burp Suite tool Decoder can convert between different encoding schemes, and leveraging the tool as a part of diligent session management testing can help identify simple obfuscation like this.

Statistical Analysis

The randomness of the session token should be explicitly assessed and can be done with Burp Suite‘s Sequencer tool. Port Swigger has additional information and usage guidance here: https://portswigger.net/burp/documentation/desktop/tools/sequencer. Sequencer performs several types of statistical analysis, comparing many session tokens together to identify patterns in character occurrence.

Using OWASP WebGoat (https://github.com/WebGoat/WebGoat), we can see how Sequencer can help. There is a session hijacking lesson there that issues a hijack_cookie with a value that initially looks sufficiently random.

hijack_cookie=5995535169708608726-1743185440912;

The portion at the end is a timestamp, a pattern that’s already been discussed. However,Sequencer can shed further light on the enigmatic string of numbers. Right-click the request and send it to Sequencer.

Select the cookie you’d like some analysis of and start a live capture.

The overall result will provide a high-level and human readable result. In the case of the WebGoat token, this is that the “overall quality of randomness within the sample is estimated to be: extremely poor”. The additional data presented in the analysis charts help point towards the specific flaw.

This character-level analysis narrows down the issue. The green lines are character positions that have changed, and the red lines are character positions that did not change. This means that to forge a token and compromise an account, testing can focus on a subset of characters until the scheme is fully understood and exploited.

Character Modification Testing

Some characters in the session token may not be used by the application to track session state. Identifying any characters that are not required can simplify session management testing and may make some attacks, like brute-forcing sessions more feasible.

A tool that can shed light on the makeup and construction of session tokens is the character frobber payload type in Intruder. With the session token as the insertion point, character frobber will increment the ASCII value of each character by one before sending the request.

Notice how the characters have been modified one by one and the status code for each. The base request (with a valid token) is a 200 OK, but every other request is a 302 (redirecting to login). This indicates that no modifications resulted in a successful request.

This testing may not often return interesting results, but when it does, the issue is likely to have security implications. A simple example of where this works is when a token appears long and complex, but only a few characters are meaningful, with the rest being unvalidated padding. With this information, brute-forcing session tokens may be much more feasible.

Another example is an application that implements a custom in-house encoding scheme that can be mapped to identify which characters correspond to hidden access control attributes. If an ‘F’ in the middle of the token represents an admin role, and an ‘P’ represents a normal user, the requests in character frobber results will both be 200 OK. Further investigation will be required, but this test quickly provides information that would be difficult to get otherwise.

A similar payload type is bit fipper, which modifies bit positions instead of ASCII codes, and can grant more fine-grained control. Character frobber and bit flipper can be read about here: https://portswigger.net/burp/documentation/desktop/tools/intruder/configure-attack/payload-types.

Destruction

Sessions should not be permanent, and destroying sessions on the server-side under appropriate conditions is a critical component of session management and yet is often improperly implemented.

Idle Timeout

Automatic session destruction happens through timeouts. The first timeout is the idle timeout which should be triggered by the application when no activity is associated with a session within a certain timeframe. This limits the time an attacker has to forge a valid token.

To test idle timeout, capture a sensitive request in a tool like Repeater. Leave the application for a period appropriate for the application, a lunch break being a good opportunity. After this period, resend the sensitive request. If the request successfully returns sensitive data, an idle timeout is not implemented or is too long.

The length of the idle timeframes should look to balance security with usability, as well as reflect the criticality of the data, access, or functionality the applications steward. Based on OWASP recommendations, idle timeout windows should be:

• 2-5 minutes for critical applications and data
• 15-30 minutes for less sensitive applications and data

Absolute Timeout

Absolute timeouts, on the other hand, happen after a defined period regardless of activity. This helps prevent extended or indefinite access if a token is compromised.

To test absolute timeout, capture a sensitive request in a tool like Repeater. Leave the application for a period appropriate for the application, overnight being a good timeframe. After this period, resend the sensitive request. If the request successfully returns sensitive data, an absolute timeout is not implemented or is too long.

Determining the appropriate values will require some discretion and understanding of the business context the application operates within and should conform to how long users are expected to use the application. Based on OWASP recommendations, absolute timeout windows should be:

• 4-8 hours regardless of activity

Destroyed on Logout

Manual session destruction happens primarily through logout functionality. A user’s session should be destroyed when they are done using it as an explicit revocation of the token, preventing attackers from maintaining access to the application should they compromise a token.

Capture a sensitive request in a tool like Repeater. Log out of the application, then resend the sensitive request. If you get data back, that session was not destroyed on logout.

This is also a test to confirm the sessions are being destroyed on the server-side, not simply overwriting cookies with blank values in the client browser, such as Set-Cookie: session=’’. Client-side handling of session destruction will allow attackers to continue to use a compromised token because the server still considers it valid.

Remains Destroyed on Subsequent Login

Also, check if old sessions that were deactivated are reactivated when the user logs back in. Sometimes session tokens are stored in the database but marked as inactive, only to be reinvigorated when that user logs in again. In this case, an attacker that can compromise a session token merely has to wait for a victim to login again to gain access to the application.

Ensure a token that became invalid through logout or timeout remains invalid when the same user logs into the application again. To do so, find a sensitive request, capturing it in a tool like Repeater. Log out of the application and confirm the request now fails, returning an unauthorized response. Log back into the application and send the request with the prior token again.

If the request, which previously failed, is now successful, the session may have been reactivated, creating an opportunity for an attacker with a captured token to gain access to the application again.

Fixation

Applications will sometimes set a session token in a cookie when a user first visits the site, even before authentication. During the login process, if the application accepts the session token passed in during authentication and uses that value to create the user’s session, that creates an opportunity for session fixation attacks. 

This behavior is a security concern because if an attacker can get a known value set in the right cookie in a victim’s browser, the attacker will just have to wait until the victim authenticates. Then the attacker will also have authenticated access because they know the session token.

Damn Vulnerable Web App is vulnerable to session fixation and this demonstration is based on that application.

To test, visit the target application and find an unauthenticated cookie being set. Next, login and see if that same session token carries over into the authenticated session. A way to make the issue more obvious is to set the cookie value to something it would not otherwise be, such as TrustedSecCookie.

This login request submits a valid username and password, as well as a PHPSESSID session cookie. The application then sets that cookie again with the same value in the response, but on the backend, that cookie value is now associated with a valid user session.

Authenticated access to the application is now possible with a known value as a session token. An attacker that can introduce a known value to a victim’s browser through methods including physical access or cross-site scripting will be able to access the application once the victim authenticates.

Session Puzzling

If an application begins populating a user’s session with meaningful information before the user fully authenticates, there may be an opportunity to attack the session management process through session puzzling. The flaw is a session token that is created for a user in an unauthenticated state that is also valid for authenticated functionality.

A simple example is a Forgot Password page that takes user input to begin that password recovery process. Once a username is submitted, an email or other form of authentication is sent, but what is significant is a session cookie was set and a back-end session was also created with that username as an attribute.

Pause this password reset process (The idea is you are attacking a victim whose email you don’t have access to, so you couldn’t complete the process anyway) and attempt to access sensitive functionality with the token that was issued when the username was submitted.

Password reset functionality is one method but consider where else the application allows user information to be submitted prior to authentication. Test from an unauthenticated state to see if any tokens issued based on this user data can then be used to perform actions on behalf of that user. For instance, make updates to their profile.

OWASP provides further information on session puzzling and how to test for it. The session can be found here.

Token Disclosure

Session tokens may be used or passed in locations other than the cookie itself, and sometimes these processes present new security concerns. Searching for the token value to determine if it appears elsewhere can quickly identify potential disclosure of session tokens.

Do a global search for the token value. Sometimes they appear in unexpected places. Is the value recorded somewhere it shouldn’t be, like in a URL query string or in a filename? The query string is the portion of the URL after the ‘?’, such as https://trustedsec.com?userSession=MDE0NTIzfGFhcm9ufHRydXN0ZWRzZWN8MXww. Sensitive data should not be included in query strings like that because those query strings are recorded in a variety of places like web server, proxy, and application logs, as well as browser histories. These locations likely do not have stringent security measures and may provide malicious actors opportunity to compromise session tokens.

There are likely to be other locations besides filenames where sensitive tokens are recorded in insecure ways. If such tokens turn up in places they shouldn’t be, consider how an attacker could plausibly exploit the issue.

Configuration

Sensitive data such as session tokens passed in cookies should have some baseline security attributes applied. These attributes can protect cookies from common attacks like cross-site scripting, cross-site request forgery, and eavesdropping.

When a cookie is set, the attributes for that cookie are set along with it following the cookie value. As an example, a response header responsible for setting a cookie may look like the following.

Set-Cookie: session=MDE0NTIzfGFhcm9ufHRydXN0ZWRzZWN8MXww; expires=Mon, 28 Apr 2025 10:02:37 GMT; Max-Age=86400; path=/; domain=application.io; HttpOnly; Secure; SameSite=Lax

Find the session token being set in the response and identify what, if any security attributes are set. In a request-response context the cookies will appear similar to the following.

Security attributes can also be viewed in the browser’s storage as well.

Secure prevents the cookie from being sent over unencrypted HTTP where it could get stolen by an attacker with a suitable network position capable of intercepting traffic. Find more details about the secure attribute here.

HttpOnly prevents JavaScript from accessing the cookie value, protecting against session tokens being stolen through cross-site scripting. If an application needs to read details stored in the cookie with JavaScript, a different method of getting that data should be implemented. Find more details about HttpOnly here.

There are a few other security attributes set on cookies that are worth knowing about, but whether their configuration is flawed may be situationally dependent.

Domain and Path determine where cookies are sent. Without the Domain attribute, the cookie will only be sent to the domain that set it, but setting the Domain attribute will allow the cookie to be sent to subdomains as well, which is less restrictive than if it was absent. The Path attribute restricts the cookie to specific URL paths, which is useful if multiple applications are under a single URL. Find more details about where cookies are sent here.

SameSite informs the browser when cookies should be sent in cross-site requests. This attribute can be set to one of several values.

• Strict – Cookies will not be sent in cross-site requests
• Lax – Cookies are sent when a user navigates to the origin site by following a link as well as fetching sub resources like images, iframes, and scripts. The POST, PUT, and DELETE methods do not send the cookie.
• None – Cookies will be sent in cross-site requests

If no value is sent, many browsers will treat the cookie as having the SameSite=Lax attribute. Find more details about controlling third-party cookies with SameSite here.

In each case, determine what attributes are appropriate for the application to be tested.

Token Exchange Processes

The coolest and most impactful session management bugs are often related to some sort of token exchange process. Careful consideration should be given to that exchange process any time a user is authenticated across multiple systems or environments that use their own session management schemes. If something is going to go wrong, there is a decent chance this is where it will be. 

This seems particularly true in environments where several legacy systems or APIs are tied together with a newer identity and access management system or front end, and an in-house solution was developed in the environment to handle it.

This may also happen when OAuth parameters are coopted, or custom parameters are used while exchanging the session token from App A for a token for App B. When combined with user enumeration somewhere, this has resulted in arbitrary account compromise. Implementation errors like that are easy to make when treading an uncharted or bespoke development path.

JWTs will be discussed in a separate post, but opaque tokens that are exchanged for a JWT may give some insight into the token contents or construction. This is because JWTs can be decoded to review the claims and user information inside. If this could be combined with some other issue like cryptographically sound yet predictable or static tokens, forging arbitrary sessions could be possible.

All this is to say the token exchange process is going to be highly dependent on the specific environment but should send up red flags because these situations may offer significant opportunity.

Conclusion

Session management is a critical component of application security. Because it can be complex, errors can be made in its implementation. Testing for flaws in these systems is often equally complex. Despite how dry session management testing may seem at first, understanding how it functions can yield high rewards.

Most of this session management testing methodology is based on OWASP’s cheat sheet as well as my own experience testing applications. The OWASP cheat sheet is more academic and less referenceable in my opinion, but it should be read and understood by anyone looking to get a good grasp on the topic. Find more details about the OWASP cheat sheet here.

Happy hunting and Godspeed!