Are you currently experiencing an attack?

Are you currently experiencing an attack?

Defeating Session Attacks

A session attack occurs when attackers try to obtain unauthorized access to a computer system by hijacking a legitimate user’s session.

For example, in web applications, a session starts after logging into the website and ends after logging out. At the initiation of the session (during user authentication), most applications generate a unique session token and pass it along to the browser. (The token is usually stored as a cookie.) Because HTTP is a stateless protocol, the browser sends this token back to the server with each subsequent interaction during the session. This identifies and authenticates the user.

If an attacker can know or discover this token, he can impersonate the user and take over the session. Whatever the user can do within the application, the attacker will be able to do as well.

This article will discuss session attacks and how to prevent them from succeeding, with a focus on web applications (since these are the most common targets). Similar concepts apply for other types of sessions such as APIs.

How to Wage a Session Attack

Attackers can attempt to compromise a session in a number of different ways.

Man-in-the-Middle (MITM)

In its simplest form, an MITM attack occurs when an attacker is between two parties trying to communicate, and the attacker is able to intercept messages as well as impersonate at least one of the parties.

For example, an attacker can set up a free, but malicious, Wi-Fi hotspot in a public place. When users connect to insecure sites (i.e., they use HTTP instead of HTTPS), the attacker can sniff the traffic, including session tokens.

For sessions with secure sites, a successful attack is more challenging but still feasible. Techniques such as SSL stripping or DNS hijacking allow the attacker to capture the data sent by the user, including login credentials and session tokens. In some situations, the attacker can even alter the data sent by the user before forwarding it upstream to the site.

Cross-Site Scripting (XSS)

An XSS attack abuses a web application that accepts and incorporates user-generated content. For example, online forums accept and display posts from users, and ecommerce sites often allow users to post product reviews.

In an XSS attack, the hacker submits content that includes scripting code (usually Javascript). If the web app accepts the content, subsequent users will receive the script in their browsers. The browsers will execute the code, which can perform a variety of nefarious activities, such as sending the users’ session tokens for the site to the attacker.

Cross-Site Request Forgery (CSRF or XSRF)

In a CSRF attack, the attacker does not have direct access to the session token, nor is it needed. Instead, the attacker constructs a malicious URL for the web application, and tricks the victim into accessing it. The URL creates a request to perform an action within the targeted web application—for example, “change the current user’s email address to {the attacker’s email address}”. If the user is currently logged into the application when that URL is accessed, then a valid session token will be included with the request, and the hostile action will be performed by the application.

Session Side Jacking

This attack uses packet sniffing to monitor traffic and capture session data after user authentication. Some websites only use SSL/TLS encryption for login pages; this creates a vulnerability in which an attacker can listen to post-login network traffic. If the attacker then finds a session token in the sniffed data, they can use this information to impersonate the user and hijack the session. Users of unsecured Wi-Fi hotspots are vulnerable to this attack.

Session Fixation

A server which accepts (or generates and then provides) a session token before the user is authenticated is vulnerable to session fixation. Here the attacker provides a URL with a session token to the victim, and fools the victim into accessing the URL and logging into the application. By doing this, the user has created a valid session based on the token. Now the attacker can hijack the session at will.


If an attacker can install malware on the victim’s system, then the attacker can sniff and capture the victim’s network traffic, including session tokens.

Brute Force

This type of attack is exactly how it sounds; the attacker repeatedly guesses what the victim’s session ID could be. In theory, this can work; in practice, it is only possible if the application uses very simple session IDs. Of course, an attacker may try to automate the guessing process by using scripts and special tools to increase his chance of success.

Defending Against Session Attacks

As shown above, session attacks can occur in a variety of ways. Similarly, defending against them requires a variety of countermeasures.

Attack Response

Along with the attack-prevention measures discussed below, an often-overlooked step is to train your staff how to react if an attack is suspected:

  • Alert: If a user complains that an account was usurped, take immediate action.
  • Contain: Terminate all sessions for that user. If a broader breach is suspected, shut down the application.
  • Purge: Rollback whatever changes occurred within the victim’s account.
  • Recover: Carefully restore the account and reset credentials for the victim.

Ideally, no session attack would ever succeed, and this training would never be needed. But in today’s threat environment, there’s no such thing as too much preparation. Incident-response training is an important part of every security plan.

Attack Prevention

There are a variety of steps that will harden your users’ sessions against compromise. All of the below are recommended.

Harden the Communication Layer

Use the Secure attribute and the __Secure- prefix on your cookies. This ensures they will only be sent over HTTPS.

Use the HttpOnly attribute. This prevents Javascript in a client browser from accessing the cookies.

Use the SameSite=Strict attribute. This will prevent cookies from being included with third-party requests, which will prevent some types of CSRF attacks.

Ensure that session IDs are at least 128 bits long, which will prevent brute-force attacks. Also ensure that session tokens are not included in URLs.

Set Timeouts and Policies

Setting appropriate timeouts can have a significant impact on security. Timeouts should be set, and they should be set as low as possible. If possible, there should be a global timeout for all application sessions.

Use the Content-Security-Policy (CSP) header if possible, to restrict the allowable sources for Javascript and other resources (images, fonts, etc.) This can prevent XSS attacks.

Renew session keys after initial authentication for additional protection.

Invalidate session tokens after a user logs out.

Use a Next-Generation Firewall

For robust security, a dedicated security solution should be used. Trying to add security features to web application servers is not an ideal approach (they should be optimized for serving web applications). Instead, security should be provided by a solution that is designed for, and dedicated to, that purpose.

There are many WAF products that can protect against session attacks and other web threats to varying degrees. Most are able to detect and block requests with obviously hostile payloads (scripts and so on). Fewer can customize responses back to the user, as described above.

For full security, a next-generation WAF must be used. It is not merely enough to examine incoming requests for hostile intent; it must also be recognized that some hostile requests will appear to be completely legitimate. For example, if an attacker wages a phishing campaign and successfully captures a user’s credentials, there is no way for a conventional WAF to detect that the next use of these credentials is not being done by the person to whom they were issued.

Reblaze goes beyond traditional WAF solutions and adds a number of additional security layers. The platform uses UEBA and Machine Learning to build behavioral profiles for each web application that it protects. It learns the characteristics of legitimate users and how they interact with the protected applications. By definition, every hostile user must, at some point, deviate from legitimate user behavior. When a hostile actor attempts to abuse an account, Reblaze detects and blocks the traffic source, preventing further access.

Reblaze is a comprehensive web security platform, providing web application security, API security, bot management and hostile bot mitigation, and more. For more information or to get a demo, contact us.

Get your price quote

Fill out your email below, and we will send you a price quote tailored to your needs

This website uses cookies to ensure you get the best experience on our website.