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.