Come proteggere l'endpoint di convalida della posta elettronica?

1

Abbiamo la convalida e-mail nel nostro modulo di registrazione (una chiamata Ajax a un endpoint REST per convalidare un indirizzo e-mail quando un utente lo inserisce). Diamo un nome normale, nome, cognome, email, password, indirizzo ... Abbiamo 2 azioni in questo modulo.

  1. Quando l'utente inserisce un'e-mail, facciamo una chiamata al back-end e controlla se questa e-mail è già stata presa da qualcuno.
  2. Modulo di invio.

Abbiamo un token CSRF (per una richiesta in un campo nascosto) per l'intero modulo (quindi riceviamo un nuovo token dopo la convalida della posta elettronica).

Ma qualcuno può creare uno script per chiamare l'endpoint di convalida della posta elettronica con il token e raccogliere gli indirizzi email che abbiamo nel sistema.

Esistono buone pratiche per garantire questo tipo di scenario? Abbiamo anche in programma di implementare la limitazione.

    
posta Ntwobike 06.11.2017 - 19:35
fonte

2 risposte

3

Modifica per rispondere alla domanda effettiva

Ci scusiamo per aver frainteso la tua domanda. Detto questo, ecco una risposta. Se il tuo obiettivo è fare in modo che nessuno sappia quali indirizzi email hai registrato sul sistema (che è un buon obiettivo), allora la semplice risposta è che non puoi verificare prima della mano se l'indirizzo e-mail è preso, e poi fagli sapere se è così. Indipendentemente da quali misure di sicurezza hai messo in atto, avrai comunque un posto dove le persone possono venire a chiedere "questa persona è sul tuo sito?". Anche la limitazione della frequenza non lo fa in realtà, poiché un malintenzionato potrebbe bersagliare un utente specifico. Se già conoscono l'indirizzo e-mail della persona in anticipo, devono solo andare al modulo di registrazione e vedere se l'e-mail è stata presa. Invece, dovrai modificare il tuo passo di registrazione:

  1. Puoi sempre verificare che si tratti di un vero e proprio indirizzo email (dicendogli che l'indirizzo email non è un indirizzo email proteggerà dagli errori di battitura e ovviamente non rivelerà nulla di sensibile).
  2. Fagli digitare due volte l'indirizzo email: questo, di nuovo, aiuterà a prevenire errori di battitura, che saranno di grande aiuto nel passaggio successivo:
  3. Forza l'utente attraverso un processo di convalida della posta elettronica, come descritto di seguito: invia loro un'email con una chiave che deve utilizzare per attivare il proprio account. Questo fornisce un paio di livelli di protezione. Se qualcuno sta usando il modulo di registrazione per annusare gli indirizzi email usati, non scoprirà nulla. In tutti i casi il modulo di registrazione restituisce un messaggio generico "Controlla la tua email per le istruzioni su come attivare il tuo account". Se l'indirizzo e-mail esiste già, anziché inviare le istruzioni di attivazione, puoi inviare un messaggio "Hai appena provato a registrarti ma già esiste nel nostro sistema. Fai clic qui per recuperare la password." Se non hai provato a registrarti, fai clic su questo link e quindi ignorare questo messaggio "(o qualcosa del genere). Altrimenti, esegui il normale messaggio di convalida della posta elettronica.

Dato che non vuoi dire alle persone se tentano di registrarsi con una email già esistente, riceverai tre persone diverse che invieranno il modulo di registrazione:

  1. Nuove persone che stanno cercando di registrarsi (queste persone non avranno alcun problema)
  2. Gli anziani che sono già registrati ma dimenticati: la tua e-mail alternativa li aiuterà a entrare molto rapidamente.
  3. Le persone che stanno cercando di raschiare la tua lista e-mail. Non riceveranno nulla.

Di conseguenza, gli attori malintenzionati verranno esclusi e i tuoi utenti legittimi passeranno senza problemi. Un buon mix tra usabilità e sicurezza (IMO).

risposta precedente: leggermente applicabile

Una corretta convalida della posta elettronica non dovrebbe comportare la possibilità per qualcuno di verificare l'esistenza di indirizzi e-mail nel sistema. Potrebbe essere necessario includere maggiori dettagli su cosa esattamente stai facendo. Detto questo, vale sempre la pena spiegare quale sia la risposta dovrebbe essere:

La convalida della posta elettronica deve essere eseguita da una chiave crittografica sicura e casuale che viene inviata via email all'utente. A quel punto la convalida del tempo può essere semplice come fare clic su un link che si invia all'utente che assomiglia a qualcosa di simile:

https://example.com/verify_registration?key=LONGANDRANDOMSTRING

Cose da tenere a mente:

  1. Assicurati che la chiave di convalida sia generata con un CSPRNG corretto: se l'utente può indovinare la chiave dal loro input, è inutile.
  2. L'indirizzo email dell'utente non fa parte dell'input e non è necessario in nessuna fase del processo di convalida. Il fatto che l'utente conosca la chiave casuale, che viene distribuita solo via email, è ciò che verifica che l'utente possieda l'indirizzo email. Di conseguenza, non dovrebbero esserci opportunità per le persone di analizzare un elenco di indirizzi e-mail.
  3. Assicurati che la tua chiave abbia abbastanza byte casuali da non poter essere indovinata
  4. Normalmente utilizzeresti solo POST di richieste per apportare modifiche e, pertanto, desideri assicurarti che questo endpoint abbia una protezione CSRF. Tuttavia, non è necessario qui. Il motivo è che la chiave stessa è sufficientemente casuale che nessuno, tranne la persona con l'e-mail, dovrebbe averlo comunque. Quindi è meglio che il processo di validazione avvenga tramite un semplice link e una richiesta di GET . Anche se l'utente deve semplicemente copiare e incollare la chiave dalla propria email a un modulo Web, qualcuno lo sbaglia. Il modo in cui funziona è abbastanza semplice e abbastanza sicuro che (IMO) un'interfaccia utente più semplice è perfettamente ragionevole.
  5. Vale la pena menzionare perché lo vedo sempre: gli hash non aggiungono casualità a una stringa. Utilizzare un CSPRNG effettivo per creare una stringa casuale. Non prendere semplicemente dei dati altrimenti semplici e cancellarli. Gli hash non aggiungono entropia: devono farlo apparire casuali.
risposta data 06.11.2017 - 20:41
fonte
1

Non è chiaro quale minaccia stai cercando di gestire.

Ci sono alcune opzioni, che descriverò in cima alla mia testa:

  • perdita di informazioni per una singola email

    Dovrai negare la registrazione ad un certo punto, quindi non hai modo di fare qualcosa contro di essa, ad eccezione dell'invio delle informazioni via e-mail, cioè lascia che il primo passo sia un campo di input che genera un'e-mail con un link per procedere.

    Questo rende la registrazione ancora più noiosa, perché è comunque un approccio orribile, UX-saggio.

  • perdita di informazioni con forza bruta

    L'iterazione di indirizzi email (piuttosto lunghi) è noiosa, ma la limitazione della frequenza manterrà sotto controllo gli attaccanti che non usano il cloud per delegare le richieste da vari IP.

    Potresti comunque rendere il controllo computazionalmente costoso facendo in modo che la parte richiedente utilizzi le funzioni hash lente più volte prima di inviarla alla tua API (JavaScript sembra essere comunque necessario).

    Ciò richiederebbe di eseguire tali calcoli anche per ogni utente su ogni registrazione, ma sarebbe accettabile, probabilmente.

    Inoltre, questo sarebbe uno spreco di potenza di calcolo se non esiste un elenco di indirizzi email validi ed è un'iterazione puramente casuale di indirizzi email validi per RFC.

  • minacce avanzate in cui l'email è compromessa o può essere intercettata

    Non puoi fare nulla al riguardo. Questo vale anche per il primo szenario se non hai una chiave S / MIME o PGP valida per l'indirizzo quando invii il link.

In generale, potresti voler utilizzare, ad esempio, i provider OAuth per l'autenticazione per non doversi preoccupare di tutto questo - o non utilizzare gli indirizzi email come ID:

Se consenti agli utenti di scegliere uno pseudonimo sulla registrazione che deve essere univoco, puoi semplicemente concedere una seconda registrazione per un indirizzo email; e perché no *?

Con l'attivazione dell'email, è possibile eliminare la registrazione in sospeso se non viene completata entro x ore. E dato che hai raccolto una chiave da parte dell'utente, potresti anche dire che hanno già ricevuto un account (e lo pseudonimo) in quella email.

(*) Anche gli utenti che non hanno accesso a più indirizzi e-mail possono utilizzare la funzione alias da RFC e creare più account a meno che non si verifichi l'uguaglianza in modo tale che [email protected] == [email protected] . Quindi gli utenti potrebbero creare più account comunque.

    
risposta data 07.11.2017 - 06:20
fonte

Leggi altre domande sui tag