Le sessioni possono essere gestite in modo sicuro con i cookie disabilitati?

Question

Le sessioni possono essere gestite in modo sicuro con i cookie disabilitati?

#1 da (2 voti)
#2 da (0 voti)

2

Ho letto alcune letture sulla gestione degli ID di sessione e ho appreso che generalmente è una cattiva idea includere un ID di sessione nel codice sorgente HTML e / o nella stringa di query. Ad esempio È corretto utilizzare il modulo campo (nascosto) per la memorizzazione del token di sessione e Perché passare l'id della sessione come parametro url non sicuro?

Con questo in mente, c'è un modo sicuro per gestire le sessioni se i cookie sono disabilitati?

Ad esempio, ho notato che il carrello della mia azienda inserisce gli ID di sessione in un campo modulo nascosto (per l'azione Aggiungi al carrello), e se i cookie sono disattivati vengono aggiunti anche per interrogare le stringhe per tutti i collegamenti. Ho controllato una pagina google memorizzata nella cache e abbastanza sicuro che Google avesse memorizzato nella cache il proprio ID di sessione. Ho quindi afferrato quell'ID di sessione e visitato il carrello di Google - che era scaduto a quest'ora. Tuttavia, ovviamente non sono un fan di ciò che è possibile in primo luogo.

Su una nota correlata, quando ho incollato il primo link sopra, originariamente incluso? newreg = XXXXXXX (sembrava un ID di sessione di qualche tipo). Mi ero appena registrato per security.stackexchange.com e sono stato riportato a quell'URL. Forse non è un problema, ma ho pensato che fosse un bell'esempio casuale di come gli ID di sessione possano essere accidentalmente condivisi.

cookies session-management session-fixation

posta Mike Willis 30.01.2014 - 19:16

fonte

2 risposte

Leggi altre domande sui tag cookies session-management session-fixation

Bancomat infettati da malware in Cina tramite dispositivo specializzato La politica di blocco dell'account ha senso?

score 2 · Answer 1

Direi che dipende dal tuo caso d'uso. Se si guarda una richiesta POST HTTP ci sono essenzialmente tre aree in cui i dati possono essere inseriti, le intestazioni, l'URL e il corpo della richiesta.

Se escludiamo di mettere il token nel corpo della richiesta o nell'URL, questo ci lascia con le intestazioni delle richieste come luogo in cui inserire il token di autenticazione.

Esistono schemi esistenti che fanno uso di questo, ad esempio Autenticazione di base HTTP, Autenticazione del digest e Autenticazione NTLM.

Tuttavia ognuno di questi ha aspetti negativi e se sono appropriati / sicuri per la propria applicazione dipenderà dall'applicazione, dal modello di minaccia e dalla popolazione di utenti.

Se, ad esempio, si sta parlando di un'applicazione aziendale interna in cui tutte le macchine client eseguono varianti di Windows, l'autenticazione NTLM sarebbe probabilmente una buona idea.

Se invece stai guardando ad un sistema di e-commerce generale con una varietà di sistemi operativi per l'utente finale, non lo sarebbe.

score 0 · Answer 2

C'è un modo sicuro che hai toccato: inserire gli ID di sessione in campi di moduli nascosti. Tuttavia, devono essere inviati da POST (vale a dire nel corpo della richiesta).

Lo svantaggio di questo approccio è che è necessaria un'azione di navigazione ogni per inviare un modulo.

Ad esempio potremmo avere un modulo per gestire la navigazione su ogni pagina costruita in questo modo:

<form method="post" action="/navigate">

    <input type="hidden" name="navigationPage" />
    <input type="hidden" name="sessionId" value="12345678" />

</form>

Con un clic all'interno della navigazione JavaScript verrà eseguito e impostato navigationPage sul valore appropriato (ad esempio myAccount , orderHistory , ecc.) e quindi inviare il modulo. L'URI /navigate verificherà sessionId e quindi passerà alla pagina specificata in navigationPage se la sessione è valida. Usando questo metodo ogni pagina all'interno della sessione di accesso avrà lo stesso URI ( www.example.com/navigate in questo caso).

Questo è sicuro in quanto l'ID di sessione non sarà trapelato in referer di intestazioni nel caso di link esterni. I collegamenti esterni possono semplicemente collegarsi direttamente alla risorsa e non saranno il modulo POST utilizzato dalla navigazione interna.

Molti sistemi bancari utilizzano una tecnica simile per una protezione extra contro il dirottamento di sessione all'interno della sessione. In questi scenari, sessionId nel campo modulo nascosto verrà rigenerato su ogni caricamento di pagina che garantisce che solo un singolo browser Web stia navigando contemporaneamente. Tuttavia, ciò impedirà l'utilizzo del pulsante Indietro perché impone una nuova presentazione dei dati POST o l'apertura di collegamenti in schede separate del browser, in quanto l'ID rolling non verrà aggiornato in entrambe le posizioni. Questo è spesso usato in combinazione con i cookie di sessione, ma può essere usato in isolamento. Le azioni che richiedono informazioni aggiuntive come i trasferimenti di denaro possono semplicemente includere campi di moduli aggiuntivi da inviare con il modulo principale.

Un altro vantaggio di questo approccio è che è intrinsecamente sicuro contro CSRF . Se un'altra pagina effettua una richiesta cross site, mancherà il sessionId perché non verrà inviata automaticamente allo stesso modo dei cookie.