What is Session Hijacking and How Does it Work?

Session hijacking (aka cookie hijacking or cookie side-jacking) is a cyber-attack in which attackers take over a legitimate user’s computer session to obtain their session ID and then act as that user on any number of network services. This type of attack is hazardous to application security because it allows attackers to gain unauthorized access to protected accounts (and the data housed within them) under the guise of a legitimate user.

This article will explore everything you need to know about session hijacking, including

• What is session hijacking?
• How does session hijacking work?
• What are the types of session hijacking?
• How is session hijacking different from session spoofing?
• What are the risks and consequences of session hijacking?
• What are examples of session hijacking?
• How can you protect against session hijacking?

Every time a user accesses a website or application via an HTTP connection, the service authenticates the user (for example, via a username and password) before opening the line of communication and providing access. However, HTTP connections on their own are “stateless,” meaning that each action a user takes is viewed independently. As a result, if we relied solely on HTTP, users would have to re-authenticate themselves for each action they take or page they view.

Sessions resolve this challenge. A session gets created on the server hosting the website or application once a user logs in and then serves as a reference for the initial authentication. Essentially, users can remain authenticated for as long as a session stays open on the server. Users can end a session by logging out of the service, or some services end a session after a pre-defined period of inactivity.

Most services create these sessions by issuing a session ID, a string of numbers, and letters stored in temporary session cookies, URLs, or hidden fields on the website. In some cases, these session IDs get encrypted, but that’s not always the case. And in many instances, these session IDs are based on predictable information, like a user’s IP address.

Session hijacking occurs when attackers gain unauthorized access to a user’s session ID, which allows them to assume that user’s online identity. In doing so, attackers can pose as legitimate users, gain information, and take actions under the assumed identity.

Session hijacking starts when an attacker gains unauthorized access to a user’s session ID. Attackers typically gain this access by either stealing a user’s session cookie (hence the alternative name of cookie hijacking) or convince the user to click on a malicious link that contains a predicted session ID (more on this below).

Once an attacker has the session ID and the user has logged in to the service, the attacker can then take over the session. They do so by applying the legitimate user’s session ID to their browser, which tricks the service into thinking the attacker is the legitimate user engaging in that same session.

Under this guise, the attacker can then pose as the legitimate user and access any information or take any action that the user is authorized to do. In cases where users have a single sign-on (SSO), the attacker can use this approach to gain unauthorized access to any number of applications, severely compromising application security across the board.

Digging deeper into how exactly session hijacking works reveals numerous ways to conduct this type of attack. The types of session hijacking include:

Cross-site scripting (XSS) is one of the biggest risks and most popular approaches for session hijacking. XSS occurs when the attacker finds vulnerabilities in the target server or application and takes advantage by injecting client-side scripts onto the webpage. The page then loads with this malicious code, but everything looks legitimate on the user’s side because it is still coming from a trusted server. Once the malicious code has loaded, it gives the attacker access to steal the user’s session ID.

The attacker might send a link to a trusted website in an XSS attack but with modified HTTP query parameters. Once the user clicks on this link, the attacker can then gain access to their session ID, or in some cases, the link may even send that information directly to the attacker. In instances like this, attackers will typically use a URL shortener to hide the URL and, therefore, anything suspicious in the link.

Session side-jacking, also known as session sniffing, is a more active type of hijacking attack. In this case, attackers will use packet sniffing like Wireshark or Kismet to monitor network traffic and steal session cookies after authentication. Users are most vulnerable to this type of attack when the server only encrypts the authentication page and not other pages within the session. As a result, attackers can obtain the session ID post-authentication on the unencrypted pages throughout the session.

Importantly, attackers need access to the user’s network to execute this type of attack, which means session side-jacking typically occurs over unsecured WiFi networks or public networks. 

Session fixation occurs when attackers can set a user’s session ID. 

This type of attack requires a vulnerability in the target website that allows session IDs to be set via URLs or forms. In this case, an attacker can set a session ID on behalf of a user and then get the user to log in accordingly by either sending them a phishing URL that contains the session ID or setting that ID within a false login form. 

In either case, the legitimate user logs into a website and authenticates using the session ID fixed by (and therefore known to) the attacker. Once the user has logged in, the attacker can then take on the session ID as well.

Many websites follow a pattern for issuing session IDs, and in some cases, it may be as simple as making it the user’s IP address. In these cases, attackers can monitor the session IDs that get issued to determine the pattern. If they can do so, then they can easily predict what a valid session ID might look like for specific users and generate that session ID to use themselves.

Similarly, a brute force attack can occur if attackers gain access to a setlist of session IDs and try them over and over again until one works. They will typically have such a list if the pattern for generating IDs is predictable. The difference, in this case, is that they may not be able to predict the ID for a specific user, so they will need to try different IDs from the list until they find a match.

A man in the browser attack, also known as a man in the middle or malware attack, first requires attackers to infect a user’s computer with malware. 

Once the malware gets installed and a user logs in to a website, the attacker can then act as a man in the middle and intercept information, modify the actions a user takes onsite or take additional actions posing as that user — all without the user’s knowledge. Because this type of attack originates from the legitimate user’s actual device, it can be very difficult to detect any violations of application security in these types of attacks.

With this type of access to a user’s device, attackers can also go straight to the user’s temporary local storage folder on the browser (aka the “cookie jar”) and then grab session IDs for whatever cookies they want.

Session hijacking and session spoofing are similar in many ways, but they are not ultimately the same type of attack. The most significant difference between these two types of attacks is that session hijacking occurs when a legitimate user is logged in to a good web session. In contrast, session spoofing occurs when attackers impersonate a user to launch a new web session (meaning that the user does not have to be logged in at the time).

The biggest manifestation of this difference is the experience for the legitimate user. In the case of session hijacking, an attacker interrupting the session may cause the website or application to behave unusually or even crash for the victim. Meanwhile, because the user isn’t actively logged in during a session spoofing attack, they won’t experience any “side effects” from the next session.

A successful instance of session hijacking gives an attacker the ability to do anything the targeted user can do. This carries significant risk to application security in various ways, most notably when it comes to initiating monetary transactions, accessing protected data or gaining unauthorized access to other systems via SSO.

Some of the most notable risks of session hijacking include:

• Monetary theft: Attackers gain the ability to conduct financial transactions on behalf of the user. This might involve transferring money from a bank account or making purchases with saved payment information.
  
• Identity theft: Attackers gain unauthorized access to sensitive personal information saved in accounts that they can use to steal a victim’s identity beyond the confines of the hacked website/application.
• Data theft: Attackers can steal any kind of sensitive personal or organizational data housed within the application and use that information to harm the victim or organization (e.g., in the case of blackmail) or to pursue their agenda (e.g., in the case of selling protected, potentially competitive information or intellectual property).
  
• Access to additional systems through SSO: Attackers can also gain unauthorized access to additional systems if SSO is enabled, further spreading the potential risk of a session hijacking attack. This risk is particularly important for organizations, many of which now enable SSO for employees. Ultimately, this means that even highly protected systems with stronger authentication protocols and less predictable session cookies, like those that house financial or customer information, may only be as protected as the weakest link in the entire system.

Several high-profile examples illustrate exactly what can occur as a result of a session hijacking attack. Some of the most notable examples include:

When the COVID-19 pandemic hit, the world turned digital, with school, work, and social events taking place over video conferencing applications like Zoom. It didn’t take long until these video conferences became a popular victim for session hijacking, even earning the name “Zoom-bombing.” 

Several notable instances occurred in which attackers engaged in session hijacking to join private video sessions. The most reported instances included those in which the attackers made themselves known by shouting profanities, hateful language, and sharing pornographic images. In response, companies like Zoom issued stronger privacy protections, such as meeting passwords and waiting rooms, so that meeting hosts could manually admit guests.

In 2010, Mozilla Firefox released a browser extension called Firesheep that opened a vulnerability for people using the browser on public, unencrypted Wifi networks. Specifically, the Firesheep extension made it easy for attackers to easily steal these users’ session cookies from any website added to their preferences in the browser. Ultimately, many websites responded to protect against this session hijacking risk by requiring HTTP Secure (HTTPS) connections.

In 2019, a researcher on a bug bounty platform found a vulnerability in Slack that would allow attackers to force users into fake session redirects and then steal their session cookies, ultimately giving the attackers access to any data shared within Slack (which for many organizations ends up being quite a lot). Slack responded quickly and patched the vulnerability within 24 hours of the researcher identifying it.

In 2017, a security researcher identified a vulnerability in GitLab in which users’ session tokens were available directly in the URL. Upon digging deeper, the researcher found that GitLab also used persistent session tokens that never expired, meaning once an attacker got one session token, they could use it without the worry of expiration. 

This combination of open exposure and persistent tokens presented a serious risk, opening users to various severe attacks through session hijacking via a brute force attack. GitLab ultimately fixed the vulnerability by changing how it used and stored those tokens.

Session hijacking remains a top cyber-security threat, but there are several ways to protect your organization and its users from this type of attack. The best results come from using multiple (if not all) of these approaches together to provide several lines of defense for protection.

Make sure that the websites and applications your team use (particularly those that are part of an SSO universe) require the use of HTTPS everywhere — even beyond initial login pages — to ensure fully secure sessions at every stage. You should also hold them to the standard of using SSL/TLS encryption for everything, including sharing session keys. 

This level of encryption is the first line of defense in protecting the visibility of session keys. Finally, you should set a standard for locking down access to cookies from client-side scripts to protect against XSS attacks.

The longer and more random session cookies get generated, the better, as this makes them harder to predict or guess, therefore offering protection against brute force attacks. The best way to accomplish this true randomness is to use a web framework to generate and manage session cookies rather than create a system yourself.

The best way to protect against session fixation attacks is to change the session key immediately after authentication happens at login. 

Changing the key after login makes it so that even if an attacker knows the original key, they won’t know the key that will follow the user for the rest of their session. This approach means that even if an attacker sends users a phishing link and users do use that link to log in, the attacker won’t be able to do anything with the generated key.

Adding new areas for identity verification beyond the initial login and the resulting session cookie can also provide another layer of protection. 

For instance, you might look at the user’s IP address to determine if it matches the location of previous logins or monitor each user’s overall behavior to identify any anomalies better. However, this approach is not perfect: It may flag non-issues, such as cases where users move around often, and it may miss actual issues, such as cases where an attacker logs in from the same IP address as the user typically does.

IDS and IPS compare site traffic to a database of known attack signatures. If these systems find a match, they will block that traffic and alert system owners. These systems can be difficult and expensive to install but offer a strong layer of defense against session hijacking.

Finally, consider instituting policies that manage how users end sessions. Two popular approaches include time boxing user sessions, particularly after a period of inactivity, and requiring automatic logoff whenever the window is closed. Both of these approaches help minimize the amount of time that a particular session cookie remains active. Along the same lines, once a user logs off, you should make sure the session cookie automatically gets deleted from their device to avoid any extra exposure.