What is Session Hijacking?
Share
Session hijacking is a cyberattack where adversaries impersonate an authenticated user after stealing their session ID. Apart from credential theft, session hijacking is one of the most common ways in which attackers exploit poor authentication practices to steal money, data, and identities.
Session hijacking is a man-in-the-middle (MITM) attack that can happen at both the application layer (Layer 7) as well as the network layer (Layer 3). This article will focus on session hijacking at the application layer.
What is a session?
To understand session hijacking, it’s important to know the basics of session management.
Since HTTP is a stateless protocol, there is no connection between a request and other requests that were executed previously. Theoretically, this means a user would have to authenticate for every action they take on a particular application. Entering usernames and passwords for every button click or web page view is not fun for anyone. This is why sessions are needed.
A session is a sequence of interactions between two devices, usually a client and a server, that happen over a single connection. When a user logs into an application, a new session is created and a session ID is assigned. The session is usually active until the user logs out of the application, although some apps end the session after a period of user inactivity. Sessions keep track of any user-specific parameters that are needed to ensure a good app experience. When a session is destroyed, all associated user data is deleted from the allocated memory space.
A session ID is a long alphanumeric string that is continually transmitted between the server and the client. They are often stored in session cookies, URLs, and hidden forms on the website. This is why session hijacking is also called cookie hijacking or cookie side-jacking.
How session hijacking works
In session hijacking, an attacker gets hold of a valid user session to gain unauthorized access to the account. This is commonly done through three methods:
Brute force: The attacker keeps trying session IDs until they are successful.
Calculation: If the session IDs are generated in a non-random manner, the attacker can calculate them.
Theft: The attacker acquires the session ID through techniques like session sniffing, session fixation, and cross-site scripting.
A session ID for an authenticated session is considered a very strong authentication method. This means attackers getting a user’s session ID is as bad as attackers getting a user’s login credentials.
An attacker with a stolen session ID has the same level of access to resources and functionalities as a legitimate authenticated user. Session hijacking can lead to:
Identity theft and account takeover
Fraudulent banking transactions and purchases
Exfiltration of the user’s personal information or their company’s sensitive data
Also read: Broken Authentication 101
Common session hijacking methods
Here are some common ways in which session hijacking attacks are carried out:
Session sniffing
Session sniffing, also known as session side jacking, involves attackers using a sniffer like Wireshark to inspect network traffic and extract the session key. Session sniffing is particularly effective on unencrypted networks like public Wi-Fi.
Applications that don’t use SSL/TLS encryption – or use it selectively – are also vulnerable to session side jacking attempts. For example, if the login page uses SSL/TLS encryption, attackers can’t view a user’s password. But if the rest of the application does not use SSL/TLS encryption, session hijacking can still occur.
Cross-site scripting (XSS)
In cross-site scripting, attackers exploit web application or server vulnerabilities by injecting malicious scripts from the user’s device. This is commonly done by sending users emails with script-injected links. The user will click the link because it points to a known, trusted website. But when they click the link, the injected script will execute.
If the code copies the user’s active session cookies and sends them to a server controlled by the attacker, they can hijack the user’s session.
Session fixation
In session fixation, attackers take over user accounts by setting their session ID to a string known by the attackers. Websites that accept session IDs within URLs and do not perform security validation on them are particularly prone to session fixation attacks.
In practice, session fixation starts by attackers sending users a URL that contains a session ID, usually in a phishing email. When the user clicks the link and logs into the application, the attacker knows the valid session ID and can remotely hijack the session.
Session hijacking prevention tips
Here are some security measures organizations can take to prevent session hijacking attacks:
Keep an eye on session lengths
Different applications will have different levels of tolerance to long session lengths. A streaming or social media app might keep users logged in for weeks, while a banking or healthcare app might log users out after a few minutes of inactivity due to the increased risk of session hijacking.
Developers should ensure that session lengths align with the level of sensitivity of the application.
Change session IDs after login
Applications should issue a new session identifier after login is complete. This prevents session fixation because the session ID provided by the attacker will not persist after the user logs in. Any session-related tokens should be immediately invalidated when the session ends to prevent attackers from reusing them.
Don’t put session IDs in URLs
Another way to prevent session fixation is to not accept session IDs in URLs. More broadly, session IDs should not be accepted from any GET or POST variable.
Use HTTPS
It’s important to use HTTPS on the entire application or website, not just the login page. Using HTTPS everywhere encrypts all traffic and prevents attackers from sniffing for session IDs.
Set session ID cookies to HttpOnly
Session ID cookies should be flagged as HttpOnly to prevent client-side Javascript from accessing any session details. This reduces the likelihood of cross-site scripting attacks.
