Capire cosa proteggere con JWT

2

Quindi ho scritto una domanda fittizia, un modulo di login scritto in angular2, che registra il nome utente e la password su un'API di resto, se le credenziali sono corrette, l'API restituisce un JWT (codificate nel JWT sono varie autorizzazioni). Il JWT viene salvato nella memoria del browser locale.

Funziona perfettamente, il JWT è memorizzato nell'archivio locale (secondo le guide che ho letto online) e può essere accessibile a chiunque abbia un po 'di conoscenza del browser (controlla elemento, visualizza risorse ecc.) e una volta che accedi al Token JWT, può essere facilmente decifrato senza l'uso di una chiave.

Nella mia applicazione angular2, decodifica la chiave, se la chiave contiene "value1 = True" consente all'utente di accedere a una determinata parte del sito Web, se il valore della chiave è falso, restituisce l'utente alla home page con un messaggio di accesso negato. Di nuovo funziona bene nella mia configurazione di prova.

Poiché la chiave viene memorizzata solo localmente, posso creare una JWT ovunque, incollarla nella memoria locale del mio browser con le credenziali corrette, quindi posso accedere alle aree riservate del sito web.

Ho perso qualcosa, in quanto questo non sembra sicuro? Diciamo che la mia app era online su mynewapp.com e che l'area mynewapp.com/private era protetta con questa autenticazione JWT, l'applicazione ha verificato un JWT valido, se viene trovato un token JWT valido, ispeziona il token, per vedere se contiene le autorizzazioni rilevanti per accedere a quest'area, in caso contrario, cosa è impedire alla persona dietro il browser di modificare il contenuto della memoria locale del browser, di manipolare i dati per accedere a quest'area proibita.

L'unico modo in cui posso pensare è:

Se JWT esiste, esegui una chiamata API al server REST, se l'utente con il JWT dispone dell'autorizzazione per accedere all'area richiesta, restituisce true e consente alla richiesta di continuare all'interno di Angular

Altrimenti, REST Api restituisce false e l'utente non è più autorizzato.

    
posta crooksey 19.12.2016 - 16:10
fonte

2 risposte

2

Se le JWT vengono utilizzate per l'autorizzazione o l'autenticazione, devono essere firmate o crittografate (che dipende dal tuo caso d'uso esatto). Se si dispone di una risorsa auth e di più altre risorse che desiderano utilizzare la JWT, la firma con una chiave privata (nella risorsa auth), verificando con una chiave pubblica (nelle altre risorse) è un buon esempio. Se sono presenti più server che funzionano come endpoint e risorse, una chiave di crittografia condivisa può funzionare bene, poiché il token può essere creato e crittografato, quindi decrittografato quando deve essere verificato.

Una JWT contiene reclami, ma tali affermazioni, come si immagina, non dovrebbero essere manipolabili sul lato locale.

Gli utenti di Auth0 (disclaimer: nessuna relazione con Auth0) avere più informazioni sugli algoritmi di firma JWT standard.

Una nota: le restrizioni in Angular2 (come tutte le pagine lato client) sono adatte solo per la comodità dell'utente finale, ad esempio nascondendo le pagine a cui non possono accedere in modo da non confondersi. Non dovresti MAI fare affidamento su questi, poiché qualsiasi restrizione in Angular2 / JS può essere aggirata banalmente. Prima di recuperare i dati riservati o eseguire operazioni con restrizioni, i controlli di autorizzazione dell'utente devono essere eseguiti sul SERVER. In effetti, i controlli di autorizzazione dovrebbero essere eseguiti per ogni operazione: non ti fidi mai del cliente, mai.

    
risposta data 19.12.2016 - 19:12
fonte
1

"Ho perso qualcosa?"

Tipo di: hai individuato sicuramente il principale fallimento con JWT. Questo in realtà non fornisce molto in termini di sicurezza. In particolare, è suscettibile di "replay attack".

Per quanto ne so, non c'è modo di proteggere completamente un sistema usando solo un JWT. È necessario avere ulteriori controlli sul server.

Potrebbe essere un metodo semplice. ad esempio, creazione e token crittografato sul server che includeva l'indirizzo IP dei mittenti. Confronta il token con una nuova versione sul server ogni pochi contatti dal browser (o ogni pochi secondi / minuti, dipende dal tipo di applicazione e dalla quantità di dati che stai trasferendo). Limiti il numero di assegni per prevenire attacchi DOS.

Sintonizzando la frequenza con cui si effettua il controllo, è possibile bilanciare l'utilizzo delle risorse del server con la sicurezza necessaria.

Sono sicuro che ci sono molti altri modi per fare controlli simili. Potresti anche ridurre il rischio riducendo il timeout sul token, questo non è altrettanto sicuro ma sicuramente aiuta.

    
risposta data 19.12.2016 - 16:33
fonte

Leggi altre domande sui tag