È corretto utilizzare il campo modulo (nascosto) per memorizzare il token di sessione

4

È 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?

    
posta WxyZ 22.11.2011 - 04:46
fonte

4 risposte

12

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.

    
risposta data 22.11.2011 - 11:22
fonte
6

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.

    
risposta data 22.11.2011 - 11:50
fonte
6

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.

    
risposta data 22.11.2011 - 13:39
fonte
-1

Tre approcci comuni per il trasferimento dell'identificatore di sessione tra browser e server

  1. Cookie
  2. Campi nascosti
  3. URL

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

  • Adv: meno incline a CSRF poiché l'identificatore di sessione non viaggerà in cookie e non verrà inviato implicitamente dal browser
  • DisAdv: se lo sviluppatore utilizza un metodo GET o aggiunge il parametro all'URL, l'identificativo della sessione verrà esposto nella cronologia del browser, nei registri del proxy, nei registri del server Web ecc.
  • DisAdv: identificatori di sessione memorizzati nella cache insieme alla pagina se la memorizzazione nella cache non è disabilitata
  • Adv: non devi preoccuparti di marcare cookie sicuri o HTTPOnly ecc. o preoccuparti della scadenza dei cookie
    • DisAdv: devi rispedirlo in tutte le risposte, aumentando la dimensione della tua risposta
    • Adv: non devi preoccuparti che i cookie vengano disabilitati sui browser degli utenti

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

    
risposta data 22.11.2011 - 07:59
fonte

Leggi altre domande sui tag