Handling Session Management in Web Applications

Back in 1893, the Lizzie Borden murders, where the Massachusetts woman was accused of killing both her parents with an ax, captivated the public and news media. Eventually found not guilty, one fundamental question perplexed police officers and the jury. Every door inside the Borden house had its own lock and corresponding key, an attempt to prevent the different family members from entering each others’ rooms without permission.

While weird and seemingly unrelated to session management, this story gives you a little insight into why session management makes it easier for your users to interact with your application. If every single click or tap through your application meant the user needed to resubmit their credentials, the result would be incredibly time-consuming and burdensome. Sessions and session management enable you to track authenticated users as they move throughout your application’s modules.

Since handling session management in web applications is critical to security, you should understand the best practices for generating secure session IDs to mitigate the risks of session hijacking attacks.

What are sessions?

Applications use sessions to track users after the first login, giving them a way to move through the different modules without having to resubmit credentials for every new interaction. Every time the user interacts with the application, like clicking on a button, they initiate a new request to the application server. If every new request required people to input their username and password, the process would be time-consuming. Sessions track the communication between the user’s web browser and the application’s server so the application can identify and track the user.

Some examples of how sessions make user interactions easier include:

E-Commerce: Letting people store items in a shopping cart instead of forcing them to make individual purchases
Video games: Allowing players to pause a game without saving and still return to the same spot
Financial services: Keeping account information available when someone swaps between different applications on a mobile device

What is Session Management?

Session management is the process of

Identifying user at login
Creating, storing, and organizing temporary data about the user
Preserving their ID and access as they navigate the application
Removing the temporary data when the user logs out or the application automatically logs them out

The three elements of session management are:

Creating Session ID: The application generates unique digital information about the user when they log in either as a cookie or token.

Storing session data: While the application server stores a token, the user’s browser stores the cookie.

Session expiration date: While users can control how long a cookie remains valid, the application can define how long the token is effective.

As more organizations deploy single-page applications for better user experiences, session management becomes more nuanced. In these applications, storing tokens becomes a challenge since local storage creates security risks. Meanwhile, developers need to take extra precautions with cookies, ensuring that they code the appropriate attributes to protect the cookie’s data from client-side scripts accessing it.

Session Hijacking Attacks: What Happens When Session Management Goes Awry

Cookies and tokens contain sensitive information that authenticate the user to the application, like the username or password. If malicious actors obtain this information, they can take over a user’s session or “hijack” it. Session hijacking attacks fall into three basic categories:

Active session hijacking: active session takeover where attacker acts as legitimate users to control communications between client and server
Passive session hijacking: monitoring communications between client and server to listen to and record data for future use
Hybrid hijacking: Monitoring network traffic to identify a vulnerability so they can control the session and complete objectives

Best Practices for Handling Session ID Properties

As a developer, you want to take steps to prevent attackers from compromising communications between intended users and your application. By understanding best practices for managing session ID properties, you can implement basic security controls and then use a session management cheat sheet to help secure your session management implementation.

Session ID Name Fingerprinting

Your session ID should be as vague as possible, limiting the amount of details about the ID’s purpose and meaning. Attackers can easily identify session IDs when you’re using a common application development framework, so you should change the default session ID name. Some examples of easily fingerprintable IDs include:

PHP: PHPSESSID
J2EE: JSESSIONID
ColdFusion: CFID, CFTOKEN
ASP.NET: ASP.NET_SessionId

Session ID Length

To reduce brute force attack risk, your session ID must be at least 128 bits (16 bytes).

Session ID Entropy

You need to create session IDs that attackers can’t guess or reverse engineer. To create session IDs that are random enough, your session IDs should:

Be created using a Cryptographically Secure Pseudorandom Number Generator (CSPNG)
Provide at least 64 bits of entropy
Be unique from all other session IDs, including others in the current session ID space

Session ID Content or Value

A session ID should never include personally identifiable data or sensitive information that attackers can use to learn about the user, session, or application business logic. The session ID should be a client-side identifier, with any additional information stored on the server side.

Data that should never be in the client-side session ID include:

Client IP address
User-Agent
Email address
Username
User ID
Role
Privilege level
Access rights
Language preferences
Account ID
Current state
Last login
Session timeouts

Scan for Session Injection Vulnerabilities with Qwiet AI

With Qwiet AI, you can create a build rules file to compare your analysis against your defined rules. With our platform, you can set parameters for the types of vulnerabilities you want to filter, including Session Injection, to review your build for issues that attackers can use to engage in session hijacking attacks. Further, our list of possible OWASP category values include a1-injection, a7-cross-site-scripting, a7-xss, and a03-2021-injection to help you identify issues in your source code, enabling you to push out secure applications faster.

About ShiftLeft

ShiftLeft empowers developers and AppSec teams to dramatically reduce risk by quickly finding and fixing the vulnerabilities most likely to reach their applications and ignoring reported vulnerabilities that pose little risk. Industry-leading accuracy allows developers to focus on security fixes that matter and improve code velocity while enabling AppSec engineers to shift security left.

A unified code security platform, ShiftLeft CORE scans for attack context across custom code, APIs, OSS, containers, internal microservices, and first-party business logic by combining results of the company’s and Intelligent Software Composition Analysis (SCA). Using its unique graph database that combines code attributes and analyzes actual attack paths based on real application architecture, ShiftLeft then provides detailed guidance on risk remediation within existing development workflows and tooling. Teams that use ShiftLeft ship more secure code, faster. Backed by SYN Ventures, Bain Capital Ventures, Blackstone, Mayfield, Thomvest Ventures, and SineWave Ventures, ShiftLeft is based in Santa Clara, California. For information, visit: www.shiftleft.io.