1. Introduction
2. Technical Explanation
Session Fixation occurs because the web server doesn’t create a new, random session ID after authentication. An attacker can send a link containing their pre-defined session ID to a victim. If the victim clicks this link and then logs in, the server may associate the victim’s credentials with the attacker’s session ID. The Common Weakness Enumeration (CWE) identifier for this issue is CWE-384. An example attack involves an attacker crafting a URL like https://example.com/login?sessionid=attacker_token and sending it to a user. If the user logs in via that link, the attacker can then use the same session ID to access the victim’s account.
- Root cause: The server accepts client-supplied session tokens without generating a new one upon successful authentication.
- Exploit mechanism: An attacker sends a crafted URL with a predetermined session token to the victim, hoping they will authenticate using that token.
- Scope: Web applications using HTTP cookies for session management are affected. Specific versions or configurations depend on the application’s implementation of session handling.
3. Detection and Assessment
- Scanning: Burp Suite, OWASP ZAP, and other web scanners can detect Session Fixation using specific signatures. These are examples only; results should be verified manually.
# No direct command example available, as this is a web application issue. Use browser tools or scanners.4. Solution / Remediation Steps
4.1 Preparation
- Ensure you have access to the application’s source code or configuration files. A roll back plan is to restore the backed-up code/config.
- A change window may be needed for production systems; approval from security and development teams is recommended.
4.2 Implementation
- Step 1: Modify the application’s session management logic to reject client-supplied session IDs.
- Step 3: Ensure that all subsequent requests use the newly generated session ID.
4.3 Config or Code Example
Before
// Insecure example (PHP)
session_start();
if(isset($_GET['sessionid'])) {
$_SESSION['sessionid'] = $_GET['sessionid'];
}
After
// Secure example (PHP)
session_start();
if(isset($_GET['sessionid'])) {
// Do not use client-supplied session ID.
}
session_regenerate_id(true); // Generate a new session ID after authentication.
4.4 Security Practices Relevant to This Vulnerability
Practices that directly address this vulnerability include secure defaults and input validation.
- Practice 1: Secure Defaults – Configure the application with strong, unpredictable session ID generation by default.
- Practice 2: Input Validation – Reject any client-supplied data used as a session token to prevent manipulation.
4.5 Automation (Optional)
# No suitable script available for automated remediation. Focus on code review and testing.5. Verification / Validation
Confirming the fix involves checking that new session IDs are generated upon login and client-supplied IDs are ignored.
- Re-test: Repeat the scanner tests from step 3; they should no longer report Session Fixation vulnerabilities.
- Smoke test: Verify that users can still log in and access protected resources without issues.
- Monitoring: Monitor application logs for consistent session IDs across multiple requests, which could indicate a regression.
# No direct command example available; use browser tools or scanners to verify the new session ID is generated after login.6. Preventive Measures and Monitoring
Preventive measures include updating security baselines and incorporating checks into CI/CD pipelines.
- Baselines: Update your web application security baseline to include requirements for secure session management (for example, CIS control 14).
- Asset and patch process: Implement a regular review cycle of application configuration and code to ensure security best practices are followed.
7. Risks, Side Effects, and Roll Back
Potential risks include compatibility issues with older browsers or applications if session ID generation is changed significantly.
- Roll back: Restore the backed-up application code and configuration if any issues arise.
8. References and Resources
- Vendor advisory or bulletin: N/A – depends on your web server software.
- NVD or CVE entry: http://projects.webappsec.org/w/page/13246960/Session%20Fixation
- Product or platform documentation relevant to the fix: https://www.owasp.org/index.php/Session_fixation