it-swarm-eu.dev

La raccomandazione OWASP relativa al deposito locale è ancora valida?

Attualmente sto lavorando a un'applicazione che è un'applicazione a pagina singola costruita con Angular. Viene servito su HTTPS, usando HSTS.

Per l'autenticazione, stiamo usando Auth0. La documentazione di Auth consiglia di archiviare il token di accesso nell'archivio locale.

Un intercettore viene quindi utilizzato per aggiungere questo all'intestazione di ogni richiesta HTTP.

Tuttavia, questa risposta consiglia di non archiviare informazioni riservate con localstorage.

La risposta è del 2011 e l'autore ha anche co-scritto il cheat sheet OWASP HTML5, in cui si afferma:

Presta particolare attenzione alle chiamate "localStorage.getItem" e "setItem" implementate nella pagina HTML5. Aiuta a rilevare quando gli sviluppatori creano soluzioni che mettono informazioni riservate nella memoria locale, il che è una cattiva pratica.

Mi chiedo se la situazione nel 2017/2018 sia cambiata. Sono OK a seguire le linee guida di Auth0 o devo adottare un altro approccio?

49
JMK

Personalmente non vedo alcun problema con l'utilizzo dell'archiviazione locale, purché tu sia soddisfatto del fatto che l'utente non debba eseguire nuovamente l'autenticazione tra le sessioni. La risposta collegata fornisce il seguente argomento contro questo. Direi che è molto debole -

Il meccanismo di archiviazione sottostante può variare da un agente utente a quello successivo. In altre parole, qualsiasi autenticazione richiesta dall'applicazione può essere ignorata da un utente con privilegi locali alla macchina su cui sono archiviati i dati. Pertanto, si consiglia di non archiviare alcuna informazione sensibile nella memoria locale.

Questo vale per qualsiasi tipo di token di autenticazione. Qualcuno locale con privilegi di amministratore (supponendo che non sia crittografato con una chiave legata alle credenziali degli utenti) può leggerlo da qualsiasi tipo di memoria, RAM o forse anche direttamente dalla rete.

Suggerisce anche -

(o difetto XSS nel sito Web)

Ancora una volta: questo vale per qualsiasi tipo di token a cui JavaScript può accedere.

51
Hector

Il motivo per cui l'archiviazione locale è considerata non sicura è perché qualsiasi JavaScript eseguito nel contesto della pagina può accedervi. Questo ti apre al dirottamento della sessione tramite XSS riflettente e vulnerabilità XSS memorizzate, potenzialmente divulgazione di informazioni a seconda del contenuto del token.

Ad esempio: se un utente accede a una pagina con contenuti condivisi tra altri utenti e esiste una vulnerabilità XSS memorizzata, un altro utente può iniettare un attacco che ruba il token dal deposito locale.

La breve scadenza protegge solo il token dagli attacchi di replay, ma se esiste una vulnerabilità XSS con accesso allo store locale, ciò non avrà alcun effetto sulle sessioni attive poiché è possibile scrivere un meccanismo di polling per estrarre nuovamente il token dallo store locale allo scadere

Ti suggerisco di utilizzare un cookie come memoria per il tuo token.

  • I cookie possono essere contrassegnati solo come HTTP. Ciò impedirà a JavaScript di accedere al cookie
  • Sul server, fai in modo che il tuo codice estragga il token dal cookie e quindi lo convalidi
  • Contrassegnalo anche come Sicuro solo per HTTPS

Spiacenti, non hai abbastanza punti per rispondere, quindi lascia perdere qui:

Un'altra considerazione, qual è il tuo modello di minaccia? Utenti malintenzionati esterni sul Web: archivia il token in un processo cookie sul server Utenti sullo stesso computer (non amministratore): forse l'archiviazione della sessione quindi nessuna persistenza Amministratore locale: Beh niente - sono amministratori locali, possiedono il sistema

La certificazione client non è in realtà un elemento di autenticazione praticabile per le applicazioni Web come utente: gli autenticatori MFA sono l'alternativa migliore

12
McMatty

Seguendo i consigli di il blog auth è possibile contrastare i problemi di sicurezza mantenendo un valore di scadenza del token basso e, soprattutto, è possibile crittografare il token.

Un approccio alternativo sarebbe l'uso dei token Web JSON in associazione con OAuth2.

3
Stefan

Non sono sicuro al 100%. Ne ho letto qualcos'altro.

Il problema con "informazioni token sensibili" è lo stesso problema, sia esso un cookie o un archivio locale.

Ma puoi salvare molti più dati nella memoria locale, il che potrebbe far apparire l'idea, che è una buona idea archiviare tutte le informazioni bancarie, tutti i trasferimenti, ecc. (Per favore inserisci altre informazioni rischiose ascolta. Medico, giudiziario, ... ) nella memoria locale, così puoi accedervi offline.

Il rischio per la sicurezza di un cookie o di una sessione è mitigato da un timeout della sessione sul lato server. Ma l'archiviazione locale non ha un timeout. Quindi, se memorizzi qualcosa nella memoria locale, preparati, che rimanga lì per sempre. Se non vuoi che tutti coloro che hanno accesso alla macchina siano in grado di leggerlo, assicurati di eliminarlo e assicurati che il tuo meccanismo funzioni in "ogni circostanza" (qualunque cosa ciò significhi nel contesto di archiviazione locale - quindi non è possibile. Ma sono uno sviluppatore php, per favore correggimi.)

2