Qual è il vantaggio aggiuntivo di avere un token CSRF per un link di attivazione dell'account?

Naviga le tue risposte
1

Abbiamo una semplice webapp in cui un utente dovrà creare un account. Per verificare il loro indirizzo email (che sarà usato per inviare notifiche in seguito per motivi di lavoro, che è una delle caratteristiche principali dell'applicazione), inviamo un link di attivazione.

Il nostro link di attivazione porta a un sottodominio differente. Per questo motivo, e la possibilità per l'utente di aprire questo link di attivazione su un altro computer / browser (ad esempio sul PC anziché sul telefono), l'utente dovrebbe ottenere un nuovo token CSRF quando segue il collegamento di attivazione.

Quando attivi il tuo account, non è necessario che tu abbia effettuato il login. (Potresti essere loggato, ma non all'account che stai attivando.)

Quindi, quando attivi il loro account, accade quanto segue:

  1. l'utente fa clic sul link,
  2. il front-end che gestisce tali richieste si apre,
  3. il front-end effettua una richiesta di pre-volo al nostro server per ottenere un token CSRF,
  4. il front-end riceve il token CSRF,
  5. il front-end utilizza i parametri passati nell'URL per inviare una richiesta di attivazione al nostro server.
  6. Il server restituisce la risposta appropriata dopo aver gestito la richiesta
  7. Il front-end visualizza la pagina appropriata in base alla risposta ("È riuscito, fai clic qui per accedere" o "Il tuo account è già stato attivato, fai clic qui per accedere" o "Link di attivazione scaduto", ecc.)

Il punto chiave qui è che la persona che attiva un account non ottiene alcun diritto speciale. Non registriamo automaticamente la persona che attiva il proprio account. Le persone devono ancora farlo da soli.

Quindi mi chiedo: perché ho bisogno di questo token CSRF? Il link di attivazione contiene un token di attivazione, quindi chiunque sia in grado di attivare un account è davvero fortunato o ha effettivamente ricevuto l'e-mail. Se un utente malintenzionato ha attivato un account, tutto ciò che accade è "l'account è attivato".

Mi piacerebbe prendere il token CSRF da questo processo per accelerare il processo (in particolare per le persone con Internet ad alta latenza). Dovrei indebolire la mia sicurezza se ho tolto il token CSRF dal processo, in modo che il processo risolva in questo modo:

  1. l'utente fa clic sul link,
  2. il front-end che gestisce tali richieste si apre,
  3. il front-end utilizza i parametri passati nell'URL per inviare una richiesta di attivazione al nostro server.
  4. Il server restituisce la risposta appropriata dopo aver gestito la richiesta
  5. Il front-end visualizza la pagina appropriata in base alla risposta ("È riuscito, fai clic qui per accedere" o "Il tuo account è già stato attivato, fai clic qui per accedere" o "Link di attivazione scaduto", ecc.)

TL; DR: Un token CSRF aggiunge sicurezza per gli endpoint REST dove non è necessario effettuare l'accesso?

    
posta Pimgd 03.08.2017 - 11:49
fonte

1 risposta

1

Ok, come vedo, ci sono due importanti richieste HTTP qui:

  1. Il primo viene generato quando l'utente fa clic sul link di attivazione. Questo è comunque non protetto da un token CSRF, ma contiene un token di attivazione. Tutto sembra a posto.
  2. Il frontend genererà quindi un token CSRF e invierà una richiesta al tuo server per completare l'attivazione. Se quella richiesta contiene il codice di attivazione e il server lo verifica, non vedo un motivo per avere un token CSRF in questo caso particolare, sebbene sia difficile dirlo con certezza, senza vedere come appaiono le richieste / risposte e cosa fanno sul lato server. Potrebbe essere che il token CSRF sia usato in seguito per qualcos'altro? Ci sono delle modifiche relative alla sicurezza sul lato server o clinet dopo l'esecuzione di queste richieste?

Poiché la prima richiesta non è protetta da un token CSRF e il token è generato al volo per la seconda richiesta, questo tipo di implementazione del token CSRF comunque non ha molto senso per queste particolari richieste perché l'attaccante deve ancora conosci solo il token di attivazione, se ho capito tutto bene.

Cosa potrebbe ancora andare storto?

Un attaccante non conosce il segnalino di attivazione della vittima, quindi non può usare quel vettore di attacco in ogni caso.

Ma un utente malintenzionato potrebbe creare il proprio account e rendere la vittima attiva, ma ciò sarebbe sfruttabile solo se tale richiesta avrebbe qualche effetto aggiuntivo, come la registrazione dell'utente (cosa non è il caso, come descritto). Devi solo stare molto attento che l'attivazione dell'account sia l'unico effetto di tale richiesta.

Un altro scenario inverosimile sarebbe se il server genera sempre gli stessi token CSRF per gli stessi codici di attivazione. L'utente malintenzionato potrebbe consentire al server di generare un token CSRF, ma interrompere l'attivazione dell'account (la seconda richiesta). Dopo di ciò, avrebbe fatto visitare alla vittima il link con la sua attivazione, e avrebbe saputo quale gettone CSRF avrebbe ottenuto la vittima. Ma anche questo è un po 'esagerato.

Inoltre, l'uso di un token CSRF ha spesso alcuni effetti collaterali, come limitare l'XSS all'auto-XSS, ma è una cosa più generale, non specifica per il tuo caso.

A proposito, se vuoi accelerare le cose, perché usi il frontend per generare la seconda richiesta? Perché non fare in modo che il server elabori la prima richiesta e attivi l'account?

E per favore non prendere ciò che ho detto per scontato perché è difficile dare una risposta precisa se non ho visto l'app.

    
risposta data 03.08.2017 - 16:18
fonte

Leggi altre domande sui tag

IAT Domande di aggancio? Limitazioni delle tecniche di emanazione elettromagnetica (come TEMPEST)