+44 (0)203 88 020 88

Menu

Search

Cyber Security News & Articles

 

Cyber Security
News & Articles

Trusted Cyber Security Experts
25+ Years Industry Experience
Ethical, Professional & Pragmatic

Understanding Session Fixation Attacks

The most common causes of CVE

Session Fixation is a type of attack on web application users where an attacker is able to trick a victim into using a Session ID which is previously known to them.

When the victim makes use of the known Session ID in their requests to a vulnerable application, the attacker is able to exploit this vulnerability to make their own requests using the same Session ID – carrying out actions as if they were the legitimate owner of the Session. This attack differs from Session Hijacking, in the fact that the Session ID is previously known to the attacker and is forced onto the victim, as opposed to the attacker discovering the token through another vulnerability.

Why do we need sessions ?

The HTTP protocol that is used by web-based applications is designed to be ‘stateless’, meaning that each request handled by the server is processed individually and is not treated as being related to previous requests. The problem is that most web applications need to keep track of user’s actions across multiple requests, and remember certain information about the user while they are active. This is called the user’s ‘Session’.

Each Session consists of data held on the server which is associated with a Session ID of some kind, which is passed by the user’s browser with each HTTP request. Data that’s held in sessions often includes sensitive items, such as: shopping cart contents, identity information and authorisation levels.

Session Fixation

In a Session Fixation attack, a victim is tricked into using a particular Session ID which is known to the attacker. The attacker is able to fool the vulnerable application into treating their malicious requests as if they were being made by the legitimate owner of the session. A typical scenario involves the attacker prompting their victim into clicking on a link which directs them to sign in, while also supplying a Session ID. The server accepts the Session ID, and populates the session with information about the authenticated user. The attacker is then able to carry out actions in the application as if they were the victim by passing the compromised Session ID along with their requests.

Many developers think that simply using server-generated Session IDs is enough to prevent Session Fixation attacks; however, the example in the following diagram shows that this is not the case. The attacker only needs to extract the Session ID from their own cookie before sending it to the user:

session fixation

In a variation of the attack, the attacker could make use of subdomains under the target domain which they control, to allow them to set a wildcard cookie after tricking the user into accessing a malicious link. This takes advantage of the fact that web browsers will send wildcard cookies to any subdomain of the site which set them. It’s worth noting that there may even be no need for the user to actually log into the vulnerable application, as simply browsing through public areas on some websites may be enough to leak sensitive information to the attacker, such as shopping cart contents or credit card details filled in during the compromised session.

The impact to the victim of the attack and the owners of the website will vary, depending on the type of application and the nature of the data stored within the compromised user session. At a minimum, a successfully exploited Session Fixation could lead to a loss of privacy allowing the attacker to obtain sensitive information entered into the application by the victim. In a more serious case, it could lead to the takeover of the victim’s account if the attacker is able to authenticate with the application using the stolen Session ID.

If administrator accounts are compromised using this vulnerability the attack could be used to make other attacks possible, such as altering the configuration of the application or extracting data from backend databases. The organisation is likely to suffer damage to their reputation and lose the trust of users who have had their accounts compromised by the attack.

Testing for Session Fixation vulnerabilities

The most common type of Session Fixation vulnerability comes from a failure in the application to issue a new session token after login. Testing an application for this is fairly straightforward and can be performed using a web browser and a proxy application (such as Burp Suite or ZAP Proxy) using the following process:

  1. Browse to the application login page and check the HTTP Response in the proxy for a cookie containing the Session ID
  2. Note the value of the Session ID
  3. Sign into the application, and check the HTTP Response from the application
  4. If the response does not issue a new session cookie, then the application may be vulnerable to Session Fixation

In addition to testing how the application behaves during login, it’s also worth checking whether the application accepts a Session ID passed as a URL parameter, since this makes it especially easy for an attacker to force the Session ID onto a user through the use of a malicious link.

Ensuring cookies are handled correctly plays an important role in preventing certain types of Session Fixation vulnerabilities, as cookies which are scoped to their root path or which are valid for wildcard domains may allow a Session Fixation vulnerability to be exploited.

How to prevent Session Fixation vulnerabilities

The countermeasure for a Session Fixation vulnerability is to code the application in such a way that prevents the application from accepting a token that has been forced onto a victim’s session.

The following steps provide a robust way in which to secure a web application against these attacks:

Don’t accept Session IDs in GET or POST parameters

This makes it much harder for an attacker to exploit, since it’s simpler to trick a victim into making the request without the need for browser vulnerabilities. Additionally, all Session IDs should be server-generated; there should be no need for the client to propose a new session ID for the application.

Change the Session ID after login

The server should generate a new Session ID and set it as a cookie after the user has signed in. Any existing session for the user should be destroyed on the server.

Provide a logout feature and expire old sessions

The user should be able to choose when to end their session with the application, which should immediately terminate any current sessions on the server and not simply delete the cookie from the browser. Session data should also time-out automatically after a certain period, to reduce the time window an attacker can make use of a compromised session.

References

https://www.owasp.org/index.php/Session_fixation

 

Subscribe to our monthly newsletter today

If you’d like to stay up-to-date with the latest cyber security news and articles from our technical team, you can sign up to our monthly newsletter. 

We hate spam as much as you do, so we promise not to bombard you with emails. We’ll send you a single, curated email each month that contains all of our cyber security news and articles for that month.

Why Choose SecureTeam?

Customer Testimonials

“We were very impressed with the service, I will say, the vulnerability found was one our previous organisation had not picked up, which does make you wonder if anything else was missed.”

Aim Ltd Chief Technology Officer (CTO)

"Within a very tight timescale, SecureTeam managed to deliver a highly professional service efficiently. The team helped the process with regular updates and escalation where necessary. Would highly recommend"

IoT Solutions Group Limited Chief Technology Officer (CTO) & Founder

“First class service as ever. We learn something new each year! Thank you to all your team.”

Royal Haskoning DHV Service Delivery Manager

“We’ve worked with SecureTeam for a few years to conduct our testing. The team make it easy to deal with them; they are attentive and explain detailed reports in a jargon-free way that allows the less technical people to understand. I wouldn’t work with anyone else for our cyber security.”

Capital Asset Management Head of Operations

“SecureTeam provided Derbyshire's Education Data Hub with an approachable and professional service to ensure our schools were able to successfully certify for Cyber Essentials. The team provided a smooth end-to-end service and were always on hand to offer advice when necessary.”

Derbyshire County Council Team Manager Education Data Hub

“A very efficient, professional, and friendly delivery of our testing and the results. You delivered exactly what we asked for in the timeframe we needed it, while maintaining quality and integrity. A great job, done well.”

AMX Solutions IT Project Officer

“We were very pleased with the work and report provided. It was easy to translate the provided details into some actionable tasks on our end so that was great. We always appreciate the ongoing support.”

Innovez Ltd Support Officer

Get in touch today

If you’d like to see how SecureTeam can take your cybersecurity posture to the next level, we’d love to hear from you, learn about your requirements and then send you a free quotation for our services.

Our customers love our fast-turnaround, “no-nonsense” quotations – not to mention that we hate high-pressure sales tactics as much as you do.

We know that every organisation is unique, so our detailed scoping process ensures that we provide you with an accurate quotation for our services, which we trust you’ll find highly competitive.

Get in touch with us today and a member of our team will be in touch to provide you with a quotation. 

0

No products in the basket.

No products in the basket.