Detailed Explanation of Session Fixation Attack

I. Attack Description
Session fixation is an attack method that hijacks a user's session by exploiting a legitimate session identifier (Session ID). The attacker first obtains a valid session identifier and then lures the victim into logging in using that specific identifier. After the victim completes authentication, the attacker can impersonate the victim to access the system using the known session identifier.

II. Step-by-Step Analysis of the Attack Principle

1. Basics of Session Mechanism

   • Web applications use session identifiers to track user state (e.g., login status).
   • Session identifiers are typically stored in cookies or URL parameters.
   • Normal flow: The server generates a new session identifier when a user logs in; a temporary session is used when not logged in.

2. Core Vulnerability of the Attack

   • The application does not change the session identifier before and after login.
   • The attacker can obtain or preset a session identifier in advance.

3. Breakdown of Attack Steps
   Stage 1: Attacker Obtains a Fixed Session Identifier

   • Method 1: Directly access the application to obtain a system-assigned session identifier (e.g., Session ID in a non-logged-in state).
   • Method 2: Generate a specific identifier via a malicious link (e.g., https://example.com/login?sessionid=attacker_specified_value).

   Stage 2: Implant the Session Identifier into the Victim

   • Send a link containing the fixed session identifier via phishing emails.
   • Set the victim's cookie using an XSS vulnerability.
   • Preset a session identifier cookie on a public computer.

   Stage 3: Victim Logs in Using the Fixed Identifier

   • The victim accesses the application via the link provided by the attacker.
   • The system does not change the session identifier and directly completes the login binding.

   Stage 4: Attacker Hijacks the Session

   • The attacker accesses the application using the known session identifier.
   • The system mistakenly considers this an authenticated legitimate session.

III. Detailed Defense Measures

1. Regenerate Session Identifier After Login (Key Defense)

   • Immediately invalidate the old session upon successful authentication.
   • Generate a new random session identifier and bind it to the user.
   • Example code logic:

     # After successful login verification
     old_session_id = request.session.session_id
     request.session.flush()  # Clear old session data
     request.session.cycle_key()  # Generate new identifier
     log_security_event(f"Session renewed: {old_session_id} -> {request.session.session_id}")
     

2. Strengthen Security Attributes of Session Identifiers

   • Use sufficiently long random numbers (recommended 128 bits or more).
   • Ensure session identifiers are unpredictable (avoid simple rules like timestamps).

3. Multi-Dimensional Verification Mechanisms

   • Bind user fingerprint information (e.g., hash of User-Agent, IP address).
   • Set session timeout periods (operational timeout, absolute timeout).
   • Re-authentication required for sensitive operations (e.g., entering password before payment).

4. Secure Design of Identifier Transmission Methods

   • Prefer cookies over URL parameters for transmitting session identifiers (to prevent Referer leakage).
   • Set HttpOnly and Secure attributes for cookies (prevent XSS theft + enforce HTTPS).

5. Thorough Implementation of Logout Functionality

   • Actively destroy session data on the server side.
   • Immediately expire client-side cookies.

IV. Practical Scenario Simulation
Assume a vulnerable login process:

1. Attacker visits https://example.com to obtain their own session identifier SID=123.
2. Construct a malicious link https://example.com/login?SID=123 and send it to the victim.
3. The victim clicks the link and logs into their account. The server does not change the SID, only binding SID=123 to the account.
4. The attacker directly accesses the system using the preset SID=123 in the cookie, gaining the victim's permissions.

Fixed process:

1. When the victim logs in, the server detects that the session identifier has not changed (still SID=123).
2. At the moment of successful authentication, force the generation of a new identifier (e.g., SID=xyz) and return it to the client.
3. The old identifier SID=123 is immediately invalidated, and the attacker can no longer use it.

V. Extended Knowledge Points

• Difference from Session Hijacking: Fixation attack actively presets the identifier, while hijacking steals an existing active session.
• Relationship with CSRF: Some defense measures (e.g., SameSite Cookie) can mitigate both types of attacks.
• Automatic Protection in Modern Frameworks: Frameworks like Django and Spring Security default to supporting session identifier change upon login.