The session fixation demo explained

A session fixation attack must be tailored to how the target application initializes sessions. In this demo app, a user's session is initialized when the user authenticates. Consequently, we're hoping to set the victim's session ID before the victim logs in. Sensitive data for the victim will be written to session once the victim logs in.

To show that a user's authentication cookies — these can be Forms Authentication or WIF cookies — are unrelated the ASP.NET session cookie, this site requires the user to log in.

  1. Log in as the attacker.
    • The attacker will get her session initialized with the attacker's data.
    • The attacker switches to a new random session ID to get a new uninitialized session. This ensures that the victim under no circumstance would get the attacker's session — that would be slightly embarrasing.
  2. Fix victim's session.
    • The attacker sets the session ID of the uninitialized session in the victim's browser.
    • You'll see that the attacker has several options for doing this, feel free to try them all!
  3. Wait for the victim to log in and populate the (now) shared session with the victim's data.
    • The attacker will periodically update the webpage on her end to see when the victim has logged in.
  4. Have a look at the victim's session data.
    • Success! You da hacker!

Are you ready? Then start the attack, you'll have to log in if you haven't already.