Si tratta di un problema di sicurezza che consente la registrazione di indirizzi email quasi identici?

Il primo e più importante problema con questo approccio è che nel tuo esempio, solo il primo è in realtà un indirizzo email sintatticamente valido. Gli altri tre non lo sono. Ciò significa che una delle due seguenti opzioni contiene:

1. L '"indirizzo email" è solo un suggerimento. Il sistema vuole un identificatore di accesso univoco; gli indirizzi email sono identificatori ragionevolmente buoni perché gli utenti li ricordano e il sistema di posta elettronica garantisce già unicità in tutto il mondo.

2. L'indirizzo e-mail dovrebbe essere un indirizzo e-mail (ad esempio, per inviare e-mail a quell'indirizzo), e il sistema di registrazione fallisce totalmente nel convalidare che qualunque sia l'utente inserito è un indirizzo e-mail.

In quest'ultimo caso, questo significa che le e-mail non vengono trasmesse, e anche che lo sviluppatore è stato molto sciatto per quanto riguarda la convalida dell'input dell'utente, che non è un buon segno per la sicurezza, in generale.

Tuttavia, se gli identificatori sono di forma libera, ciò a cui si assiste è il risultato della creatività degli utenti umani. Non è un problema finché gli identificatori di accesso vengono utilizzati per quello che sono. Spazi, punto e virgola ... possono distruggere script o applicazioni poco sviluppati. (Provare a registrare con un nome account contenente una virgoletta singola, nel caso ci sia qualche possibile iniezione SQL.)

Solo il primo indirizzo email è in realtà un indirizzo valido. Certo, la validazione degli indirizzi email è difficile , quindi cercare di implementare una validazione perfetta non ha senso . Al massimo, puoi approssimare la convalida e, per motivi di usabilità, dovresti essere indulgente con il tuo filtro. Per questo motivo, non dovresti basare la tua sicurezza sulla validità degli indirizzi email.

Tuttavia, quando si richiede un indirizzo email per la registrazione, è consuetudine inviare un link di conferma a tale indirizzo (per evitare errori di battitura, ecc. non farlo potrebbe essere considerato un problema di sicurezza), il che renderebbe il tuo scenario impossibile.

In ogni caso, questo non è un problema di sicurezza. La tua autenticazione dovrebbe essere in grado di gestire nomi simili, altrimenti è difettosa .

Tuttavia, dovrei stare attento con gli spazi all'inizio o alla fine, dato che capita spesso che venga tagliato a un certo punto, il che potrebbe effettivamente causare problemi.

Oltre a questo, ci sono solo due piccoli problemi:

• Errori di battitura: potrebbe esserci un utente [email protected]:123456 e un utente [email protected]:123456 . Se uno di loro digita erroneamente le proprie credenziali in caso di incidente, potrebbe finire nell'account dell'altro utente. Ma questa è una coincidenza, e non proverei a difenderlo a causa di motivi di usabilità.
• Identificazione: puoi visualizzare indirizzi email al posto di nomi utente, consentendo eventualmente all'utente di imitare un utente diverso. Ad es. Nel tuo esempio [email protected] e [email protected] sono difficili da distinguere. Ma questo è di nuovo un caso d'angolo, perché di solito vengono visualizzati i nomi utente per l'identificazione, non gli indirizzi email.

Tutti tranne il primo dovrebbero essere rifiutati semplicemente perché non sono indirizzi email validi.

Quando copi e li copi letteralmente nel tuo client di posta elettronica preferito, potrebbero fare ciò che ti aspetti, ma il comportamento più probabile è che li interpreti tutti allo stesso modo. Pertanto, se desideri che gli indirizzi di posta elettronica identifichino in modo univoco gli utenti, devi insistere per inserire uno (esattamente uno) indirizzo email sintatticamente corretto nel modulo di registrazione.

Esiste sicuramente un problema di sicurezza che deriva da un provider che consente la registrazione di indirizzi email quasi identici. Ma non è proprio quello che i tuoi esempi specifici stanno testando. E i suoi effetti non sono nemmeno necessariamente limitati agli utenti del servizio di posta elettronica, ma possono avere un impatto più ampio su chiunque riceve mail da un utente quel servizio. Il pericolo di cui sto parlando è uno che coinvolge la rappresentazione di un utente del servizio verso i destinatari della posta.

Per capire cosa intendo, mettiamo da parte i problemi di confusione (già ben discussi) su ciò che è e non è un indirizzo di posta valido e se l'id di un utente è in realtà lo stesso dell'indirizzo di posta elettronica esterno dell'utente. Invece, diamo un'occhiata al seguente scenario:

L'attaccante vuole che il malware venga impiantato sul computer di Jane Smith. L'attaccante conosce l'indirizzo e-mail di Jane Smith, sa che Jane Smith è molto amica di John Anderson e sa che John Anderson mantiene un indirizzo e-mail attivo con un fornitore di posta elettronica mail.com su [email protected]. L'attaccante controlla il processo di registrazione di mail.com e scopre felice che il servizio gli consentirà di registrare [email protected] (nessun limite) come indirizzo valido. L'attaccante imposta il suo nome "da" per l'account come "John Anderson" e inizia a comporre un'e-mail di pesca in apnea indirizzata a Jane Smith. L'attaccante trova un documento PDF su Internet che sembra il tipo di oggetto che John Anderson e Jane Smith potrebbero trovare reciprocamente interessanti, e quindi usa SET per inserire in quel documento un exploit PDF e un carico utile malevolo.

L'attaccante invia il messaggio. Alla fine di Jane Smith, riceve un'email da "John Anderson" all'indirizzo [email protected]. Il messaggio è un inoltro su un articolo PDF con una raccomandazione di una frase di John: "Ho appena finito questo, e penso che troverai la pena leggere. Non sono sicuro di essere d'accordo con tutti i punti dell'autore, ma molto, molto interessante. " E siccome mail.com certifica crittograficamente che il messaggio proviene effettivamente dall'indirizzo presunto, il servizio di posta elettronica di Jane Smith ha lasciato che il messaggio passasse attraverso la sua casella di posta invece di inviarlo alla cartella spam (come potrebbe accadere se l'attaccante semplicemente spoofed il "da" indirizzo).

Domanda retorica: quali sono le probabilità che Jane Smith apra quell'allegato PDF?

Risposta: all'incirca quanto riceverai per un attacco di pesca in apnea. (Almeno senza avere accesso al sistema di posta elettronica del suo datore di lavoro e impersonare il suo capo, o qualcosa del genere).

Le probabilità che un utente tipico si accorga che [email protected], [email protected] o persino [email protected] non sono dello stesso mittente sono piuttosto basse. (Se l'utente è molto attento alla sicurezza in generale, ovviamente le possibilità di rilevamento aumentano, anche se sospetto non tanto quanto qualcuno potrebbe supporre.) Se il vero indirizzo email della persona reale che l'autore dell'attacco sta tentando di imitare è già nella rubrica del destinatario prima che arrivi l'e-mail dell'utente malintenzionato, il destinatario potrebbe (potrebbe) quando riceverà il messaggio che il mittente di questo particolare messaggio non è lì, come il destinatario si aspetterebbe . E lui o lei potrebbe (potrebbe) trovare un po 'sospettoso. D'altra parte, lui o lei sarà, più probabilmente, basterà presumere che il corrispondente stia inviando email da un nuovo indirizzo leggermente diverso per qualche motivo. O che la funzione della rubrica del suo servizio di posta elettronica era pignola. Oppure ...

Ottieni il punto: questa tattica di imitazione di indirizzo e-mail ravvicinata può essere uno molto potente (anche se a volte trascurato) in attacchi di phishing / spearfishing.

Riguardo a ciò che i provider di posta elettronica possono fare e sono disposti a fare per cercare di bloccare registrazioni di indirizzi molto simili, è una pratica difficile combattere efficacemente anche se un provider di posta elettronica lo desidera. E considerando che qualsiasi fornitore di posta elettronica preferirebbe dire di registrare potenziali utenti "Scusa, quell'indirizzo / ID utente è già stato preso." il minor numero possibile di volte (se ricevono abbastanza quel messaggio potrebbero semplicemente rinunciare e vedere se un altro servizio di posta elettronica è libero da uno dei loro nomi desiderati) gli incentivi per i servizi di posta elettronica sono di consentire la registrazione di praticamente qualsiasi indirizzo email tecnicamente valido (con pochi eccezioni).

Concorda con tutti gli altri nel dichiarare che il primo indirizzo email è l'unico valido. Vorrei anche sottolineare che è una cattiva pratica consentire ulteriori spazi alla fine di un nome di accesso. Se ho capito bene, stai tentando di evidenziare potenziali somiglianze negli accessi utente / cliente al sistema.

Quindi in risposta alla tua domanda: "Questo dovrebbe essere considerato un problema di sicurezza?" La mia risposta sarebbe, no, per nessuno di quelli che non conteneva spazi aggiuntivi. Altrimenti, sì ... ma principalmente per il motivo, di seguito.

La tua domanda; "Qualcuno può suggerire eventuali problemi di sicurezza specifici che questa installazione potrebbe portare a?" In cima alla mia testa, mentre ci sono potenzialmente un po 'più di quanto non sia al momento a conoscenza, l'unica cosa che considererei è una specie di tipo di iniezione. Ma ciò si ridurrebbe a come gli spazi aggiuntivi sono definiti nella tua codifica. Se è bloccato abbastanza bene, non dovrebbe esserci un problema. Ma poi di nuovo, ogni tipo di tecnica viene sfruttata in modi sempre diversi. Quindi niente è veramente mai completamente sicuro. Quindi si può solo sperare e cercare di ottenere una maggiore sicurezza.

Sviluppo applicazioni Web per vivere, e posso dirlo. Anche se potrebbe non essere un "grosso" rischio per la sicurezza, è certamente uno sviluppo scadente per consentire a qualcuno di registrarsi con [email protected]; e / o "[email protected]".

Semplicemente perché lo sviluppatore non ha impiegato il tempo solitamente minimo per aggiungere la convalida dell'input. Voglio dire anche usando HTML5 semplice, se hai usato un

<input type="email" />

e provato uno dei secondi due indirizzi email il browser stesso ti mostrerebbe un errore che dice "Non è un indirizzo email valido (non testato a questo punto, ma presumo certamente dal momento che HTML5 è stato mainstream per qualche tempo).

Ma come lo sviluppatore, mai permetti a qualcuno di registrarsi con qualcosa nella loro email, che non dovrebbe essere lì. Ad esempio *, & amp ;, ^, $, ecc. Dovrebbe (a mio avviso) essere un indirizzo email alfanumerico valido che termina con un @ something.com / net / org, ecc.

È una pessima pratica non convalidare correttamente l'input dei moduli. Soprattutto quando ciò riguarda i potenziali dati del cliente, i dati dei clienti, i dati degli studenti e simili. È molto facile per i robot spam o altre forme di robot / umani malintenzionati trovare e annusare questo difetto e sfruttare il buco nel processo di input. Per questo, potrebbe essere un rischio per la sicurezza.

Però i miei due centesimi però. Spero che aiuti.