Understanding Session Fixation Vulnerability

Question

What I've Read

I'm read the following resources on session fixation, but I'm still having difficulty understanding some aspects of this kind of vulnerability:

1. Ruby on Rails Security Guide § 2.7 Session Fixation.

2. Preventive Measure for detecting Session Fixation attacks.

3. Session fixation attack.

4. Wikipedia: Session fixation.

Let's assume that sessions IDs are server-generated, and that they're stored and accessed from cookies, not passed around via GET and POST requests. The Rails guide in link #1 above describes the attack like this (summarized from source, emphasis mine):

1. The attacker creates a valid session id: They load the login page of the web application where they want to fix the session, and take the session id in the cookie from the response (see number 1 and 2 in the image).

2. They possibly maintains the session. Expiring sessions, for example every 20 minutes, greatly reduces the time-frame for attack. Therefore they access the web application from time to time in order to keep the session alive.

3. Now the attacker will force the user's browser into using this session id (see number 3 in the image). As you may not change a cookie of another domain (because of the same origin policy), the attacker has to run a JavaScript from the domain of the target web application.

4. The attacker lures the victim to the infected page with the JavaScript code. By viewing the page, the victim's browser will change the session id to the trap session id.

5. As the new trap session is unused, the web application will require the user to authenticate.

6. From now on, the victim and the attacker will co-use the web application with the same session: The session became valid and the victim didn't notice the attack.

What I Don't Understand

Now here's the part that I don't understand. Leaving aside the fact that an effective counter-measure against this attack is to simply issue a new session ID to the victim user when they login to the legitimate site, why does the legitimate server require the victim user to login anyways, even though they already have a "valid" session ID?

After all, the attacker has been maintaining the validity of the fixed session ID beforehand (as pointed out in step #2 in the Rails security guide quoted above), so why wouldn't the server just accept the session ID and log the victim user into the website as the attacker? Why are login credentials required again?

Note that this question is not specific to Ruby on Rails. It applies to any implementation of user sessions, in any framework and language.

Answer 1

The attacker never logs into the site with their credentials, they just access a page to get the session id, so while they pass on a valid session id to the victim, they do not pass on an authenticated session. When the victim logs into the site, the session is now authenticated and the attacker can access it as the victim.