Sorgente Immagine: https://cdn.vectorstock.com
Introduzione
Ciao a tutti, oggi voglio proporvi un post particolare frutto di alcune ore libere ricavate nelle ultime settimane.
Un po per necessità e un po per curiosità ho cominciato ad approfondire l’argomento Cross-site Scripting (XSS).
Spulciando blog, documentazioni, e social mi sono imbattuto in vari security researcher, uno dei quali specializzato in vulnerabilità XSS: Ashar Javed.
Le sue referenze parlano da sole, infatti è presente in tutte le Security Hall of Fame dei maggiori colossi informatici: Google, Microsoft, Facebook, Twitter ecc…
Consiglio vivamente di seguirlo su twitter dato che spesso pubblica skill, payload, full disclosure, e video interessantissimi.
Visionando registrazioni di alcuni suoi seminari mi sono ritrovato spesso davanti alla la frase:
“XSS is everywhere & it is not going anywhere. It was there.. It is there & It will be there.”
A questo punto ho cominciato a pormi la domanda:
Ma davvero questa vulnerabilità è così diffusa?
Avrà ragione il buon Ashar?
Da qui l’idea di cercare semplici XSS sui siti delle testate online italiane (Si esatto, è l’ispirazione per il titolo del post “teXSState online, pasta, pizza e mandolino” ).
Ma ditemi un po: Vi siete mai documentati o cimentati nella vulnerabilità XSS?
Se siete appassionati di sicurezza informatica o penetration test sicuramente la risposta sarà affermativa, quindi potete saltare l’introduzione, altrimenti cercherò di spiegarlo nel migliore dei modi.
XSS è una delle vulnerabilità più diffuse che affliggono siti dinamici caratterizzati da pagine web contenti input non sanitizzati nei quali è possibile iniettare del codice malevolo (payload) al fine di accedere ai dati del browser (e non solo) dell’ignaro malcapitato.
Ma cosa succede alla vittima?
In poche parole il browser della vittima si trova ad interpretare attributi html e javascript che non sono ne presenti nel codice sorgente della pagina e neanche dovrebbero trovarsi nella risposta http (http response).
Le conseguenze ti questo tipo ti attacco possono essere svariate: dalla perdita incontrollata dei propri cookies, al phishing, fino ad arrivare all’installazione di una vera e propria backdoor (Fate un salto alla pagina di questo fantastico progetto: BEEF).
Gli attacchi XSS si posso suddividere fondamentalmente in 3 tipologie:
- Stored XSS Il payload viene iniettato in maniera permanente nello storage del server, come per esempio il database di un forum o social network.
In questo caso il browser della vittima verrà attaccato nel momento in cui l’applicazione recupererà i dati, compreso lo script malevolo, dal database. - Reflected XSS Il payload viene iniettato nei parametri di una pagina i quali verranno utilizzati dall’applicazione vulnerabile per generare una nuova pagina.
Un esempio potrebbe essere il form di ricerca di un sito web.
In questo caso il malintenzionato dovrà in qualche modo indurre la vittima a cliccare su un link creato ad hoc. - DOM XSS Il payload viene iniettato nel DOM di un javascript non sanitizzato, in questo caso però lo script malevolo verrà inviato direttamente al browser della vittima senza passare dal server.
I primi due tipi di attacchi vengono classificati anche come Server XSS o Server-side, dato che vanno a modificare l’http response, mentre il terzo Client XSS o Client-side.
Per una lettura teorica più approfondita vi rimando alla pagina della community OWASP
Prima di concludere la parte teorica voglio mostrare anche un semplice esempio pratico, così da far capire ancora meglio la funzionalità dell’attacco.
Copiate questa semplice paginetta xsstest.php nel vostro web server:
_!!! Per effettuare i prossimi test utilizzate il browser Firefox, dopo spiegherò la motivazione !!!
_
Come potete notare la pagina non fa altro che stampare a video un messaggio di benvenuto includendo il valore della variabile $visitatore passata col metodo GET:
GET Request
Questo è il sorgente html restituito dall’http response:
Adesso simuliamo un attacco XSS Reflected modificando l’url della pagina iniettando un payload javascript nella variabile $visitatore.
Il payload è il seguente: alert(/XSS/)
Lo scopo di questo attacco si limiterà a far eseguire al browser della vittima un alert javascript:
Ricontrollando il codice sorgente della pagina appena restituita dal server, si può notare come il payload javascript sia stato iniettato:
Questo era un esempio pratico di XSS Reflected anche se in uno scenario di attacco reale avremmo trovato al posto di alert(/XSS/) un payload più invasivo e probabilmente l’url del sito sarebbe stato offuscato con qualche servizio URL Shortner tipo bit.ly (Ricordatevi che chi esegue un attacco XSS Reflected deve indurre la potenziale vittima a caricare un determinato url sul proprio browser, quindi camufferà l’indirizzo del sito).
Per eseguire questi test ho utilizzato il browser Firefox perchè a differenza di altri browser, tipo Chrome, non utilizza filtri XSS Reflected.
Pronti..partenza..VIA!
Scrutando la Top Sites Italy del famoso sito Alexa ho notato tra le prime posizioni la presenza di molte testate online ed essendo siti pieni di form o moduli di ricerca, ho pensato che avrei avuto meno difficoltà a testare qualche XSS Reflected.
La motivazione di aver scelto siti italiani risiede nella curiosità di tastare il polso al panorama italiano al cospetto di questa vulnerabilità e non per schernire o denigrare il lavoro di altri colleghi.
La classifica verrà stilata dalla posizione più alta alla più bassa tenendo di conto che al momento della lettura potrebbe già essere variata.
Premetto che non pubblicherò i payloads utilizzati durante i test dato che al momento della pubblicazione di questo post le vulnerabilità risulteranno ancora attive!
Posizione Alexa n.10: repubblica.it
http://www.alexa.com/siteinfo/repubblica.it
Nel form di ricerca del sito repubblica.it sono presenti dei filtri che scartano o codificano in html i caratteri più utilizzati per iniettare degli attributi, come per sempio ” < > ‘ ; ecc.. per questo motivo lo classifico come NON vulnerabile
Posizione Alexa n.11: corriere.it
http://www.alexa.com/siteinfo/corriere.it
Nel form di ricerca del sito corriere.it sono presenti dei filtri che scartano o codificano in html i caratteri più utilizzati per iniettare degli attributi, come per sempio ” < > ‘ ; ecc.. ma nella sezione store è presente una vulnerabilità XSS Reflected:
Posizione Alexa n.16: gazzetta.it
http://www.alexa.com/siteinfo/gazzetta.it
Come per il corriere.it, anche nel sito web gazzetta.it risiede la stessa vulnerabilità nella sezione store, non a caso fanno parte dello stesso gruppo RCS:
Posizione Alexa n.24: ilfattoquotidiano.it
http://www.alexa.com/siteinfo/ilfattoquotidiano.it
Il sito ilfattoquotidiano.it si basa sul famoso CMS wordpress e non ho eseguito alcuna scansione per trovare eventuali vulnerabilità al core o ai plugins.
Posizione Alexa n.34: ilsole24ore.com
http://www.alexa.com/siteinfo/ilsole24ore.com
Il sito ilsole24ore.com risulta vulnerabile all’attacco XSS Reflected:
Posizione Alexa n.47: ansa.it
http://www.alexa.com/siteinfo/ansa.it
Il sito ansa.it risulta vulnerabile all’attacco XSS Reflected:
Posizione Alexa n.51: lastampa.it
http://www.alexa.com/siteinfo/lastampa.it
Il sito lastampa.it utilizza come form di ricerca la google search appliance, la quale non risulta vulnerabile all’attacco XSS Reflected.
Posizione Alexa n.80: ilmessaggero.it
http://www.alexa.com/siteinfo/ilmessaggero.it
Il sito ilmessaggero.it risulta vulnerabile all’attacco XSS Reflected, per onor di cronaca cito il full disclosure rilasciato dal security researcher Fabio Natalucci (Consiglio vivamente di seguirlo sui Twitter):
Posizione Alexa n.82: huffingtonpost.it
http://www.alexa.com/siteinfo/huffingtonpost.it
Nel form di ricerca del sito huffingtonpost.it sono presenti dei filtri che scartano o codificano in html i caratteri più utilizzati per iniettare degli attributi, come per sempio ” < > ‘ ; ecc.. per questo motivo lo classifico come NON vulnerabile
Posizione Alexa n.96: ilgiornale.it
http://www.alexa.com/siteinfo/ilgiornale.it
Il sito ilgiornale.it utilizza come form di ricerca la google search appliance, la quale non risulta vulnerabile all’attacco XSS Reflected.
Posizione Alexa n.105: corrieredellosport.it
http://www.alexa.com/siteinfo/corrieredellosport.it
Il sito corrieredellosport.it risulta vulnerabile all’attacco XSS Reflected:
Posizione Alexa n.129: liberoquotidiano.it
http://www.alexa.com/siteinfo/liberoquotidiano.it
Il sito liberoquotidiano.it risulta vulnerabile all’attacco XSS Reflected:
Posizione Alexa n.149: leggo.it
http://www.alexa.com/siteinfo/leggo.it
Il sito leggo.it risulta vulnerabile all’attacco XSS Reflected:
Posizione Alexa n.151: ilmattino.it
http://www.alexa.com/siteinfo/ilmattino.it
Il sito ilmattino.it risulta vulnerabile all’attacco XSS Reflected:
Posizione Alexa n.401: quotidiano.net
http://www.alexa.com/siteinfo/quotidiano.net
Il sito quotidiano.net risulta vulnerabile all’attacco XSS Reflected:
Conclusioni
Il risultato della ricerca è stato interessante, ben 9 siti web su 14 risultano vulnerabili all’attacco XSS reflected.
Se si pensa alla longevità e alla semplicità di questo attacco il risultato è sconcertante.
A mio parere ci sono almeno due considerazioni importanti:
- Vista la popolarità dei siti web vulnerabili, moltissimi visitatori sono potenzialmente a rischio.
- Molto probabilmente i siti web vulnerabili non sono stati sottoposti ad un penetration test, automatizzato o manuale, appropriato.
Tornando alla domanda che mi ero posto all’inizio dell’introduzione di questo articolo:
Ma davvero questa vulnerabilità è così diffusa?
Avrà ragione il buon Ashar?
Beh..mi sento di rispondere così:
e voi????
Alla prossima!!!!