What is Session Hijacking? A Technical Overview

Originally published by AppOmni.

Written by Justin Blackburn, Sr. Cloud Threat Detection Engineer, AppOmni.

Sessions are a vital component of modern websites and SaaS applications because they enable streamlined communication between devices and servers. But adversaries frequently target sessions in order to circumvent the authentication process — which includes any additional security measures like multi-factor authentication (MFA) — and gain access to the victim’s account.

In the first installment of our technical blog series on session security, I’ll explain the implications of session hijacking, how to detect it, and why identifying potential session hijacking threats is critical to protecting your SaaS users.

What is a session?

Whenever you log in to a website or web application, the server must maintain an authenticated state to enable subsequent actions without requiring re-authentication for each request. Therefore, a session is generated to facilitate seamless communication between your device and the hosting server. This eliminates the need for constant re-authentication as you navigate from page to page. For API services, it eliminates the need for re-authentication for each request.

After authenticating a user, the server returns a session identifier or token usually in the form of a cookie or an access token. Cookies — small pieces of data stored in your browser — are used by both the server and the browser to maintain stateful authentication. With stateful authentication, the server keeps track of information about the user such as their identity and permissions. The server uses the cookie, which is passed with each request, to look up the user’s session information to determine if the user is authenticated and authorized for the requested resources.

On the other hand, access tokens such as JSON Web Tokens (JWTs) encapsulate user identity information and operate in a stateless manner. Unlike cookies, JWTs enable client authentication without requiring the server to store user information. All the necessary identity information is included in each request made by the client, and because JWTs include identity information, they are digitally signed to ensure their integrity.

Both session cookies and JWTs allow the website or application to “remember” each user throughout their visit while also ensuring secure data transmission. A session, whether in the context of interactive user sessions or API services, persists until the user signs out or the session reaches its expiration.

API services often utilize access tokens. To enhance security, it’s common to expire access tokens after a predetermined time to reduce impact in the event one is compromised. Unlike user sessions, where the lifespan may be virtually indefinite, API tokens such as JWTs are typically short-lived. Depending on organization security requirements and who implemented the session management for a service, the access token lifespan can widely vary from a few minutes to a few months.

Refresh tokens are often used as a mechanism to securely obtain new access tokens, allowing services to stay authenticated without constant manual user intervention. An access token and refresh token are returned after the initial authentication. The client then uses the access token until it expires and can request a new access token using the refresh token. This approach minimizes the risks associated with having a long-lived token, providing a balance between convenience and security.

What is session hijacking?

Sessions enhance the user experience by maintaining a continuous and secure connection, but they can still be susceptible to interception, theft on the client side, or by exploiting web application vulnerabilities. If a third-party gains unauthorized access to an active session, they can impersonate the legitimate user.

An adversary can exploit a compromised session to perform unauthorized actions, obtain sensitive information, or manipulate the user’s account. With the increased usage of MFA, especially phish-resistant implementations such as WebAuthN and PKI-based MFA, session hijacking is an attractive option for adversaries because it bypasses the entire authentication process, including MFA.

In this illustration, the user (victim) signs in to a web application. Once authenticated, the server creates a session and returns a session token/cookie, which is stored by the user’s browser. The attacker then steals the session cookie from the victim and uses it to impersonate them.

Best Practices to Mitigate Session Hijacking

Many web services implement various strategies to both reduce the risk of an adversary hijacking a session and limit the effectiveness of a successful hijacked session.

Token Binding

Binding a session token to a specific device, browser, or other attribute of the originating request can make it more difficult for an attacker to hijack the session. Even if an attacker manages to intercept a token, they won’t be able to replay it on a different device. Depending on the implementation, a request from a different IP address, user agent, or device fingerprint in the same session will force the user to re-authenticate. For example, Salesforce has such a setting called “Lock sessions to the IP address from which they originated” that can be enabled by an organization administrator.

Step-Up Authentication

Step-up authentication involves requiring additional authentication steps for sensitive actions or when unusual user behavior is detected. For example, the system might prompt for the user’s password again or present an MFA challenge. This extra layer adds a barrier for attackers attempting to exploit an already hijacked session, as they would need to overcome the additional authentication challenges required to action their objectives.

Content Security Policies

Cross-Site Scripting (XSS) attacks can be used to hijack a session. XSS is a type of security vulnerability where attackers inject malicious client-side code in trusted websites that are then executed by the browser of unsuspecting users. By defining and enforcing strict rules regarding the types of content that can be loaded and executed on a web page, content security policies (CSPs) help prevent malicious scripts from running in the user’s browser. This significantly reduces the likelihood of attackers injecting code that could steal session cookies or manipulate the session in some way. CSPs act as a proactive defense against common web application vulnerabilities that might be exploited for session hijacking.

Further Considerations

Despite the protections provided by these mitigations, there is still always the possibility that an adversary can bypass these protections and successfully hijack a session. Furthermore, not all websites and web services implement these proactive measures. In our next blog in this series, we walk through a technical tutorial that shows you how to test and detect indicators of a successful hijacked session in your environment.