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:
Let's assume that sessions IDs are server-generated, and that they're stored and accessed from cookies, not passed around via
POST requests. The Rails guide in link #1 above describes the attack like this (summarized from source, emphasis mine):
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).
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.
As the new trap session is unused, the web application will require the user to authenticate.
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.