- CWE-22: Path Traversal
- CWE-78: OS Command Injection
- CWE-79: Cross-Site Scripting
- CWE-89: SQL Injection
- CWE-90: LDAP Injection
- CWE-91: XML Injection
- CWE-94: Code Injection
- CWE-98: PHP File Inclusion
- CWE-113: HTTP Response Splitting
- CWE-119: Buffer Errors
- CWE-130: Improper Handling of Length Parameter Inconsistency
- CWE-193: Off-by-one Error
- CWE-200: Information Exposure
- CWE-211: Information Exposure Through Externally-Generated Error Message
- CWE-236: Improper Handling of Undefined Parameters
- CWE-276: Incorrect Default Permissions
- CWE-284: Improper Access Control
- CWE-285: Improper Authorization
- CWE-287: Improper Authentication
- CWE-297: Improper Validation of Certificate with Host Mismatch
- CWE-306: Missing Authentication for Critical Function
- CWE-312: Cleartext Storage of Sensitive Information
- CWE-345: Insufficient Verification of Data Authenticity
- CWE-352: Cross-Site Request Forgery
- CWE-384: Session Fixation
- CWE-427: Uncontrolled Search Path Element
- CWE-434: Unrestricted Upload of File with Dangerous Type
- CWE-476: NULL Pointer Dereference
- CWE-521: Weak Password Requirements
- CWE-601: Open Redirect
- CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
- CWE-613: Insufficient Session Expiration
- CWE-618: Exposed Unsafe ActiveX Method
- CWE-671: Lack of Administrator Control over Security
- CWE-798: Use of Hard-coded Credentials
- CWE-799: Improper Control of Interaction Frequency
- CWE-822: Untrusted Pointer Dereference
- CWE-835: Infinite Loop
- CWE-918: Server-Side Request Forgery (SSRF)
- CWE-942: Overly Permissive Cross-domain Whitelist
CWE is a trademark of the MITRE Corporation.
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
- Potential impact
- Attack patterns
- Affected software
- Severity and CVSS Scoring
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.
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:
- 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,
- 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,
- 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:
- $SessionID = md5($UserLogin);
- if (empty($_COOKIE["SESSION_ID"]))
- if ($_COOKIE["SESSION_ID"] == $SessionID):
- echo "Hello ".$UserLogin;
- echo "Please, enter your credentials";
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.
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,
- CWE-384: Session Fixation [cwe.mitre.org]
- Session fixation [www.owasp.org]
- Session Fixation [projects.webappsec.org]
- 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