Session Fixation [CWE-384]

Session Fixation weakness describes a case where an application incorrectly handles session identifiers when establishing new sessions.

Created: May 17, 2014
Latest Update: December 28, 2020

Table of Content

1. Description
2. Potential impact
3. Attack patterns
4. Affected software
5. Severity and CVSS Scoring
6. Mitigations
7. References

Want to have an in-depth understanding of all modern aspects of
Session Fixation [CWE-384]? Read carefully this article and bookmark it to get back later, we regularly update this page.

1. Description

Session fixation vulnerability arises in multiuser environments and is common for applications that authenticate users using a single token called session. This weakness is commonly observed in the following cases:

1. The web application does not destroy existing session when the user logs off. An attacker can use the same identifier to gain access to session, which is associated with the existing user,
2. The web application does not generate new session identifier for every logon event. An attacker can force a victim to use known session identifier and gain access to victim’s account once the session token is associated with the account,
3. The web application uses predictable session identifiers. An attacker can predict or brute-force session identifier and gain access to existing sessions.

This weakness can be introduced during design or implementation phase of software development process. Depending on the attack vector the session token can be stolen or predicted by the attacker using other vulnerabilities in software, such as cross-site scripting, directory traversal (when session data are stored in files in insecure manner), SQL injection (when session data are stored in database or files).

If application delivers session identifier to the browser using HTTP GET request (e.g. URL), it can be transmitted to a third-party websites via HTTP Referrer browser header and stored in log files and visitor statistics of different tracking systems.

Examples of vulnerable code
Let’s have a look at the following code in PHP:

The code above uses predictable session identifier solely based on username. An attacker, who knows username of the victim, can forge the cookie and successfully authenticate against the web application.

2. Potential impact

A remote attacker can gain access to victim’s session and perform arbitrary actions with privileges of the user within the compromised session.

3. Attack patterns

The following CAPEC (Common Attack Pattern Enumeration and Classification) vectors are related to Session Fixation weakness:

• CAPEC-21: Exploitation of Session Variables, Resource IDs and other Trusted Credentials
• CAPEC-31: Accessing/Intercepting/Modifying HTTP Cookies
• CAPEC-39: Manipulating Opaque Client-based Data Tokens
• CAPEC-59: Session Credential Falsification through Prediction
• CAPEC-60: Reusing Session IDs (aka Session Replay)
• CAPEC-61: Session Fixation
• CAPEC-196: Session Credential Falsification through Forging

In alternative WASC Threat Classification this weakness is described as an attack technique under WASC-37 (Session Fixation).

4. Affected software

Any multiuser web application that uses sessions to identify users is potentially vulnerable to this weakness.

5. Severity and CVSS Scoring

This weakness should be scored depending on the maximum possible impact and other factors and functionality of the web application. It is usually scored with medium access complexity due to need of victim interaction or other actions, such as brute-force attack.

If an attacker is able to gain administrative privileges this weakness should be scored as:
6.8 (AV:N/AC:M/Au:N/C:P/I:P/A:P) - Medium severity.

In case of information disclosure the score will be:
4.3 (AV:N/AC:M/Au:N/C:P/I:N/A:N) - Medium severity.

6. Mitigations

Session fixation vulnerability can be mitigated through source code modification only. It is almost impossible to use WAF for this purpose.

Please follow these recommendations when developing application in order to avoid session fixation vulnerabilities:

• Store session data in a safe place. Use database instead of files if possible,
• Always generate session identifiers based on random data. Do not rely on third-party software, such as web server, to generate session tokens,
• Set time frame of 15 to 20 minutes for session lifetime,
• Use multiple identifiers when validating user authentication. For example, check along with session identifier also user IP address, browser-generated HTTP headers, etc.,
• Always reset session identifier when user logs off or changes his/her password,
• Never use HTTP GET requests to deliver session identifiers, since session toked can be transmitted using HTTP referrer browser header to a third-party website and disclosed. Use cookies instead.

7. References

1. CWE-384: Session Fixation [cwe.mitre.org]
2. Session fixation [www.owasp.org]
3. Session Fixation [projects.webappsec.org]
4. Session Fixation Vulnerability in Web-based Applications [www.acrossecurity.com]

Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to ImmuniWeb is given.

↑ Back to Top