Sessioni autenticate e Man in the middle

1

Vedo molti siti Web (incluso StackOverflow) che utilizzano questo meccanismo di autenticazione:

  1. Il client si autentica sotto HTTPS e ottiene un ID di sessione.
  2. Il client torna su HTTP e accede a pagine sicure usando HTTP, passando l'id della sessione per dimostrare che l'autenticazione ha avuto luogo.

Qual è il punto di utilizzo di HTTPS per proteggere l'autenticazione se il man-in-the-middle può semplicemente rubare l'ID di sessione risultante e agire come client autenticato? Capisco che alla fine la sessione scadrà ma che dà ancora all'attaccante una finestra piuttosto lunga di opportunità per attaccare.

    
posta Gili 25.05.2014 - 17:19
fonte

2 risposte

1

Poiché l'ID di sessione viene trasferito su una connessione HTTP non protetta, un utente malintenzionato sarà in grado di impersonare l'utente. Quello che non sa è la password degli utenti, il login è fatto con HTTPS.

Le password degli utenti dovrebbero essere protette anche meglio dell'accesso a un sito, perché spesso gli utenti riutilizzano le loro password su siti diversi. Con una tale password, anche altri siti (più importanti) sono compromessi.

In altre parole, con il passaggio tra HTTP e HTTPS si mette in pericolo solo il proprio sito, con l'invio di password su HTTP si mettono in pericolo anche altri siti. In caso di StackOverflow metterei in pericolo tutti i siti connessi con l'account OpenId degli utenti.

    
risposta data 26.05.2014 - 09:19
fonte
1

semplicemente può evitare perdite di nome utente / password. nel tuo scenario il MITM può evitare la sicurezza. in altre parole ingannare gli utenti.

tuttavia potrebbero esserci delle attenuazioni, come l'ID di sessione per IP / Paese. quindi se qualcuno da un'altra pagina di richiesta di ip (probabilmente qualcuno che ha MITMed l'id), la sessione scade.

    
risposta data 25.05.2014 - 19:47
fonte