Quanto è sicuro mantenere un token angolare per future richieste a un'API Laravel?

1

Ho un front-end angolare JS che consuma i servizi Web da un'API sviluppata usando Laravel 5.

INFORMAZIONI PRINCIPALI 1

Quando l'utente esegue il login, se ha successo l'API restituisce un token e il token è come questo:

$token = base64_encode("mail=" . $mail); 
return Response::json(["token" => $token, 'error' => null]); 

Quindi ho una funzione in un servizio angolare che sa come lavorare con il token.

INFORMAZIONI DI SFONDO 2

Ogni volta che un utente deve ottenere dati, l'API accetta la posta inviata alla richiesta come una delle richieste di intestazioni. In Laravel, ho un middleware che prende quel token e fa le seguenti convalide:

  1. Il token si trova all'interno delle intestazioni (nell'intestazione dell'autorizzazione)
  2. Il token è un token valido
  3. L'email recuperata dal token esiste nel database

Se una qualsiasi di queste convalide fallisce, l'API invia una 422 richiesta errata con qualche errore.

DOMANDA

La mia vera preoccupazione è che qualcuno può hackerare il mio sito web? È possibile per qualcuno (conoscendo l'email di qualcun altro sul sito Web) modificare l'intestazione di autorizzazione che contiene l'email?

Nota

In teoria, l'utente ottiene un token se ha avuto un login di successo, se non l'ha fatto non lo otterrà.

    
posta ggderas 07.04.2016 - 01:36
fonte

2 risposte

1

La differenza con il tuo token (indirizzo email con codifica Base64) e una JWT è che per una JWT è molto più difficile creare un token per un altro utente. Con il tuo token, posso facilmente codificare qualsiasi altro indirizzo email e ottenere un token valido. Una JWT, tuttavia, è crittografata e puoi crearne una solo se hai una chiave segreta, che rimane sul server.

Se vuoi una soluzione sicura, potrebbe essere meglio usare una libreria che implementa token sicuri come i JWT.

    
risposta data 07.04.2016 - 10:32
fonte
2

Considerando che sembra che solo Base 64 codifichi l'e-mail, è facilmente aggirabile.

Non provare a reinventare la ruota, soprattutto per motivi di sicurezza.

Utilizzare una libreria di autenticazione ben nota. Dopo che un utente è stato autenticato, recupera i dati che lo riguardano dallo storage in base alla sua identità autenticata e lo trasmette come richiesto.

Modifica Se vuoi persistere con questo approccio, dovresti includere un token di convalida con il tuo json seguendo queste linee:

  • Al punto di accesso, hash un segreto (sul lato server) concatenato con l'e-mail dell'utente per produrre un token di convalida.
  • Invia il token al client
  • Quando arriva una richiesta con un token, puoi verificare che l'email non sia stata manomessa ripetendo il primo passaggio sopra e respingendo la richiesta se il token di convalida non corrisponde.

Ciò impedisce la manomissione dell'e-mail, sebbene non impedisca a qualcuno di rubare il token e usarlo in un attacco di replay ecc.

    
risposta data 07.04.2016 - 01:56
fonte

Leggi altre domande sui tag