La possibilità per un utente di scegliere il valore di un cookie di identificazione di sessione costituisce un difetto di sicurezza?

Sì, c'è un rischio in quanto si tratta di un classico problema di risoluzione della sessione ( Pagina OWASP ). Le buone pratiche standard per la gestione delle sessioni di applicazioni Web sono sempre quelle di ri-emettere un token di sessione casuale ogni volta che l'utente invia un accesso. Qualsiasi altra cosa (o non riemettere al login o consentire i valori del token di sessione impostati dall'utente) non è una buona idea.

Quanto di un problema dipende dal modo esatto in cui funziona l'applicazione e dall'ambiente utente. Alcuni esempi di questo è un rischio

• Molti siti Web hanno aree non autenticate che non sono crittografate. quindi se il token è impostato su questi e quindi non viene reindicato, il token può essere dirottato da un attacco di sniffing dei pacchetti (ad esempio su una rete wireless) prima che l'utente esegua l'accesso e quindi la sessione autenticata possa essere dirottata

• Se si accede all'applicazione da un ambiente PC condiviso, un utente malintenzionato in grado di impostare il valore del token in un browser aperto, sarebbe in grado di dirottare una sessione utente se utilizza il sistema senza chiudere e re- aprendo il browser (assumendo che il token venga cancellato quando il browser è chiuso).

Questo è un problema di sicurezza, ma non uno su cui si possa fare qualcosa in quanto il client può sempre impostare qualsiasi ID di sessione che desiderano. Se non esiste alcuna sessione lato server con quell'ID, è probabile che l'utente veda un messaggio sessione scaduta e sia obbligato ad autenticarsi.

Se un utente malintenzionato è in grado di ottenere l'ID sessione degli utenti legittimi, esiste la possibilità di un dirottamento della sessione impostando lo stesso ID sessione sul browser degli hacker e navigando verso il sito in questione.

HTTPS va in qualche modo a prevenire questo tipo di attacco fermando un tradizionale man nel mezzo il furto dell'ID di sessione.

Esistono altri metodi con cui un utente malintenzionato può ottenere l'ID di sessione di una vittima, ad esempio un attacco cross-site-scripting in applicazioni Web vulnerabili. In una tale applicazione è banale ingannare la vittima nell'aprire una pagina che può eseguire un javascript fornito da un aggressore che invia loro l'ID di sessione e consente loro di assumere la tua identità con quel servizio.

Non sono così preoccupato per un hacker che ha la possibilità di impostare l'ID di sessione prima del login come quando la vittima si autentica con l'applicazione web, la risposta imposterà un nuovo ID di sessione fornito da il server.

La maggior parte delle applicazioni web in questi giorni contengono anche misure secondarie per impedire il dirottamento di sessione attraverso altri cookie che contengono checksum con informazioni specifiche della macchina con hash in essi. Siti come Facebook consentono di specificare un elenco di dispositivi sicuri per prevenire questo tipo di attacchi.