2015-09-22 4 views

risposta

22

Può essere sicuro nei seguenti casi:

  1. la JWT è tempo di utilizzo sola volta
  2. le jti e exp rivendicazioni sono presenti nel token
  3. ricevitore implementa correttamente la protezione della riproduzione utilizzando jti e exp

ma nel caso in cui viene utilizzato come un token che può essere ripetuto essere usato per es. rispetto a un'API, quindi la fornitura come parametro di query è meno preferibile in quanto potrebbe finire nei registri e nelle informazioni di processo del sistema, disponibili per gli altri che hanno accesso al server o al sistema client. In tal caso sarebbe meglio presentarlo come parte di un'intestazione o di un parametro POST.

Oltre a ciò, utilizzandolo nei parametri di query è possibile eseguire limitazioni di dimensioni URL su browser o server; utilizzarlo in un'intestazione fornisce un po 'più di spazio, usandolo come un parametro POST funzionerebbe meglio.

+2

Inoltre, gli utenti non addestrati possono copiare e incollare un URL con il token, che potrebbe portare a un dirottamento di sessione non intenzionale. – Gray

+0

Se l'endpoint è REST, ci sono molti casi in cui è necessario utilizzare il metodo GET. Inoltre, se la richiesta è da scaricare, non puoi nemmeno usare ajax. –

+0

Che dire di un 'exp' ragionevolmente breve <2 min. più un secondo reindirizzamento (dopo che il 'jwt' è stato raccolto dall'app)? Il secondo reindirizzamento per evitare semplicemente i problemi di copia e incolla. Se il tuo browser è compromesso, anche un'intestazione non ti salverà dal tuo token per essere rubato. –

-2

Non è necessario includere informazioni riservate nell'URL. Puoi crittografare il jwt e includerlo nell'URL utilizzando il metodo GET. Tuttavia, ricorda che alcuni hacker potrebbero essere in grado di decodificarlo, il che sarà un problema se contiene informazioni riservate. Quindi, se non è riservato, puoi includerlo, altrimenti usa un metodo diverso come, POST o sessione.

+22

Eh ... il tipo di richiesta in realtà non fa nulla per proteggersi dagli hacker. Perché dovrebbero essere in grado di leggere le tue richieste GET, ma non le richieste POST? Se hanno toccato la tua connessione, sembra lo stesso. Se è SSL/TLS, anche la stringa di query è protetta. – Gray

+2

I parametri di query vengono visualizzati nella cronologia del browser. Non visibile agli avversari remoti, ma comunque debolezza nella sicurezza. – dnault

+0

Che è rilevante per lo spargimento accidentale dei dati, ad es. avere il token raschiato e servito da google. Tuttavia, per sicurezza, il token deve essere limitato nel tempo e nell'uso. –

Problemi correlati