Note: This article has been created in light of the OWASP standards and descriptions.
Introduction
OWASP defines Session Management as follows:
One of the core components of any web-based application or stateful API is the mechanism by which it controls and maintains the state for a user or device interacting with it. Session management changes a stateless protocol to stateful, which is critical for differentiating different users or devices.
To ensure that a verified application satisfies the following high-level session management requirements:
- Sessions are unique to each individual and cannot be guessed or shared.
- Sessions are invalidated when no longer required and timed out during periods of inactivity.
Cookies
In order to secure cookie data, the industry has developed means to help lock down these cookies and limit their attack surface. Over time cookies have become a preferred storage mechanism for web applications, as they allow great flexibility in use and protection.
Here's a list of cookie attributes and their definitions have been given: Secure: The Secure attribute tells the browser to only send the cookie if the request is being sent over a secure channel such as HTTPS. This will help protect the cookie from being passed in unencrypted requests.
HttpOnly: The HttpOnly attribute is used to help prevent attacks such as session leakage since it does not allow the cookie to be accessed via a client-side script such as JavaScript.
Domain: The Domain attribute is used to compare the cookie's domain against the domain of the server for which the HTTP request is being made. If the domain matches or if it is a subdomain, then the path attribute will be checked next.
Path: The Path attribute plays a major role in setting the scope of the cookies in conjunction with the domain. In addition to the domain, the URL path that the cookie is valid for can be specified. If the domain and path match, then the cookie will be sent in the request. Just as with the domain attribute, if the path attribute is set too loosely, then it could leave the application vulnerable to attacks by other applications on the same server.
Expires: The Expires attribute is used to set persistent cookies, limit lifespan if a session lives for too long, and remove a cookie forcefully by setting it to a past date.
SameSite: The SameSite attribute is used to assert that a cookie ought not to be sent along with cross-site requests. This feature allows the server to mitigate the risk of cross-origin information leakage. In some cases, it is used too as a risk reduction (or defense in depth mechanism) strategy to prevent cross-site request forgery attacks.
OWASP ASVS Methodologies for Session Management Testing
1. Testing for Session Fixation
Session fixation is enabled by the insecure practice of preserving the same value of the session cookies before and after authentication. This typically happens when session cookies are used to store state information even before login, e.g., to add items to a shopping cart before authenticating for payment.
How to Test:
To test for Session Fixation for Concurrent Sessions: Login as userA and observe sessionID for that user. Logout and then login as UserB and observe sessionID for that user. Observe that the same sessionID is used for the next user.
To test for Session Fixation for the Same Account: Login as userA and observe sessionID for that user. Logout and then login as UserA again and observe sessionID didn't change.
Vulnerabilities:
- Session Fixation for Concurrent Sessions.
- Session Fixation for the Same Account.
Remediation:
Implement a session token renewal after a user successfully authenticates.
The application should always first invalidate the existing session ID before authenticating a user, and if the authentication is successful, provide another session ID.
2. Testing for Logout Functionality
Session termination is an important part of the session lifecycle. Reducing to a minimum the lifetime of the session tokens decreases the likelihood of a successful session hijacking attack. This can be seen as a control against preventing other attacks like Cross-Site Scripting and Cross-Site Request Forgery. Such attacks have been known to rely on a user having an authenticated session present. Not having a secure session termination only increases the attack surface for any of these attacks.
How to Test:
To test if the Old Session does not invalidate after logout:
- Login as UserA.
- Intercept one of the authenticated requests and send it to the Burp repeater.
- Logout.
- Send the intercepted request in Burp Repeater again and observe the session is not validated.
Vulnerabilities:
- The Old Session does not invalidate after logout.
Remediation:
No data that should be visible only by authenticated users should be visible on the examined pages while performing the tests. Ideally, the application redirects to a public area or a Login form while accessing authenticated areas after termination of the session. It should be not necessary for the security of the application, but setting session cookies to new values after log out is generally considered a good practice.
3. Testing for Exposed Session Variables
The Session Tokens (Cookie, SessionID, Hidden Field), if exposed, will usually enable an attacker to impersonate a victim and access the application illegitimately. It is important that they are protected from eavesdropping at all times, particularly whilst in transit between the client browser and the application servers.
How to Test:
To test if the token is carried over URL via the GET method:
- Login to the application.
- Intercept all the request with Burp.
- Observe that the token is sent via URL in GET request.
- This might help an attacker to compromise the user session easily.
To test if the token is sent over HTTP
- Intercept the requests.
- Observe that the token is sent over HTTP.
Vulnerabilities:
- The token is sent over the URL (GET method).
- The token is sent over HTTP.
Remediation:
- Ensure that proper encryption is implemented.
- Review the caching configuration.
- Assess the channel and methods' security.
4. Testing Session Timeout
In this phase testers check that the application automatically logs out a user when that user has been idle for a certain amount of time, ensuring that it is not possible to "reuse" the same session and that no sensitive data remains stored in the browser cache.
How to Test:
- Login with your username and leave the browser tab open for a long time.
- Observe that session is not terminated.
Vulnerabilities:
- Session Timeout is too long.
Remediation:
The server should perform proper checks on the session state, disallowing an attacker to replay previously destroyed session identifiers.
5. Testing for Session Management Schema
One of the core components of any web-based application is the mechanism by which it controls and maintains the state for a user interacting with it. To avoid continuous authentication for each page of a website or service, web applications implement various mechanisms to store and validate credentials for a pre-determined timespan. These mechanisms are known as Session Management.
How to Test:
- Perform a standard request on the application.
- Observe session token can be decrypted or guessable or brute forceable
If not, follow the next steps:
- Gather session tokens, for the same user and for different users where possible.
- Analyze and ensure that enough randomness exists to stop session forging attacks.
- Modify cookies that are not signed and contain information that can be manipulated.
Vulnerabilities:
- Session token predictable/low entropy.
- Session cookie manipulation.
Remediation:
Unpredictability: a cookie must contain some amount of hard-to-guess data. The harder it is to forge a valid cookie, the harder is to break into a legitimate user's session. If an attacker can guess the cookie used in an active session of a legitimate user, they will be able to fully impersonate that user (session hijacking). In order to make a cookie unpredictable, random values or cryptography can be used.
Tamper resistance: a cookie must resist malicious attempts of modification. If a cookie attribute is something similar to isAdmin=No, it is trivial to modify it to get administrative rights, unless the application performs a double check (for instance, appending to the cookie an encrypted hash of its value).
Expiration: a critical cookie must be valid only for an appropriate period of time and must be deleted from the disk or memory afterward to avoid the risk of being replayed. This does not apply to cookies that store non-critical data that needs to be remembered across sessions (e.g., site look-and-feel).
Secure flag: a cookie whose value is critical for the integrity of the session should have this flag enabled in order to allow its transmission only in an encrypted channel to deter eavesdropping.
If you're looking for a more detailed walk-through on Session Management, check out my latest video:
References:
Please refer to the Cobalt Pentest Wiki and OWASP standard for more information:
- Vulnerability Wiki
- https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/01-Testing_for_Session_Management_Schema
- https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/README.html
If you liked this blog, check out Busra's previous posts like A Pentester's Guide to HTTP Request Smuggling and her video walk-throughs here: Hacking How-To series
