Session Management in HTTP: How does it work?

Session management in HTTP is achieved by maintaining a mapping of session IDs to session state information on the server and by sending a cookie containing the session ID to the client when the session is first established.

What is session management, and why is it important?

Session management is used to facilitate secure interactions between a user and some service or application and applies to a sequence of requests and responses associated with that particular user. When a user has an ongoing session with a web application, they are submitting requests within their session and oftentimes are providing potentially sensitive information. The application may retain this information and/or track the status of the user during the session across multiple requests. More importantly, it is critical that the application has a means of protecting private data belonging to each unique user, especially within authenticated sessions.

Session tokens serve to identify a user’s session within the HTTP traffic being exchanged between the application and all of its users. HTTP traffic on its own is stateless, meaning each request is processed independently, even if they are related to the same session. Thus, session management is crucial for directing these web interactions and these tokens are vital as they’re passed back and forth between the user and the web application. Each request and response made will have an associated session token which allows the application to remember distinct information about the client using it. Session cookies were designed to help manage sessions, however, there are several properties of the cookie that must be configured and implemented correctly to prevent potential compromises.

It should be noted that cookies are not the only means of carrying out a session. It is also possible to include headers that contain session tokens. Moreover, while session tokens can be embedded within a URL, this should not be implemented as URLs are often logged in various places and cached, increasing the likelihood of disclosure.

What are the vulnerabilities introduced by a lack of session management?

Enforcing correct session management often boils down to the protection and security of the session keys. There is a plethora of vulnerabilities introduced with insecure session cookies, which can be leveraged by an attacker to take advantage of an authenticated user session. Adversaries can take measures to brute force, predict, and expose session tokens which ultimately can lead to session hijacking, where the malicious party can then impersonate the victim and perform actions from their account.

Session fixation can also take place if the properties of a session token allows an attacker to fixate the token of the user once authenticated. It can then also be used to hijack the session. Alternatively, this issue may arise if the application fails to check for consistent user information throughout the session, reuses session tokens across all forms of access to the service, and sets cookies without proper validity periods.

Once a user’s session is hijacked, an adversary now has the opportunity to make changes permitted to the victim from their account and perform actions that could be dangerous as well as administrative tasks such as adding/removing users, assigning privileges, etc. The more privileges the victim has within the service, the more severe the attack can be.

Best practices: implementing session management

1. Set Secure/HttpOnly Flags on your Cookies

   Refrain from sending sensitive traffic and tokens over an unencrypted channel (HTTP). This can be enforced by setting the Secure flag, which ensures that data will only be transported over HTTPS. The HttpOnly flag should also be set for session cookies as this will prevent client-side JavaScript from accessing it, which could result in session hijacking.

2. Generate New Session Cookies

   New session tokens should be generated at every stage of a session: as soon as a user visits the application, when they provide correct credentials, and when a user logs out of their account. A cookie should also expire if the account is inactive for a long period of time and force the user to re-authenticate. This also applies to changes in state, meaning the cookie should automatically be destroyed when the session changes from anonymous to authenticated or vice versa.

3. Configure Session Cookies Properly

   Session tokens should be long, unpredictable, and unique. These properties can help to ensure that an attacker cannot guess or brute force the value of the token. The expiration on persistent cookies should be set for no longer than 30 minutes, which prevents session fixation and further hijacking. This can be achieved by modifying the Expire and Max-Age attributes. If no value is specified for the Expire or Max-Age attributes, the cookie does not persist in the user’s browser and is removed when the tab or browser is closed. This is commonly used for session cookies. It is also recommended that the scope of domains that are able to access the session cookie is limited and restrictive. This is controlled by the Domain and Path attributes.

How can Packetlabs help?

At Packetlabs, our Web Application Testing methodology includes extensive testing of the session management mechanisms you have in place for your application. Both automated and manual testing methods are used to validate that proper implementation and management of session tokens are enforced to mitigate the potential for compromise of your users and solidify their trust in your application. Book a meeting with us to learn more.