Conosco l'autenticazione basata su cookie. È possibile applicare flag SSL e HttpOnly per proteggere l'autenticazione basata su cookie da MITM e XSS. Tuttavia, saranno necessarie ulteriori misure speciali per proteggerlo dal CSRF. Sono solo un po 'complicati. ( riferimento )

Di recente, ho scoperto che JSON Web Token (JWT) è piuttosto caldo come soluzione per l'autenticazione. Conosco le cose su codifica, decodifica e verifica di JWT. Tuttavia, non capisco perché alcuni siti Web / tutorial non diano alcuna protezione CSRF se viene utilizzato JWT. Ho letto parecchio e provo a riassumere i problemi di seguito. Voglio solo che qualcuno possa fornire il quadro generale di JWT e chiarire i concetti che ho frainteso su JWT.

1. Se il JWT è memorizzato nei cookie, penso che sia uguale all'autenticazione basata sui cookie, tranne per il fatto che il server non ha bisogno di sessioni per verificare il cookie / token. C'è ancora rischio riguardo al CSRF se non viene implementata alcuna misura speciale. JWT non è memorizzato nei cookie?

2. Se il JWT è archiviato in localStorage / sessionStorage, allora nessun cookie quindi non è necessario proteggerlo da CRSF. La domanda è: come inviare JWT al server. Ho trovato qui suggerisce di utilizzare jQuery per inviare il JWT tramite intestazione HTTP delle richieste Ajax. Quindi, solo le richieste Ajax possono fare l'autenticazione?

3. Inoltre, ho trovato un altro show sul blog per utilizzare "Intestazione autorizzazione" e "Portatore" per inviare il JWT. Non capisco il metodo di cui parla il blog. Qualcuno potrebbe spiegare di più su "Intestazione autorizzazione" e "Portatore"? Questo rende il JWT trasmesso dall'intestazione HTTP di TUTTE le richieste? Se sì, che ne dici di CSRF?

I token JWT sono popolari poiché vengono utilizzati come formato token predefinito nei nuovi protocolli di autorizzazione e autenticazione come OAuth 2.0 e OpenID Connect .

Quando il token viene archiviato in un cookie, il browser lo invierà automaticamente con ogni richiesta allo stesso dominio e questo è ancora vulnerabile agli attacchi CSRF.

L'autenticazione al portatore è uno degli schemi di autenticazione definiti in HTTP. Fondamentalmente significa che YOUattaccare il token (JWT) nell'intestazione HTTP di autorizzazione di una richiesta. Il browser lo NOTfarà automaticamente per te, quindi non è adatto a proteggere il tuo sito web. Poiché il browser non aggiunge automaticamente l'intestazione alla tua richiesta, non è vulnerabile a un attacco CSRF, che dipende dal fatto che le tue informazioni di autenticazione vengano inviate automaticamente al dominio originale.

Lo schema al portatore viene spesso utilizzato per proteggere le API Web (servizi REST) ​​che vengono utilizzate tramite chiamate AJAX o da client mobili.

Dobbiamo archiviare JWT sul computer client. Se lo memorizziamo in un LocalStorage / SessionStorage, può essere facilmente catturato da un attacco XSS. Se lo memorizziamo nei cookie, un hacker può utilizzarlo (senza leggerlo) in un attacco CSRF e impersonare l'utente e contattare la nostra API e inviare richieste per eseguire azioni o ottenere informazioni per conto di un utente.

Ma ci sono diversi modi per proteggere il JWT nei cookie per non essere rubato facilmente (ma ci sono ancora alcune tecniche avanzate per rubarli). Ma se vuoi affidarti a LocalStorage / SessionStorage, puoi accedervi con un semplice attacco XSS.

Quindi, per risolvere il problema CSRF, utilizzo i cookie Double Submit nella mia applicazione.

Metodo di invio doppio dei cookie

1. Conservare JWT in un cookie HttpOnly e utilizzarlo in modalità protetta per trasferire su HTTPS.

2. La maggior parte degli attacchi CSRF ha un'intestazione di origine o referrer diversa con l'host originale nelle loro richieste. Quindi controlla se ne hai qualcuno nell'intestazione, vengono dal tuo dominio o no! In caso contrario, respingerli. Se l'origine e il referrer non sono disponibili nella richiesta, non preoccuparti. Puoi fare affidamento sul risultato dei risultati di convalida dell'intestazione X-XSRF-TOKEN che spiegherò nel passaggio successivo.

3. Mentre il browser fornirà automaticamente i cookie per il dominio della richiesta, esiste una limitazione utile: il codice JavaScript in esecuzione su un sito Web non può leggere i cookie di altri siti Web. Possiamo sfruttare questo per creare la nostra soluzione CSRF. Per prevenire attacchi CSRF, dobbiamo creare un cookie leggibile Javascript aggiuntivo che si chiama: XSRF-TOKEN. Questo cookie deve essere creato quando l'utente ha effettuato l'accesso e deve contenere una stringa casuale e non indovinabile. Salviamo anche questo numero nel JWT stesso come reclamo privato. Ogni volta che l'applicazione JavaScript vuole fare una richiesta, dovrà leggere questo token e inviarlo in un'intestazione HTTP personalizzata. Poiché queste operazioni (lettura del cookie, impostazione dell'intestazione) possono essere eseguite solo sullo stesso dominio dell'applicazione JavaScript,

Angular JS ti semplifica la vita

Fortunatamente, sto usando Angular JS nella nostra piattaforma e pacchetti angolari l'approccio token CSRF, rendendo più semplice l'implementazione per noi. Per ogni richiesta che la nostra applicazione angolare fa al server, il $httpservizio angolare farà queste cose automaticamente:

• Cerca un cookie chiamato XSRF-TOKEN sul dominio corrente.
• Se viene trovato quel cookie, legge il valore e lo aggiunge alla richiesta come intestazione X-XSRF-TOKEN.

Pertanto l'implementazione lato client viene gestita automaticamente per te! Dobbiamo solo impostare un cookie denominato XSRF-TOKENsul dominio corrente sul lato server e quando la nostra API ha ricevuto una chiamata dal client, deve controllare l' X-XSRF-TOKENintestazione e confrontarla con quella XSRF-TOKENnel JWT. Se corrispondono, l'utente è reale. Altrimenti, è una richiesta falsa e puoi ignorarla. Questo metodo è ispirato al metodo "Double Submit Cookie".

Attenzione

In realtà, sei ancora sensibile a XSS, è solo che l'aggressore non può rubarti il ​​token JWT per un uso successivo, ma può comunque effettuare richieste per conto dei tuoi utenti utilizzando XSS.

Sia che memorizzi il tuo JWT nel localStoragetuo token XSRF o non nel cookie HttpOnly, entrambi possono essere facilmente acquisiti da XSS. Anche il tuo JWT in un cookie HttpOnly può essere catturato da un attacco XSS avanzato come il metodo XST .

Quindi, oltre al metodo Double Submit Cookies, devi sempre seguire le migliori pratiche contro XSS, inclusi i contenuti di escape. Ciò significa rimuovere qualsiasi codice eseguibile che induca il browser a fare qualcosa che non si desidera. In genere questo significa rimuovere // <![CDATA[tag e attributi HTML che causano la valutazione di JavaScript.

Leggi di più qui:

• XSRF di Angular: come funziona
• Dove conservare i tuoi JWT - Cookie vs HTML5 Web Storage

Un altro aspetto dell'intero problema della memorizzazione dei JWT:

1. I JWT non devono mai essere archiviati nel tuo archivio locale
2. In realtà, non dovrebbero nemmeno essere memorizzati nei cookie , a meno che tu non sia in grado di implementare una protezione CSRF molto rigorosa

Dai un'occhiata a questo per motivazione

• JWT come id_token è come le credenziali dell'utente
• JWT come token di accesso è come il token di sessione

L'opzione più sicura è in memoria . Dai un'occhiata a questo per un'immersione profonda