Autenticazione con JWT

Naviga le tue risposte
3

Sto costruendo SPA (React / Redux) e ho bisogno dell'autenticazione dell'utente. Ho trovato discussioni simili, ma non ho trovato risposte alle domande che ho delineato di seguito. Ecco alcune opzioni che ho trovato per implementare:

Opzione 1: mantiene JWT in localStorage

Attacco CSRF : non vulnerabile, poiché i cookie non vengono utilizzati.

Attacco XSS : vulnerabile. Qualsiasi codice JS nel front-end sarà in grado di rubare il token e inviarlo all'attaccante. Con Content-Security-Policy abilitato, attaccato non può rubare / inviare a se stesso jwt, ma può comunque effettuare richieste direttamente dal browser client.

Opzione 2: mantiene JWT in cookie ( secure e http-only )

Attacco CSRF : vulnerabile. Il cliente può seguire il sito Web dannoso, che farà richiesta subdola, cookie allegato, requst riuscito.

Attacco XSS : vulnerabile. I cookie non possono essere letti da JS, ma tramite JS attacker è sufficiente effettuare richieste di back-end validi, i cookie vengono automaticamente allegati e tutte le richieste avranno esito positivo.

Opzione 3: mantenere JWT (con xsrf_token set) nel cookie + mantenere xsrf_token nel cookie LocalStorage / JS-leggibile

La soluzione è basata su questo e simile a Double Submit Cookies Method

Attacco CSRF : non vulnerabile. Se il client segue il sito Web dannoso, il che rende subdola la richiesta, tale richiesta verrà eliminata, poiché xsrf_token non è stato trasmesso dal browser del client insieme al cookie. E poiché il cookie non è visibile all'attaccante (viene fornito direttamente dal browser client), non può rendere falso xsrf_token da allegare alla richiesta.

Attacco XSS : vulnerabile. xsrf_token nel cookie localStorage / JS-leggibile può essere letto dagli hacker JS. Quindi, un utente malintenzionato sarà in grado di effettuare richieste maligne direttamente dal suo JS iniettato dal browser dei client.

Inizialmente, volevo usare l'opzione 1. Ma ero interessato all'XSS, quindi ho iniziato a cercare alternative. Questo articolo e numero di altri sconsiglia di localStorage e consiglia di utilizzare la protezione di Cookie + CSRF.

L'opzione 3 sembra la soluzione popolare, dai dati raccolti, ma ha ancora l'XSS come l'opzione 1 - JS iniettato può effettuare richieste maligne direttamente dal browser client. L'unico vantaggio è che nell'opzione 1 i dati codificati JWT sono leggibili dall'utente / utente malintenzionato, mentre nell'opzione 3 non lo è (come memorizzato nel cookie). domanda correlata

Q1. Ci sono altri vantaggi dell'opzione 3 rispetto all'opzione 1?

Q2. Se vado con l'Opzione 3, sto introducendo alcuni altri vettori di attacco, che non ho ancora considerato?

Q3. Esiste un altro modo per mitigare CSRF, invece di mantenere lo stato in front-end (localStorage / sessionStorage / Redux store / JS-readable cookie) che è sempre vulnerabile a XSS?

So che non c'è nessun proiettile magico in sicurezza. Ma forse ci sono altri approcci / opzioni a questo problema? Per rimuovere XSS, devi andare in modalità cookie completa. Ma per andare solo ai cookie, è necessario avere comunque xsrf_token nel front-end dell'utente (localStorage / sessionStorage / Redux store / cookie leggibile da JS), che è vulnerabile all'XSS. Sembra un problema di catch-22.

    
posta Ilya 15.05.2018 - 08:11
fonte

1 risposta

2

Iniziamo con la parte facile: l'opzione 2 è una non-opzione. Viene fornito senza protezione CSRF, quindi è intrinsecamente vulnerabile. In realtà, l'opzione # 3 è praticamente l'opzione n. 2 con la protezione CSRF in cima. Quindi hai ragione a focalizzare la tua domanda sulla scelta tra # 1 e # 3.

Are there any other benefits of Option 3 over Option 1?

Non proprio. E non sono sicuro che il vantaggio che hai menzionato, essendo in grado di proteggere il JWT con la bandiera Http-Only, sia un grande vantaggio.

Essere in grado di rubare il JWT è conveniente per l'aggressore, dal momento che può quindi fare tutto quello che vuole fare dal proprio computer. Ma data una vulnerabilità XSS, tutto ciò che poteva fare sul proprio computer con il JWT, può anche fare dal computer delle vittime usando script iniettati. Questo potrebbe essere un po 'più fastidioso per l'attaccante, ma non fermerebbe un determinato avversario.

Quindi, alla fine, penso che la scelta tra il primo e il terzo sia principalmente una delle preferenze personali. Personalmente mi piace di più il # 1, perché lo trovo più pulito e più diretto. Inoltre si prende cura della situazione CSRF in modo pulito, senza che io debba alzare un dito.

If I go with Option 3, am I introducing some other attack vectors, that I havent't considered yet?

Forse.

In generale, un punto debole con il pattern di cookie double submit è che consente attacchi di sottodominio . Questo è in qualche modo mitigato dall'uso di un JWT. Dal momento che è firmato, un dominio di pari livello non può riscrivere quel cookie. Ma (almeno in alcuni browser) un sottodominio potrebbe leggerlo e quindi eseguire un attacco CSRF. L'utilizzo di un'intestazione HTTP anziché di un campo modulo per il doppio invio renderebbe questo attacco molto più difficile, se non impossibile (escludendo qualcosa come un exploit Flash).

Si noti che la sicurezza di questa opzione si basa completamente sul diritto a ottenere la protezione CSRF corretta.

Is there any other way of CSRF mitigation, instead of keeping state in front-end (localStorage/sessionStorage/Redux store/JS-readable cookie) which is always vulnerable to XSS?

No. Se sei vulnerabile all'XSS, tutte le protezioni CSRF escono dalla finestra. E non importa. Perché se posso fare XSS, non ho più bisogno di CSRF. Quindi provare a trovare un modo per proteggere da CSRF in caso di XSS non è solo impossibile, è anche inutile.

Ogni minuto che passi a pensare a come proteggere il tuo token CSRF in caso di un attacco XSS è un minuto che dovresti aver speso cercando di fermare gli attacchi XSS.

    
risposta data 15.05.2018 - 13:20
fonte

Leggi altre domande sui tag

Gestione di password e dati importanti in una piccola azienda con particolare attenzione alla business continuity È possibile ignorare la restrizione dell'accesso USB inserita da Active Directory? [chiuso]