Come ha detto @Arminus in un commento, questa non è la fissazione della sessione. La fissazione della sessione è attualmente relativamente rara, perché si basa su un comportamento ora (per fortuna) ampiamente riconosciuto come insicuro / stupido: quando si accede, il server conserva il vecchio token (JSESSIONID, in questo caso) piuttosto che generarne uno nuovo. Un utente malintenzionato può abusarne conoscendo il vecchio valore del token (ad esempio, poiché era l'ultimo utente) e quindi disconnettendosi e aspettando che un nuovo utente venga; quando il nuovo utente esegue l'accesso, mantiene il vecchio token.
Una vulnerabilità della sicurezza richiede che qualcuno faccia qualcosa che non è autorizzato a fare. Nello scenario, come diavolo l'utente nonAdmin trova JSESSIONID dell'amministratore? Se sono la stessa persona, allora l'utente è (presumibilmente) già autorizzato ad accedere come amministratore - lo ha fatto sull'altra macchina, dopotutto - quindi nessun bypass di sicurezza si è verificato . Se non sono la stessa persona, il nonAdmin ha rubato il JSESSIONID dell'amministratore (nel qual caso la vulnerabilità della sicurezza è in come l'hanno rubata , che potrebbe essere colpa tua o potrebbe essere dovuta al computer dell'utente Admin ha spyware), oppure l'utente Admin ha condiviso il JSESSIONID con il nonAdmin (il che significa che l'amministratore, in sostanza, sostituisce il nonAdmin come utente temporaneo dell'account dell'amministratore).
I token di autenticazione (JSESSIONIDs, nel tuo caso) hanno un certo numero di proprietà critiche. Il seguente elenco non è in ordine particolare. I relativi qui sono evidenziati:
- Sono generati in modo sicuro (cioè non utilizzare
java.util.Random , che ha un output prevedibile; usa java.security.SecureRandom ). Alcune implementazioni utilizzano stringhe di informazioni utente crittografate invece di token casuali; questo ha alcuni rischi per la sicurezza piuttosto brutti.
- Sono abbastanza lunghi da non poter essere forzati brute (64 bit sono generalmente visti come borderline: 128 bit e oltre sono buoni).
-
Non vengono mai riutilizzati, quindi un utente malintenzionato che ne vede uno vecchio non può utilizzarlo per ottenere la sessione di qualcun altro. Poiché tenere traccia di tutti i token delle vecchie sessioni non è possibile, la soluzione è di nuovo usa un token (casuale) abbastanza lungo che le probabilità di una collisione sono infinitesimali (e se esprimi le probabilità che ciò accada usando parole come "miliardi", non è abbastanza infinitesimale).
- Devono essere verificati in modo costante (altrimenti la forzatura bruta di un token valido diventa lineare nella sua lunghezza, piuttosto che esponenziale).
-
Non devono essere condivisi tra livelli di privilegi o sessioni per un determinato utente. Ogni volta che un utente si autentica di nuovo, il vecchio token deve essere invalidato e ne viene utilizzato uno nuovo.
-
L'invalidazione del token deve avvenire sul server. Se un utente si disconnette o la sua sessione scade (o termina in altro modo), il server non deve più riconoscere il token come valido. L'eliminazione del token dal client è non sufficiente.
- I token non devono mai essere inviati in un URL, solo nelle intestazioni o se necessario nei corpi dei messaggi. Anche su HTTPS, gli URL tendono a perdere (potrebbero essere registrati dai proxy, inclusi nelle intestazioni dei referrer o salvati nella cronologia del browser, tra gli altri rischi). Se un valore sicuro deve deve essere inviato in un URL, deve essere solo monouso e invalidato dopo il primo tentativo di utilizzarlo, indipendentemente dal fatto che l'utente abbia completato la propria azione e debba anche scadere. molto rapidamente.
- I token non devono mai essere inviati su connessioni non sicure. Se il tuo sito supporta HTTPS, il token non deve mai essere inviato tramite una connessione non HTTPS (un modo semplice per assicurarsi che questo sia il token in un cookie e impostare il flag
secure su quel cookie). Se il tuo sito non supporta HTTPS, quindi tratta le sessioni solo come comodità; non c'è una vera sicurezza lì. ( Sì, guardandoti, SE comportamento predefinito post-autenticazione ... )
Probabilmente me ne dimentico, ma un elenco completo non è il punto centrale qui. Tuttavia, come puoi vedere, ci sono un sacco di cose (alcune correlate, alcune indipendenti) richieste per un token di autenticazione sicuro, che è solo una componente di un sito sicuro. Devi farli tutti; un link debole di solito è sufficiente per l'attacco di un utente malintenzionato.