Session Hijacking - rigenera l'ID di sessione

Ho visto implementazioni che hanno provato questo approccio e hanno finito per tirarlo perché sì, può causare problemi di risorse e condizioni di competizione tra le Web farm. All'inizio sembra una buona idea, ma può anche rendere l'applicazione più incline agli attacchi denial of service se il processo di rigenerazione è troppo crittografico. La risposta è di dover rilasciare periodicamente gli ID di sessione e mantenere una cache disponibile, ma in tal caso è necessario gestire la cache in modo sicuro.

Alcune soluzioni più comuni per proteggere le variabili ID di sessione è

• usa SSL
• genera solo l'ID di sessione autenticato dopo login riuscito su SSL, altrimenti diventi vulnerabile alla fissazione della sessione
• genera token crittografici casualmente e non gestibili
• scadono frequentemente gli ID di sessione
• scade correttamente quindi sul lato server alla disconnessione
• contrassegna il cookie dell'ID di sessione come HttpOnly e 'secure'

Suppongo che dipenda da come implementeresti tutto questo, ma la probabilità è che ti imbatterai in una serie di problemi di runtime che monitorano gli ID delle sessioni di modifica.

Sarebbe d'aiuto? Non proprio. Puoi spoofare REMOTE_ADDR e catturare l'id della sessione prima che cambi sia piuttosto semplice: prendilo e usalo prima che l'utente faccia un'altra richiesta.

L'idea migliore sarebbe quella di crittografare i valori del cookie, solo connettersi tramite HTTPS, impostare la durata del cookie su qualcosa di molto breve / impostare la durata della sessione su qualcosa di molto breve, impostare i cookie su HttpOnly (non accessibile tramite JavaScript - - solo parte dei nuovi browser però), e infine, usa la gestione della sessione framework - non eseguire il rollover. :)

Devi assicurarti che la tua sessione scada e che i token siano certamente affidabili e generati casualmente.

Tuttavia, da tutte queste risposte, penso che il punto più strong sia l'uso di SSL, ma per l'intera sessione.

Anche se si effettua il login via SSL e si utilizza il normale http da quel momento in poi, si rigenerano le sessioni da ogni richiesta successiva e si fanno tutti gli aspetti positivi menzionati sopra, non c'è davvero alcun modo per garantire che la sessione di un utente non possa essere dirottata in alcuni modo. Devi davvero assicurarti che il trasporto dell'intera sessione prevenga l'intercettazione e il dirottamento, per cui è stato progettato SSL.

L'uso di indirizzi remoti è anche piuttosto discutibile quando si tratta di firewall NATed.

Se è necessario fare un ulteriore passo avanti per garantire che la macchina di un particolare cliente sia l'unica macchina che può accedere, è possibile emettere un certificato client, che l'utente caricherà nel browser, e il server lo richiederà durante la negoziazione SSL.

Il migliore che ho visto nell'uso comune rigenera l'identificatore di sessione dopo l'accesso sicuro e associa l'identificatore al computer client. Il wrapper di sicurezza dell'applicazione controlla gli accessi simultanei (disabilitando uno nuovo fino a quando il vecchio non ha finito e l'ID è scaduto) e scade l'ID al browser in chiusura o in uscita e ha anche una scadenza piuttosto breve (10 minuti)

In combinazione con le altre funzionalità di sicurezza era appropriato allo scopo (un'applicazione di consumer banking online) senza sovraccaricare il sistema.