Cosa ho letto

Ho letto le seguenti risorse sulla risoluzione della sessione, ma ho ancora difficoltà a comprendere alcuni aspetti di questo tipo di vulnerabilità:

1. Guida alla sicurezza di Ruby on Rails § 2.7 Correzione della sessione .

2. Misura preventiva per il rilevamento degli attacchi di Session Fixation .

3. Attacco di correzione sessione .

4. Wikipedia: fissazione della sessione .

Supponiamo che gli ID di sessione siano generati dal server e che siano archiviati e accessibili dai cookie, non trasmessi tramite GET e POST richieste. La guida Rails nel link # 1 in alto descrive l'attacco come questo (riassunto dalla fonte, enfasi mia):

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.

Cosa non capisco

Ora ecco la parte che non capisco. Lasciando da parte il fatto che un'efficace contromisura contro questo attacco consiste semplicemente nel rilasciare un nuovo ID di sessione all'utente vittima quando accede al sito legittimo, perché il server legittimo richiede all'utente vittima di accedere comunque, anche se hanno già un ID di sessione "valido"?

Dopo tutto, l'utente malintenzionato ha mantenuto in anticipo la validità dell'ID sessione fissa (come indicato nel passaggio 2 nella guida alla sicurezza di Rails citata sopra), quindi perché il server non accetta solo l'ID sessione e il registro l'utente vittima nel sito web come utente malintenzionato? Perché sono necessarie di nuovo le credenziali di accesso?

Si noti che questa domanda non è specifica di Ruby on Rails. Si applica a qualsiasi implementazione di sessioni utente, in qualsiasi framework e linguaggio.