Lo que he leído

He leído los siguientes recursos sobre la fijación de la sesión, pero todavía tengo dificultades para comprender algunos aspectos de este tipo de vulnerabilidad:

1. Guía de seguridad de Ruby on Rails § 2.7 Fijación de sesión .

2. Medida preventiva para detectar ataques de fijación de sesión .

3. Ataque de fijación de sesión .

4. Wikipedia: Fijación de sesión .

Supongamos que los ID de las sesiones son generados por el servidor, y que se almacenan y se accede a ellos desde cookies, no se transfieren a través de las solicitudes GET y POST . La guía de Rails en el enlace # 1 anterior describe el ataque de esta manera (resumido de la fuente, el énfasis es mío):

  

    

1. ElatacantecreaunIDdesesiónválido:carganlapáginadeiniciodesesióndelaaplicaciónwebdondedeseancorregirlasesiónytomanelIDdesesiónenlacookiedelarespuesta(consultelosnúmeros1y2enlaimagen).

  

2. Posiblementemantienelasesión.Lassesionesqueexpiran,porejemplocada20minutos,reducenengranmedidaelmarcodetiempoparaelataque.Porlotanto,accedenalaaplicaciónwebdevezencuandoparamantenervivalasesión.

  

3. AhoraelatacanteforzaráalnavegadordelusuarioausaresteIDdesesión(verelnúmero3enlaimagen).Comonopuedecambiarunacookiedeotrodominio(debidoalamismapolíticadeorigen),elatacantedebeejecutarunJavaScriptdesdeeldominiodelaaplicaciónwebdedestino.

  

4. ElatacanteatraealavíctimaalapáginainfectadaconelcódigoJavaScript.Alverlapágina,elnavegadordelavíctimacambiaráelIDdesesiónalIDdesesióntrampa.

  

5. Comolanuevasesióndecapturanoestáenuso,laaplicaciónwebrequeriráqueelusuarioseautentique.

  

6. Deahoraenadelante,lavíctimayelatacanteutilizaránlaaplicaciónwebenlamismasesión:lasesiónsehizoválidaylavíctimanonotóelataque.

  

Loquenoentiendo

Ahoraaquíestálapartequenoentiendo.DejandodeladoelhechodequeunacontramedidaefectivacontraesteataqueessimplementeemitirunnuevoIDdesesiónalusuariovíctimacuandoiniciesesiónenelsitiolegítimo,¿porquéelservidorlegítimorequierequeelusuariovíctimainiciesesión?¿Detodosmodos,aunqueyatienenunIDdesesión"válido"?

Después de todo, el atacante ha estado manteniendo la validez de la ID de sesión fija de antemano (como se señaló en el paso # 2 de la guía de seguridad de Rails citada anteriormente), ¿por qué el servidor no acepta la ID de sesión y el registro? el usuario víctima en el sitio web como atacante? ¿Por qué se requieren las credenciales de inicio de sesión nuevamente?

Tenga en cuenta que esta pregunta no es específica de Ruby on Rails. Se aplica a cualquier implementación de sesiones de usuario, en cualquier marco e idioma.