problemi di sicurezza nello storage JWT

9

Sto creando un meccanismo di accesso JWT per un sito.

Ci sono due opinioni molto opposte su come conservare il JWT. Stormpath giura tramite cookie httponly: link Auth0 swear by localStorage: link

All'inizio mi sono schierato con Auth0, poi con Stormpath, ma ora sono tornato a pensare che localStorage sia il migliore. Le insidie di localStorage è un attacco xss in grado di catturare il JWT, la trappola di auth0 è che un attacco csrf può rubare il cookie.

Sembra che lo sviluppatore possa rendere il metodo dei cookie davvero difficile per l'hacker per ottenere l'accesso tramite CSRF, ma non impossibile. Tuttavia, se lo sviluppatore utilizza localStorage e gestisce il suo codebase e disinfetta i suoi input, sembra che l'hacker non abbia modo di entrare, è sbagliato?

    
posta user2331566 12.01.2017 - 13:41
fonte

3 risposte

4

L'argomento principale per la memorizzazione locale sembra essere questo:

it is easier to protect against XSS than protecting against XSRF

L'argomento per questo è che l'XSS è presumibilmente risolto con l'igienizzazione automatica degli input, mentre CSRF è difficile da capire.

Il secondo punto può o non può essere vero, ma - come afferma la tua fonte - la protezione completa contro CSRF è relativamente semplice. Se la tua applicazione è tranquilla, si tratta semplicemente di controllare tutte le richieste POST per un token CSRF *.

XSS d'altra parte non è così semplice. La sanificazione degli input non è la soluzione, codifica dell'output. E il problema è che questa codifica dipende dal contesto. Ad esempio, è necessaria una codifica diversa se ci si trova in un contesto JavaScript o HTML.

Mentre alcuni framework forniscono motori di template con codifica automatica, altri no. E la codifica automatica generalmente codifica solo HTML, ma non considera XSS in un contesto JavaScript. Aggiungendo a questo che molti sviluppatori saltano i motori dei template in alcuni casi e producono direttamente input dell'utente, direi che l'XSS è più difficile da difendere rispetto a CSRF.

* Questo è un po 'semplificato, e ci sono altre cose da considerare. L'iniezione HTML, ad esempio, può perdere i token CSRF e l'applicazione potrebbe effettivamente utilizzare le richieste GET per modificare lo stato del server.

Conclusione

Non sarei d'accordo sul fatto che l'XSS sia più facile da difendere rispetto a CSRF. Poiché questo è l'argomento principale per l'archiviazione locale, sceglierei l'approccio cookie. Fornisce una piccola attenuazione per XSS e ha anche il vantaggio di garantire che i dati rilevanti vengano inviati solo tramite HTTPS (tramite l'attributo cookie sicuro).

    
risposta data 12.01.2017 - 13:59
fonte
2

Nella mia esperienza di sviluppatore e tester di penna, direi che è probabilmente più facile lavorare con un framework di sviluppo web che ha una protezione integrata contro CSRF piuttosto che avere sviluppatori che proteggono correttamente contro XSS. Questo suggerirebbe la soluzione di Stormpath.

È probabile che tu voglia comunque proteggere contro entrambi gli attacchi.

    
risposta data 12.01.2017 - 13:51
fonte
0

Probabilmente usando una combinazione di entrambi è più sicuro perché ogni negozio ti protegge da una forma di attacco (XSS o CSRF). Ecco una bella recensione sullo stesso:

link

    
risposta data 15.10.2018 - 14:21
fonte

Leggi altre domande sui tag