LOL ridicola verifica di indirizzi email con regular expressions

[Sisupoika]

Chiunque usi internet si sara' trovato spesso in siti internet dove viene fatta la verifica di un indirizzo email mediante regular expressions (specialmente con javascript) che opera puramente sul formato dell'indirizzo, perche' questa e' la strada che purtroppo molti (poor) developers scelgono (o e' l'unica che conoscono) - personalmente nelle mie applicazioni opero la verifica dell'esistenza della mailbox direttamente sul server del dominio dell'indirizzo, ma sembra che purtroppo non molti sviluppatori facciano altrettanto).
Le regular expressions sono uno strumento molto potente per fare molte cose, ma leggendo attentamente le specifiche RFC2822 sull'SMTP (sto scrivendo un servizio web interfacciato ad un mail server), pare che molti siti web facciano controlli che non dovrebbero affatto, applicando restrizioni che non dovrebbero, toppando invece li' dove dovrebbero bloccare..usando caratteri speciali...

Es. Paragrafo 2.3.10: La prima parte dell'indirizzo email, quella che precede il simbolo @, e' definita "local part", e dovrebbe essere interpretata solo dall'host che riceve la mail inviata a quell'indirizzo, e che in pratica gestisce la posta elettronica per il dominio di quell'indirizzo email.

Indirizzi email del tipo:

"Abc\@def"@esempio.com
"Sisu Poika"@esempio.com
"Sisu\\Poika"@esempio.com
"Sisu@poika"@esempio.com
sisu/[email protected]
[email protected]
!def!xyz%[email protected]
[email protected]

stando alle specifiche dell'SMTP, sarebbero completamente validi, ma verrebbero bloccati da stupidi controlli javascript e simili, basati sulle regular expressions, solo perche' contengono caratteri come le virgolette, slash, backslash, dollaro, punto esclamativo, percentuale, underscore o altri simboli come la &, l'asterisco, il segno -, il simbolo di uguale, apice, apostrofo, elevato a potenza, circa, cancelletto, segno +, punto interrogativo, parentesi graffe!!!

Stando alle specifiche sull'SMTP, un validatore di indirizzi email dovrebbe praticamente ignorare la prima parte (locale) dell'indirizzo.

Cosa c'e' di piu'? Molti di questi controlli basati sulle RE bloccano anche indirizzi email che facciano uso del formato xxxx.xxxx.com, cioe' con un altro punto (o piu' di uno) precedenti l'estensione del dominio (come, nell'esempio, .com).
Anche questo e' errato!!! Pensate ai domini .name: io posso registrare un dominio del tipo sisu.poika.com (formato nome.cognome.com), ma a conti fatti mi verrebbe bloccato e rifiutato da moltissimi, innumerevoli applicazioni e servizi web!!!

Il bello, per chiudere, e' che molti servizi e applicazioni antispam e antiphishing usano le regular expressions per verificare la validita' di un indirizzo email, invece di verificarne l'esistenza fisica sul server, solo perche' piu' rapido. Ogni buon programmatore sa che vi sono caratteri speciali e trucchetti vari per aggirare anche regular expressions abbastanza restrittive, e certamente gli spammers professionisti ne sono a conoscenza.
Mi chiedo, dunque, perche' molti servizi e applicazioni continuino ad usare metodi cosi' stupidi per effettuare verifiche anziche' controllare l'esistenza della mailbox;

1) si rischia di bloccare indirizzi email validi (infatti, se e' vero che nessuno probabilmente usa indirizzi email del tipo che ho scritto sopra - sebbene validi secondo le specifiche, e' anche vero che in alcuni casi indirizzi con domini nome.cognome.com - giusto per esempio - verrebbero bloccati da una regola scritta male e che non tiene conto delle specifiche SMTP)

2) uno spammer che sa come aggirare controlli fatti con le regular expressions puo' scriversi un programmino che mandi milioni di emails generando indirizzi a tromba che bypassino tali controlli (credetemi, molto piu' facile di quanto probabilmente uno pensa).

L'invito e', dunque, agli sviluppatori in ascolto: verificate l'esistenza di una mailbox sul server (e' vero che e' un po' complicato scriversi del codice per far cio', ma e' anche vero che vi sono molti webservices pronti allo scopo), e lasciate perdere javascript e regular expressions

[Sisupoika]

ps: Il codice di questo stesso forum, VBulletin 3, riconosce come valido tra gli indirizzi di esempio che ho scritto, soltanto l'ultimo, [email protected]

[Sisupoika]

Nessun commento?

[W.S.]

Ciao Sisu!

Sicuramente usare javascript (o qualsiasi codice lato client) per verificare la validità dei dati immessi è una scelta discutibile, spesso sbagliata visto che basta creare la richiesta "a mano" per scavalcare il controllo.

Se l'unico scopo è verificare l'esistenza dell'indirizzo hai assolutamente ragione.

Però (non serve certo che te lo dica io ) è sempre buona norma verificare i dati prima di usarli, per questo i controlli sono molto più restrittivi. Da protocollo SMTP, un indirizzo contenente un vettore d'attacco può essere valido ma la nostra applicazione potrebbe venirne compromessa. Il tuo metodo può (ovviamente in teoria) essere sfruttato per inviare un injection vector ad un server smtp vulnerabile usando la tua applicazione.
Nella maggior parte dei casi, i controlli che reputi troppo restrittivi servono ad evitare che il campo "indirizzo mail" venga usato per attaccare l'applicazione.

[wizard1993]

Originariamente inviato da Sisupoika

Nessun commento?

secondo me non c'è spazio per i commenti; credo i complimenti per le tue ricerche contiune di bug ti siano già stati fatti; e in generale anche questo topic non fa che accrescere la tua reputazione di ottimo utente;
comuqnue bella scoperta

[Sisupoika]

Originariamente inviato da W.S.

Ciao Sisu!

Sicuramente usare javascript (o qualsiasi codice lato client) per verificare la validità dei dati immessi è una scelta discutibile, spesso sbagliata visto che basta creare la richiesta "a mano" per scavalcare il controllo.

Se l'unico scopo è verificare l'esistenza dell'indirizzo hai assolutamente ragione.

Però (non serve certo che te lo dica io ) è sempre buona norma verificare i dati prima di usarli, per questo i controlli sono molto più restrittivi. Da protocollo SMTP, un indirizzo contenente un vettore d'attacco può essere valido ma la nostra applicazione potrebbe venirne compromessa. Il tuo metodo può (ovviamente in teoria) essere sfruttato per inviare un injection vector ad un server smtp vulnerabile usando la tua applicazione.
Nella maggior parte dei casi, i controlli che reputi troppo restrittivi servono ad evitare che il campo "indirizzo mail" venga usato per attaccare l'applicazione.

Ciao WS! (ma dov'eri finito? )
Il bello di questa cosa, che volevo sottolineare, e' che questi controlli possono sembrare restrittivi eliminando possibili indirizzi email invece validi (dal momento che questi controlli ignorano alcune parti delle specifiche) ma dal momento che ci sono trucchetti per bypassarli e considerando che la grande maggioranza degli sviluppatori di certo non verifica l'esistenza di una mailbox sul server, questi controlli per me sembrano, appunto, restrittivi.
Intendevo questo, piu' che altro, ma anche con le injection alla fine si puo' giocare proprio perche' una volta bypassate le re, e' molto probabile che non vi siano migliori controlli server side.

Originariamente inviato da wizard1993

secondo me non c'è spazio per i commenti; credo i complimenti per le tue ricerche contiune di bug ti siano già stati fatti; e in generale anche questo topic non fa che accrescere la tua reputazione di ottimo utente;
comuqnue bella scoperta

Grazie ma...non intendevo ovviamente questo.

[W.S.]

Originariamente inviato da Sisupoika

Ciao WS! (ma dov'eri finito? )

Hehe, negli ultimi 6 giorni la cosa più tecnologica che mi son portato appresso è stato l'RFID dello skipass

Originariamente inviato da Sisupoika

Intendevo questo, piu' che altro, ma anche con le injection alla fine si puo' giocare proprio perche' una volta bypassate le re, e' molto probabile che non vi siano migliori controlli server side.

Questo è un problema sempre più diffuso (complice anche il web2.0), si tende a dimenticare l'importanza di validare i dati lato server. Sono davvero pochi i casi in cui possiamo fidarci dell'utente, eppure spesso si trovano applicazioni web che danno per scontata la correttezza dei dati che il client invia al server.

[Sisupoika]

Esatto

[vectorx]

Non per andare contro il tuo pensiero, sisupoika, ma se ho capito bene tu attiveresti un socket sulla 25 e faresti un helo per vedere se ti restituisce un '200'.
GIUSTO?
Però nel caso in cui il server mail fosse down, o se tutto il server fosse down per un giorno, o ancora se tu non avessi accesso al server SMTP impediresti l'iscrizione dell'utente al sito.

[Sisupoika]

Hai riesumato un post vecchio 3 anni?
Cmq per rispondere alla tua domanda, non necessariamente, immagino dipenda anche dal tipo di servizio. Quel tipo di controllo potrebbe essere disattivato solo in quei -teoricamente rari- momenti in cui mail puo' essere down.

[vectorx]

È un argomento interessante e sono ideciso su come fare questo test per il mio sito.
All'epoca ho sempre e solo controllato le RE ma è un metodo che fa abbastanza schifo, perché poi mi trovo in database un'infinità di utenti temporanei che dovranno essere cancellati.
Io anzichè fare tutto quel robo con il socket controllerei prima con uno script lato server le RE e poi effettuerei un bel DNS al dominio per vedere se è esistente.
Siccome ancora non l'ho provato, secondo te sussiste lo stesso il problema del server down?
Il DNS server ha un database all'interno. Credo dovrebbe essere diennessatto anche se down. Mai provato?
Di sicuro riesco a scansare il problema dell'accesso non concesso all'SMTP.
Altri metodi?