What is Session Hijacking

Short of having valid credentials, what’s the easiest way for an attacker to gain access to your data?

Session hijacking enables attackers to access applications without credentials or the need to submit a multi-factor authentication token.

As the world migrates to passwordless authentication, session hijacking will replace leaked credentials as the primary way attackers gain unauthorized access.

In this post, we’ll cover what session hijacking is, why attackers exploit it, and how you can prevent these attacks.

But first, let’s define some things…

What is a session?

HTTP is a stateless protocol, meaning it doesn’t remember any information from one request to the next.

To allow the server to maintain continuity with the user (so they don’t have to log in for every action), session tokens were created.

When you log in to a website, the server creates a session and assigns a unique identifier, called a session token, to keep track of who you are while you’re using the site.

This session token is typically stored on the client side, usually in a cookie, and is submitted in subsequent requests to the server to maintain the session.

How does session hijacking work?

Session hijacking is when an attacker takes over a user’s active session with a web application, allowing the attacker to impersonate the user and access the app as if they were the legitimate user.

There are several types of session hijacking, including:

1. Cross-Site Scripting (XSS) Attack

• How it works: In an XSS attack, the attacker injects malicious code (often JavaScript) into a website that users visit. When the user interacts with the infected website, the malicious script runs in the user’s browser and can steal the session ID from cookies or other storage.
• Example: A website vulnerable to Stored XSS allows an attacker to inject a script that retrieves the user’s session ID and sends it to the attacker’s server.

2. Session Fixation

• How it works: In a session fixation attack, the attacker tricks the user into logging in with a predetermined session ID. After the user authenticates, the attacker uses the same session ID to hijack the user’s session.
• Example: The attacker sends the user a link with a specific session ID embedded. When the application doesn’t generate a new session token after logging in, the attacker can take control of their victim’s session after they authenticate using the malicious link.

3. Session Side-Jacking (HTTP Hijacking)

• How it works: Similar to Man in the Middle (MitM) attacks, session side-jacking involves the malicious user sniffing network traffic to capture the session cookie. If the web app is only partially encrypted (e.g., certain pages don’t use HTTPS), the session cookie may still be transmitted over an insecure connection, making it vulnerable.
• Example: An attacker uses a packet-sniffing tool like Wireshark on a public Wi-Fi network to capture session cookies and hijack the user’s account.

4. Cross-Site Request Forgery (CSRF)

• How it works: In a CSRF attack, the attacker tricks users into submitting requests (usually through malicious links or forms) to a web application they’re logged into. Since the session is still active, the web server processes the request as if it were a legitimate request from the victim’s device.
• Example: The attacker sends the user a link that triggers a money transfer from their account without their knowledge. Since the user is already authenticated, the web app processes the request.

5. Brute Force Attacks

• How it works: In a brute force session hijacking attack, the attacker tries different session IDs until they successfully match a valid one. This can happen if session IDs are predictable or insufficiently random.
• Example: The attacker uses a script to try different session ID combinations, eventually gaining access to a valid session.

6. Malware-Based Session Hijacking

• How it works: In this form of hijacking, the attacker uses malware installed on the victim’s device to steal the session ID directly. The malware can extract the session ID from browser cookies or session storage.
• Example: A user downloads malicious software that accesses their session cookies and sends them to the attacker.

7. Physical Access Session Hijacking

• How it works: If an attacker gains physical access to a user’s computer or device, they can extract session information from the browser or memory.
• Example: An attacker temporarily uses an unattended device to steal the session ID and continue using the session remotely.

What do attackers gain from session hijacking?

Beyond gaining unauthorized access to the website or app, there are a number of things attackers can do, including:

• Access sensitive data
• Make fraudulent purchases
• Identity theft
• Access sensitive functionality or perform administrative actions
• Spread malware or launch phishing attacks
• Escalate privileges to pivot and launch attacks against other systems
• Read and intercept messages, emails, or other internal communications
• Take control over IoT devices like cameras, locks, or other connected systems

Real-world examples of Session Hijacking

• Compromising Google accounts: In October 2023, threat actors stole data from compromised Google accounts. They did this by exploiting an undocumented Open Authorization 2.0 (OAuth) endpoint called MultiLogin to restore expired authentication tokens. This allowed them to bypass authentication and access their victim’s accounts.
• Citrix Bleed: In October 2023, Citrix patched a vulnerability that exploited a buffer overflow in Citrix NetScaler ADC and Netscalar Gateway products. By sending specially crafted HTTP requests, attackers could indefinitely reset the login timeout timer. This allowed them to keep sessions open without credentials, enabling them to bypass single-factor and multi-factor authentication and gain access to their victim’s accounts.
• GitLab Sessions: In May 2017, a security researcher discovered that GitLab stores their session tokens within URLs. This means that it can end up in various logs (for example due to Referer leaks or XSS). To make matters worse, the session tokens never expired. This means that attackers could exploit disclosed session tokens for eternity (or at least until the issue was patched).

Does MFA protect against session hijacking?

No. While multi-factor authentication (MFA) adds an extra layer of security during the login process, it does little to prevent an attacker from hijacking a valid session token.

Once an attacker gains access to a valid session token for an authenticated user, they can impersonate the victim and send unauthorized requests.

This is because MFA is generally only applied during login and not during the ongoing session.

What is the best defense against session hijacking?

Preventing session hijacking requires implementing a number of security practices to prevent attackers from stealing them. Here are the most effective defenses:

1. Use HTTPS Everywhere

• Encrypt All Communications: Enforce the use of HTTPS on all pages of the website to prevent attackers from intercepting traffic between the user and the server (e.g., via Man-in-the-Middle attacks). With HTTPS, session tokens are transmitted securely over encrypted channels.
• HTTP Strict Transport Security (HSTS): Enforce HSTS to ensure that browsers always use HTTPS, even if a user attempts to access the site via HTTP.

2. Secure Session Tokens in Cookies

• HttpOnly Flag: Mark session cookies as HttpOnly to prevent them from being accessed or modified by JavaScript, which mitigates the risk of Cross-Site Scripting (XSS) attacks.
• Secure Flag: Use the Secure flag to ensure that session cookies are only sent over HTTPS connections.
• SameSite Flag: Set the SameSite attribute to Strict or Lax to prevent cross-site request forgery (CSRF) attacks by restricting how cookies are sent with cross-origin requests.

3. Session Timeouts and Token Expiration

• Short Session Lifetimes: Implement session timeouts with idle time limits, forcing users to re-authenticate after a period of inactivity.
• Regenerate Session IDs: Change the session token periodically (e.g., after login or privilege escalation) to reduce the risk of token reuse if it’s compromised.
• Revoke Tokens on Logout: Ensure that session tokens are invalidated immediately upon user logout to prevent attackers from using stolen or old tokens.

4. Prevent Cross-Site Scripting (XSS)

• Sanitize User Input: Thoroughly validate and sanitize any user input to prevent malicious scripts from being injected into the application.
• Content Security Policy (CSP): Implement a strong CSP to limit what types of content can be executed on the site and mitigate the risk of XSS.

5. Monitor Session Activity

• Session IP Binding: Restrict the use of a session to the same IP address from which it originated, preventing an attacker from using a hijacked session from a different location.
• User-Agent Validation: Bind sessions to the specific user-agent or device used by the user. If the session token is reused on a different device or browser, invalidate the session.

6. Log and Monitor Session Anomalies

• Detect Suspicious Activity: Implement monitoring and alerts for unusual session behavior, such as logins from different geographical regions, multiple logins within a short timeframe, or concurrent sessions from different IPs.