Session Hijacking attraverso sessionId brute-forcing possibile?

Session Hijacking through sessionId brute-forcing possible?

Probabilmente no.

owasp dice che un identificatore di sessione dovrebbe essere lungo almeno 128 bit per impedire bruteforcing di sessione. Forniscono questi calcoli di esempio:

With a 64 bit session identifier, assume 32 bits of entropy. For a large web site, assume that the attacker can try 1,000 guesses per second and that there are 10,000 valid session identifiers at any given moment. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is less than 4 minutes.

Now assume a 128 bit session identifier that provides 64 bits of entropy. With a very large web site, an attacker might try 10,000 guesses per second with 100,000 valid session identifiers available to be guessed. Given these assumptions, the expected time for an attacker to successfully guess a valid session identifier is greater than 292 years.

Anche supponendo che un utente malintenzionato possa eseguire 10 milioni di tentativi al secondo, impiegherebbe comunque 3 mesi per ottenere un ID valido nell'ultimo esempio dato.

L' ID di sessione di PHP ad esempio sembra essere 160 bit per default (penso che la documentazione non sia così buona), puoi anche impostare da solo .

How can I, as an application developer, prevent this ?

Oltre all'utilizzo di un ID abbastanza strong, puoi anche associare una sessione a un IP o collegarlo a un sessione TLS , in questo modo, anche se un utente malintenzionato ottiene la sessione (tramite bruteforcing o in un modo diverso), non può usarlo. E potresti anche bloccare gli IP che stanno usando troppi tentativi con ID di sessione non validi.

La risposta di tim su entropia è perfetta sul tema della forzatura bruta del sessionId.

Ma nota, ci sono modi più semplici per rubare la sessione. Ad esempio, se si rilascia la sessione su HTTPS (autenticazione) ma si torna a HTTP, ora la sessione viene esposta in testo non crittografato. Tutto ciò che va su HTTP può essere assunto è urlato ad alta voce e aperto a tutti coloro che stanno ascoltando sulla linea.

Un attacco mirato può indurre un utente a fare clic su un URL HTTP sul sito Web di destinazione e l'autore dell'attacco intercetta le intercettazioni finché l'utente non fa clic sull'URL e invia la sessione su HTTP. è per questo che dovresti impostare il flag di sicurezza per la tua sessione per assicurarti che non venga inviato a meno che non sia su HTTPS.

È possibile associare la sessione a IP, ma si noti che molti utenti possono condividere lo stesso IP se si trovano dietro un NAT. Quindi non è davvero una grande soluzione di sicurezza.

Anche se hai l'intera sessione su SSL, le vulnerabilità nel browser potrebbero consentire il furto della sessione; Lo scripting di Cross Site può rubare la sessione. Per sicurezza, è necessario correggere tutti questi problemi, ma alla fine della giornata, si supponga che la sessione possa essere rubata e ora pensa cosa?

Una soluzione avanzata per il dirottamento della sessione è un token di sincronizzazione; in questo modo, ogni volta che il browser client effettua una richiesta HTTP sul server, il server invia un nuovo token abbastanza complesso al client come valore del campo modulo nascosto e il client deve inviare questo valore nella richiesta successiva come valore nascosto della forma. Se il client invia la sessione corretta (ad es. Rubata dal cookie), ma non ha il token di sincronizzazione più recente, allora c'è qualcosa di sbagliato. Questa soluzione impedisce anche la contraffazione delle richieste tra siti. Se sei su SSL, questa soluzione non può essere infranta dall'uomo nel mezzo.