What is session prediction?
In a session prediction attack, the attacker attempts to guess an active session ID for a web application. This could be done by performing a brute force attack or deciphering, guessing, or reverse engineering the algorithm used to create session IDs.
How do session identifiers work?
Session identifiers (SIDs), sometimes called session keys or session tokens, are character strings used for user authentication in web applications. These strings are generated by the application after the user successfully logs in, presented to the user’s browser, and used across different web pages or functions of the application, usually via a session cookie. Since the web browser shares the session cookie with the application in every HTTP request, the application can use the session identifier to recognize a known user.
If it weren’t for session identifiers, we would have to log in to web applications much more frequently than we do. However, a session identifier has the same weakness as a password: it is only secure while it is secret. As soon as a malicious user knows your session ID, they can get access to your account and use it for further attacks and potential privilege escalation.
What attacks are related to session identifiers?
In general, malicious hackers will try to get access to session identifiers to impersonate users and gain access to their accounts/privileges. There are several specific attack techniques targeting sessions:
- Session hijacking is all about getting an existing session ID from a logged-in user, for example, using man-in-the-middle (MITM) techniques to infiltrate communication between the victim’s browser and the web server.
- Session fixation uses a different approach to obtain a valid ID. In a session fixation attack, the victim receives an existing session ID and is tricked into logging in using this identifier, allowing the attacker to take over the user’s session later.
- Session prediction exploits weaknesses in the way session IDs are generated. If the process is not fully random and the attacker figures out the algorithm, they can generate valid session IDs. If the session identifiers are short enough, attackers could even use brute force attacks to guess a valid identifier.
How do session prediction attacks happen?
There are two primary types of session prediction attacks:
- Brute force attacks – attempting to randomly guess the session ID. For this to be possible, valid session IDs must be short, and the web application cannot limit the number of connection attempts.
- Deciphering the algorithm – guessing or figuring out how the original developer designed the web application to generate session IDs. This could mean working out what hash or encoding algorithm is used (if any), whether the session ID is based on time/date, username, or other predictable data, and so on.
The first step of a session prediction attack is always gathering a (preferably) large number of current session IDs to create an initial dataset. The more IDs are available, the more certain the attacker can be about the structure and length of the session ID, increasing the chances of successful prediction.
Keep in mind that with the current developments in data mining, machine learning, deep learning, neural networks, and predictive models, attackers may well employ any or all of these techniques and methodologies to help them with deciphering existing session IDs and forecasting future session IDs.
How to detect session prediction vulnerabilities?
Session prediction is not a specific type of vulnerability like SQL injection or cross-site scripting. The application may be vulnerable to session prediction attacks due to bad practices with session ID generation.
Session prediction vulnerabilities, like using predictable bases or easily decipherable algorithms, are similar to logical vulnerabilities and impossible to detect automatically. Because automatic vulnerability scanning is not able to detect such issues, you need manual penetration testing and security-focused code reviews to catch them.
How to prevent session prediction attacks?
There are several ways to prevent session fixation attacks through secure coding techniques:
- If you can, use dedicated and secure mechanisms to generate new session IDs. Most development frameworks offer features that let you generate non-predictable, safe, long session IDs, for example, JdkIdGenerator in Spring. Whenever they are available, it’s always better to use ready session management mechanisms in frameworks instead of trying to generate IDs yourself.
- If you must generate IDs yourself, perhaps because you’re working on a platform with no suitable framework functions, generate IDs that are very long and based on data from cryptographically secure pseudo-random number generators (CSPRNG). If you’re combining randomness with non-random data such as timestamps and user IDs to avoid collisions, make sure to use strong and non-reversible hash algorithms.
Frequently asked questions
What are session prediction attacks?
Session prediction is a type of attack where the attacker attempts to guess an active session ID for a web application. This could be done by performing a brute force attack or deciphering/guessing the algorithm used to create session IDs.
How dangerous are session prediction attacks?
If a session prediction attack is successful, the attacker can gain access to the user’s account in the web application. The consequences are similar to other session attacks, such as session hijacking. The potential damage depends entirely on the functionality of the web application and the privileges of the user, so accessing an administrator account for a major web application may expose large amounts of highly sensitive information.
How to prevent session prediction attacks?
The only way to prevent session prediction attacks is to follow best cybersecurity practices for developing web-based applications. Whenever possible, you should use dedicated, secure mechanisms to generate new session IDs. Most development frameworks include functions for generating non-predictable, safe, long session IDs. It’s always better to use ready session management mechanisms in frameworks instead of trying to generate IDs yourself.