Come proteggere REST API per SPA e Mobile App utilizzando Cordova

Question

Ho fatto molte ricerche sulle "migliori pratiche" che circondano questo e ho letto post di blog dopo post sul blog, domanda SO dopo domanda SO e articolo OWASP dopo OWASP articolo. Sono arrivato ad alcune risposte chiare ma alcune incognite.

In primo luogo, la "Cosa fare":

1. Usa JWT per autorizzare gli utenti sul mio REST API [1][2]
2. Conservare il JWT in HTTPOnly/cookie sicuro e costruire nella protezione CSRF. Non conservare in memoria locale HTML5 [3][4][5] (In realtà, questo punto è discutibile, è più facile per la protezione contro XSS o CSRF? [6])
3. Verificare il metodo firma del JWT [7]

Ora ho iniziato partendo dal presupposto che avere una SPA (costruita con Angular) e l'utilizzo di sessionStorage HTML5 sarebbe abbastanza sicuro per i token di breve durata, ma bisogna fare in modo che gli attacchi XSS possano accadere da un "cattivo attore" originario di quello di molte librerie caricate da un CDN.

Per il mio caso d'uso specifico, non ho intenzione di avere token di lunga durata - scadenza dopo 10 minuti di non utilizzo, ma sto ancora cercando di rintracciare la scadenza per sessione o usare i token di aggiornamento - StormPath raccomanda il primo (non più stateless?), ma credo che i grandi giocatori che usano le JWT utilizzino i token di aggiornamento (Google li usa ma afferma che è necessario archiviarli in un archivio sicuro a lungo termine, il che significa che HTML5 localStorage è di nuovo fuori questione).

Mi piacerebbe farlo in modo che i miei utenti non debbano accedere di nuovo se aggiornano la pagina (da qui la necessità di memorizzare il token sul lato client). Mi piacerebbe anche utilizzare la mia SPA come "app mobile" con l'aiuto di Cordova. L'ovvia insidia qui è che se utilizzo i cookie, non c'è alcun supporto/archiviazione dei cookie integrati con Cordova e sono invece invitato a passare all'archiviazione locale HTML5. Dal momento che sui dispositivi mobili non ho davvero bisogno di preoccuparmi di aggiornare le pagine, posso semplicemente lasciare il mio token in memoria e scadere con la strategia su cui mi sto ambientando.

Se seguo questo approccio, basato su cookie JWT su desktop, intestazioni "Bearer" su dispositivo mobile, ora ho bisogno di un endpoint di autenticazione che fornisca token in due modi diversi e quando autorizzo sul lato REST API, Devo supportare sia i JWT basati su cookie (con CSRF) sia la verifica JWT basata sull'intestazione. Questa complicazione mi preoccupa perché non so se posso prevedere con precisione le implicazioni sulla sicurezza qui.

di riassumere la raffica di pensieri di cui sopra:

• creare un gestore di autenticazione che distribuire i token via HttpOnly/cookie Sicuro al desktop, e payload per il mobile.
• Sulla mia API REST, supportare entrambi i metodi di verifica: basato sull'intestazione e basato sui cookie, inclusa la protezione CSRF per l'approccio basato sui cookie.

C'è qualche motivo per cui non vorrei prendere questo approccio? Suppongo che se prendo XSS sulla mia SPA come un grave rischio, quindi ho bisogno di una classica pagina di login per l'autenticazione per impostare i cookie appropriati perché se faccio l'autenticazione tramite la SPA, quindi qualsiasi attacco XSS potrebbe potenzialmente intercettare anche quello (sia su cellulare che su desktop)! Tuttavia, sul cellulare, dovrei inserire il JWT in SPA, magari attraverso qualche elemento DOM personalizzato (meta tag?), ma a quel punto posso semplicemente lasciare che la SPA esegua il login e non consideri XSS una minaccia sui dispositivi mobili. Cordova impacchetta tutte le risorse nel pacchetto di installazione, quindi è un po 'meglio, ma allora perché non adottare lo stesso approccio sulla versione Desktop?

La mia applicazione richiede pochissimo input da parte dell'utente, è principalmente uno strumento di dashboard/reporting. Ci sarà un "centro messaggi" ma il contenuto dovrebbe sempre essere creato dall'utente (solo da quell'utente) e disinfettato. Nel mio caso d'uso, quindi, sarebbe corretto deviare dalle "migliori pratiche" e fare affidamento su localStorage senza contare l'XSS come un serio rischio per la mia SPA? Ciò semplificherebbe l'intera cosa (utilizzare sessionStorage HTML5 come originariamente pianificato) e ridurre la complessità, che ridurrebbe la superficie di attacco per potenziali errori di sicurezza. Voglio solo assicurarmi di comprendere i rischi prima di andare avanti.

Non esiste un modo sicuro per rendere questo sicuro se non costruendo un'app nativa per dispositivi mobili e non utilizzando Cordova per convertire la SPA in un'app mobile? Odio che questo sia il caso, ma potrebbe benissimo essere.

Apprezzerei tutte le considerazioni in merito!

Answer 1

Quando si pensa di progettare applicazioni multipiattaforma basate su javascript per eseguire un dispositivo mobile, molte delle avvertenze con la progettazione di normali applicazioni basate su browser Web non si applicano necessariamente.

Per quanto riguarda la sicurezza, se si decide di utilizzare JWT o semplici token OAuth, assicurarsi che tutte le comunicazioni siano tramite https.

Utilizzare localStorage per quanto possibile. Se si considera l'anatomia di una richiesta http, tutto ciò che è veramente è l'invio di un messaggio basato su testo diviso in più sezioni su un server. L'intestazione della richiesta non è più sicura di qualsiasi altra parte di esso compresi i cookie. Pertanto, i punti di interesse dal punto di vista della sicurezza sono generazione/convalida/invalidazione del token, memorizzazione del token sul dispositivo e meccanismo di trasporto delle richieste.

1. Generazione/Convalida/Invalidità: genera i token sul server. Utilizzare alcune tecnologie/strategie per garantire che non vi siano possibilità di collisione o sanguinamento. Inoltre, assicurarsi che la strategia consenta di invalidare un token sul server che successivamente nega l'accesso ai dati richiesti dal server per l'ulteriore utilizzo del token. Spetta a te nella tua app gestire il viaggio dell'interfaccia utente degli utenti quando il server nega l'accesso alle risorse.

2. Il modo in cui il token viene archiviato sul dispositivo è limitato a quanto reso disponibile dal sistema operativo del dispositivo. Per quanto riguarda l'utilizzo di un'app nativa migliore rispetto alla multipiattaforma, penso che la creazione di un plug-in nativo-cordova per memorizzare il token utilizzando qualsiasi strategia nativa specifica, se uno non è soddisfatto con quelli "out of the box" (come l'archiviazione locale) è possibile, sebbene nella mia esperienza questo sia di solito eccessivo. Felice di essere corretto su questo se qualcuno ha un'esperienza diversa.

3. Utilizzare HTTPS SEMPRE senza eccezioni per TUTTE le comunicazioni endpoint Webservice. HTTPS è infallibile, NO, ma non costruiresti una casa senza una porta principale semplicemente perché i ladri dedicati potrebbero imparare a raccogliere le serrature. Ciò protegge notevolmente il meccanismo di trasporto.

In genere, tutte le app native devono funzionare comunque.