È corretto utilizzare il campo modulo (nascosto) per memorizzare il token di sessione invece di utilizzare i cookie? Qual è il rischio per la sicurezza ad esso associato?
Per essere protetti contro CSRF e allo stesso tempo indurire contro XSS, memorizzare gli ID di sessione nei cookie (con flag httpOnly) e utilizzare token separati per moduli associati alla sessione che si convalidano su POST. Combinando questi metodi, si impedisce a un utente malintenzionato che ha trovato XSS di rubare ID di sessione, mentre si protegge ancora contro CSRF in modo significativo. L'utilizzo dell'ID di sessione come token di modulo consente a un utente malintenzionato di rubare l'ID di sessione tramite XSS.
IMHO, lo svantaggio di gran lunga maggiore è che devi aggiungere esplicitamente del codice per ripopolare l'identificatore di sessione in ogni pagina, potenzialmente in più punti. L'utilizzo di un campo modulo funziona solo dove hai un modulo e questo è l'unico modo per uscire dalla pagina.
Quindi devi anche aggiungere del codice per analizzare ogni href sulla pagina e aggiungere l'id di sessione (dato che non vuoi inviare l'ID di sessione ad altri siti).
E le richieste di ajax? Navigazione basata su Javascript?
Dovresti anche cambiare l'ID della sessione all'autenticazione - così hai anche infranto il comportamento del pulsante Indietro.
Sì, puoi risolvere tutti questi problemi lanciando codice e impegno, ma più codice = più bug = meno sicurezza.
Un'altra considerazione è che alcune applicazioni utilizzano identificativi di sessione multipli - gestire questo al di fuori dei cookie sarebbe un PITA ancora più grande.
No, non si dovrebbero usare i parametri GET o POST per gli identificatori di sessione. L'ID sessione dovrebbe solo essere trasmesso tramite i cookie HttpOnly.
Ci sono almeno tre motivi per farlo:
Fissazione della sessione attacchi. L'utente malintenzionato può invogliare l'utente vittima a visitare una pagina con un modulo contenente il suo ID di sessione in un campo nascosto. Se invii il modulo, la vittima verrà autenticata come utente malintenzionato (e tutte le azioni che successivamente eseguirà sul sito web di destinazione verranno eseguite con le credenziali degli aggressori)
qualsiasi difetto XSS nel tuo sito web consentirà direttamente all'utente malintenzionato di sequestrare la sessione mentre l'ID della sessione in HttpOnly impedisce che ciò accada
attacchi di estrazione del contenuto - ci sono alcune tecniche di UI per la correzione per l'estrazione del contenuto HTML di un sito web di destinazione , quindi conducendo alla sessione dell'utente di dirottamento. Un esempio di tale attacco che richiede l'interazione dell'utente è Estrazione di accesso token Facebook , che implica la visualizzazione della sorgente HTML di un sito Web della vittima in un IFRAME invisibile e che attira l'utente per selezionarlo e trascinarlo nella textarea dell'utente malintenzionato; se l'ID di sessione è incluso nel documento HTML, questo rivela l'ID di sessione all'autore dell'attacco. Inoltre, quando il sito Web consente la comunicazione tra domini (ad esempio con l'uso di permissive crossdomain.xml), i contenuti possono anche essere recuperati tramite Flash senza l'interazione dell'utente. Pertanto, l'ID di sessione non dovrebbe mai essere visualizzato all'interno dell'origine della pagina HTML.
Per interrompere CSRF, è importante includere anche un token CSRF in un campo modulo nascosto o nell'URL di ogni richiesta POST. Tuttavia, il token CSRF non deve contenere l'ID di sessione ed è più sicuro se non contiene o rivela l'ID di sessione. Una scelta più sicura è utilizzare un nonce casuale o un hash unidirezionale dell'ID di sessione come token CSRF.
Tre approcci comuni per il trasferimento dell'identificatore di sessione tra browser e server
Tutti hanno i loro vantaggi e svantaggi, ma dal momento che hai chiesto informazioni su Hiddel Fields solo qui ci sono alcuni vantaggi e svantaggi
Questo è quello che riesco a pensare subito, altri possono indicare più vantaggi e svantaggi
E sì, presumo che tu abbia il tuo Session lato server di monitoraggio e codice di gestione e logica di logout scritti correttamente
Leggi altre domande sui tag session-management