È possibile un indirizzo email valido (qualcosa che funzionerebbe se usato mandare a gmail, per diverse definizioni di valido (l'e-mail non sarebbe l'exploit)) per contenere javascript che potrebbe essere sfruttato se reso e l'output non è sterilizzato (correttamente codificato)? in tal caso, fornire un esempio.
Direi che teoricamente (e praticamente, a seconda della funzione di risanamento), sì , la parte locale di un'e-mail può essere utilizzata negli attacchi XSS.
Il problema è che gli indirizzi email sono complessi e possono includere un numero di caratteri speciali. Inoltre, gli indirizzi e-mail offrono funzionalità come commenti e stringhe tra virgolette, che consentono anche caratteri più speciali.
XSS nella parte locale dell'indirizzo email
[Sto utilizzando l'informazione rfc3696 , perché è molto più piacevole da leggere rispetto a quella ufficiale RFC.]
The exact rule is that any ASCII character, including control characters, may appear quoted, or in a quoted string.
Quindi un indirizzo email valido sarebbe:
"<script>alert(1)</script>"@example.com
Puoi testarne la validità qui . Questo ovviamente non è sicuro.
Ulteriori possibilità
Anche senza stringhe tra virgolette, un attaccante può almeno avvicinarsi:
Without quotes, local-parts may consist of any combination of alphabetic characters, digits, or any of the special characters ! # $ % & ' * + - / = ? ^ _ ' . { | } ~
Questo è già sufficiente per inserire un contesto javascript, ad esempio:
<a href='mailto:USER_EMAIL'>email me</a>
via:
foo'onclick='alert'foo='@example.com
Il problema qui è che ( non è consentito, ma non sarei a mio agio a stamparlo sull'utente finale non codificato. Per lo meno, un utente potrebbe cambiare lo stile: foo'style='color:red'title='imImportant'@example.com .
Puoi anche posizionare il payload all'interno di un commento della parte locale, quindi non si applicano eventuali restrizioni del tuo provider di posta elettronica, ad esempio: ("<script>alert</script>")[email protected] , dove [email protected] è il tuo indirizzo email (qui, le stesse regole di cui sopra apply - < e > possono essere solo all'interno di stringhe tra virgolette; inoltre, non puoi avere ( e ) , anche in stringhe tra virgolette).
E questa è solo la parte locale. La parte del dominio fornisce a un utente malintenzionato ulteriori vettori di attacco.
Difesa adeguata
Questo è il motivo per cui la prevenzione XSS non dovrebbe riguardare il filtraggio, ma la codifica corretta. Tutti i personaggi pericolosi (nella maggior parte dei contesti - ma non tutti - questi sono almeno ' , " , < e > ) dovrebbero essere codificati in HTML quando vengono inviati a un utente, indipendentemente dal filtro precedentemente applicato.
Oltre a l'eccellente risposta di Tim , Gmail implementa una politica di sicurezza dei contenuti per impedire che qualsiasi script che riesca a ignorare i loro filtri esegua il rendering in browser supportati .
Quindi sì, mentre un indirizzo email può contenere tag "<script>alert('foo')</script>"@example.com Sarei sorpreso se Google non lo codificasse correttamente, e come detto hanno il CSP per proteggere gli utenti se non lo fossero. Detto questo, c'è stato un bug recente nell'app Gmail in Android che consentiva agli indirizzi di apparire come se fossero stati falsificati a prima vista.
Leggi altre domande sui tag javascript penetration-test exploit