Definition

Session hijacking is defined as taking over an active TCP/IP communication session without the user’s permission. When implemented successfully, attackers assume the identity of the compromised user, enjoying the same access to resources as the compromised user. Identity theft, Information theft, stealing sensitive data are some of the common impacts of session hijacking.

Session hijacking is also an attack where a user session is taken over by an attacker. A session starts when you log into a service, for example your banking application, and ends when you log out. The attack relies on the attacker’s knowledge of your session cookie, so it is also called cookie hijacking or cookie side-jacking. Although any computer session could be hijacked, session hijacking most commonly applies to browser sessions and web applications.

Types of session hijacking attacks:

There are two types of session hijacking depending on how they are done. If the attacker directly gets involved with the target, it is called active hijacking, and if an attacker just passively monitors the traffic, it is passive hijacking.

Active:

The attacker will silence one of the machines, usually the client computer, and take over the clients’ position in the communication exchange between the workstation and the server. The active attack also allows the attacker to issue commands on the network making it possible to create new user accounts on the network, which can later be used to gain access to the network without having to perform the session hijack attack.

Passive:

In Passive session hijacking attack, the attacker monitors the traffic between the workstation and server. The primary motivation for the passive attack is to monitor network traffic and potentially discover valuable data or passwords.

• Session fixation: To discover the victim’s cookie, the attacker may simply supply a known session key and trick the user into accessing a vulnerable server. There are many ways to do this, for example by using HTTP query parameters in a crafted link sent by e-mail or provided on a malicious website, for example:

When the victim clicks the link, they are taken to a valid login form, but the session key that will be used is supplied by the attacker. After authentication, the attacker can use the known session key to hijack the session.

Another method of session fixation is to trick the user into completing a specially crafted login form that contains a hidden field with the fixed session ID. More advanced techniques include changing or inserting the session cookie value using a cross-site scripting attack or directly manipulating HTTP header values (which requires access to the user’s network traffic) to insert a known session key using the Set-Cookie parameter. 

One legacy trick that will no longer work in modern browsers (since Chrome 65 and Firefox 68) was to inject the <meta http-equiv="Set-Cookie"> HTML tag to set the cookie value via the metadata tag. This functionality has also been removed from the official HTML spec.

• Cookie theft by malware or direct access: A very common way of obtaining session cookies is to install malware on the user’s machine to perform automated session sniffing. Once installed, for example after the user has visited a malicious website or clicked a link in a spam email, the malware scans the user’s network traffic for session cookies and sends them to the attacker. Another way of obtaining the session key is to directly access the cookie file in the client browser’s temporary local storage (often called the cookie jar). Again, this task can be performed by malware, but also by an attacker with local or remote access to the system.
• Brute force: Finally, the attacker can simply try to guess the session key of a user’s active session, which is feasible only if the application uses short or predictable session identifiers. In the distant past, sequential keys were a typical weak point, but with modern applications and protocol versions session IDs are long and generated randomly. To ensure resistance to brute force attacks, the key generation algorithm must give truly unpredictable values with enough entropy to make guessing attacks impractical.

Session Hijacking prevention and Countermeasures

End-to-end encryption between the user’s browser and the web server using secure HTTP or SSL, which prevents unauthorized access to the session ID. VPNs  can also be used to encrypt everything, not just the traffic to the webserver using personal VPN solution tools.

Web servers can generate long and random session cookies, which reduces the chances of an adversary guessing or predicting what a session cookie could be.

Session ID monitors can also be used to monitor if these IDs are being used, and utilities such as Blacksheep can be used to send fake session IDs to the network and monitor if an intruder is trying to use the session ID.

There should be an automatic log off if a session ends in use, and the client should be required to re-authenticate using a different session ID. Additionally, a server can be directed to delete a session cookie from the client’s computer to minimize the amount of time a session cookie is being exposed in the network.

The session hijacking threat exists due to limitations of the stateless HTTP protocol. Session cookies are a way of overcoming these constraints and allowing web applications to identify individual computer systems and store the current session state, such as your shopping in an online store.

For regular browser users, following some basic online safety rules can help reduce risk, but because session hijacking works by exploiting fundamental mechanisms used by the vast majority of web applications, there is no single guaranteed protection method. However, by hardening multiple aspects of communication and session management, developers and administrators can minimize the risk of attackers obtaining a valid session token:

• Use HTTPS to ensure SSL/TLS encryption of all session traffic. This will prevent the attacker from intercepting the plaintext session ID, even if they are monitoring the victim’s traffic. Preferably, use HSTS HTTP)strict transport security to guarantee that all connections are encrypted.
• Set the HttpOnly attribute using the Set-Cookie HTTP header to prevent access to cookies from client-side scripts. This prevents XSS and other attacks that rely on injecting JavaScript in the browser. Specifying the Secure and Same Site  directives is also recommended for additional security.
• Web frameworks offer highly secure and well-tested session ID generation and management mechanisms. Use them instead of inventing your own session management.
• Regenerate the session key after initial authentication. This causes the session key to change immediately after authentication, which nullifies session fixation attacks – even if the attacker knows the initial session ID, it becomes useless before it can be used.
• Perform additional user identity verification beyond the session key. This means using not just cookies, but also other checks, such as the user’s usual IP address or application usage patterns. The downside of this approach is that any false alarms can be inconvenient or annoying to legitimate users. A common additional safeguard is a user inactivity timeout to close the user session after a set idle time.

Drop your comment please.