JWT o cookie di sessione per l'API per l'app Web e mobile?

Question

JWT o cookie di sessione per l'API per l'app Web e mobile?

#1 da (0 voti)
#2 da (0 voti)

0

Ho letto tutto quello che potevo su questo argomento negli ultimi due giorni e non riesco a decidere quale sarebbe l'approccio migliore.

Gli unici due requisiti sono:

Ho bisogno di conoscere gli utenti che hanno effettuato l'accesso e ogni sessione che hanno, quindi l'utente sarebbe in grado di vedere un elenco con queste informazioni e di essere in grado di chiudere qualsiasi sessione che scelgono.
Entrambe le app dovrebbero utilizzare gli stessi endpoint di un'API di riposo.

All'inizio usavo i cookie di sessione e chiamavo l'API con setCredentials = true, ma ho scoperto che le app mobili gestiscono i cookie in modo diverso e non ne ho il controllo (ad esempio, vengono eliminati per vari motivi prima della scadenza ). Ho pensato di salvare il cookie nello storage nativo e di aggiungerlo ad ogni richiesta, ma non posso accedere al cookie in alcun modo perché httpOnly è impostato su true. La soluzione sarebbe quella di impostare httpOnly su false, ma in questo modo espongo il cookie e non sono sicuro di quali misure di sicurezza dovrei adottare per proteggere il cookie da eventuali furti o manomissioni.

L'altra soluzione sarebbe quella di utilizzare JWT e archiviarlo nella memoria web / nativa. Vorrei anche memorizzare in una tabella ogni token ancora valido (hash con un algoritmo di password) per ottenere l'elenco degli utenti loggati e le loro sessioni, e un'altra tabella per i token non validi per quando l'utente sceglie di terminare una particolare sessione / cambia password / ecc. Ma ancora una volta non sono sicuro delle misure di sicurezza che dovrei fare con questo approccio. Dovrei crittografare anche il token? Stavo pensando di accodare i dati sul dispositivo che richiedono il token per verificare sempre che il dispositivo che ha richiesto il token sia quello che lo utilizza. Quali altre cose dovrei fare per proteggere questo token?

Se implemento correttamente entrambe le opzioni, quale sarebbe più sicuro sia per il Web che per i dispositivi mobili?

mobile jwt cookies web-application session-management

posta Leia 10.10.2018 - 16:29

fonte

2 risposte

Leggi altre domande sui tag mobile jwt cookies web-application session-management

La firma binaria deve essere verificata prima di essere avviata da postazioni attendibili? Esiste una soluzione alternativa per un uomo nel proxy centrale che utilizza Shell in a Box?

score 0 · Answer 1

Ti fidi di tutto il tuo codice cliente? In caso affermativo, è possibile memorizzare gli ID di sessione nella memoria locale e accertarsi di inviarli con ogni richiesta HTTP. Sul backend, è sufficiente disporre di una tabella con hash dell'ID di sessione come chiave primaria e ID utente come chiave esterna e una scadenza. Non tenere un elenco di sessioni eliminate, basta eliminare la riga (o contrassegnarla come cancellata).

Il rischio con i cookie è che vengono inviati con ogni richiesta HTTP al tuo dominio, anche se proviene da un client falso. Questo è chiamato CSRF . A meno che tu non abbia una sorta di protezione CSRF, evita i cookie e utilizza la memoria locale.

Ovviamente, se non puoi fidarti di tutto il tuo codice cliente, allora avrai bisogno di un'altra soluzione.

Inoltre, se utilizzi HTTPS, gli ID di sessione, i cookie o i moduli inviati verranno crittografati.

score 0 · Answer 2

Prima di entrare nei dettagli, dirò che entrambi i cookie di sessione e le JWT funzionano per il tuo caso ed entrambi sono sicuri se implementati correttamente . Personalmente vorrei andare con le JWT se non altro perché è più facile ottenere informazioni aggiornate o soluzioni già pronte.

JWT

Le JWT erano pensate per l'autorizzazione stateless ma puoi ancora usarle per le sessioni. In particolare, ti consigliamo di utilizzare un modello di accesso / aggiornamento dei token in cui tieni traccia dei token di aggiornamento attivi nel tuo database.

Come per la crittografia, esistono due principali implementazioni dello standard JWT, ovvero JWS (un token firmato) e JWE (firmato quindi token crittografato). Quello che vuoi tenere a mente è che la firma di un token firmato garantisce già l'integrità del token. Implementerai JWE solo se passi anche informazioni sensibili nel token che vuoi oscurato dal client . Tuttavia JWT da solo non risolve i problemi con gli attacchi man-in-the-middle, quindi è necessario ricordare di usare SSL ogni volta che si trasmette il token.

Lo spazio di archiviazione del token sarà diverso tra l'app Web e l'app nativa per dispositivi mobili. Per le app mobili è necessario memorizzarle nel Portachiavi / Keystore del sistema operativo (molto probabilmente attraverso un wrapper) progettato per tale scopo. Dove conservare le JWT su un browser d'altra parte è ancora un argomento piuttosto controverso in quanto l'archiviazione in Webstorage (sessionStorage / localStorage) è vulnerabile a XSS-Attacks mentre la memorizzazione all'interno di un cookie è vulnerabile a CSRF.

Da quello che riesco a capire, la tendenza generale è quella di evitare il webstorage a causa della sua superficie di attacco più ampia, ma ad essere onesti ho visto esempi di entrambi i metodi. Per le applicazioni a pagina singola puoi anche considerare di mantenere il token in memoria senza memorizzazione persistente.

Cookie di sessione

Senza conoscere i dettagli della tua app per dispositivi mobili è difficile dirlo, ma dalla mia esperienza se utilizzi i meccanismi di CookieManager / NSHTTPCookieStorage forniti da Google / iOS non dovrebbe esserci un problema con i cookie eliminati che descrivi.

Per memorizzare i cookie sul browser è necessario proteggerli contro CSRF. Per quale protezione dovresti usarlo dipenderà molto dalla tua specifica implementazione e restrizioni del server e penso che dovresti controllare le risorse su OWASP o poni una domanda più specifica.