Il motivo della sigla xss e non css , è proprio per evitare di far confondere i meno esperti con la sigla css che in gergo webmaster sta per “Cascading Style Sheets” L’attacco XSS appartiene alla tipologia injection, quindi si tratta di immissione di codice arbitrario in input alle pagine web. A differenza di sqlinjection ed altri attacchi alle web application trattati precedentemente a questo attacco , sono vulnerabili siti dinamici e non . L’attacco può essere portato a compimento su qualsiasi sito che presenti l’utilizzo di tecnologie come javascript, VBScript, actvex, html e Flash. Per chi non conosce queste tecnologie , basti pensare che si tratta di linguaggi e applicazioni che vengono eseguiti direttamente dal vostro webbroswer (internet explorer, netscape, Mozilla Firefox, ecc.)
Come al solito, questa vulnerabilità è dovuta agli errori dei programmatori, che molto spesso trascurano completamente la validazione delle informazioni passate in input al sito dagli utenti.
L’attacco Cross Site Scripting è quindi possibile d’attuazione, quando un sito web prende in input dati su cui effettua delle operazioni. Queste informazioni vengono inviate al sito solitamente tramite url. Questi dati, in siti non protetti, vengono visualizzati cosi’ come sono stati inseriti dagli utenti. Potenzialmente la vittima dell’attacco non è solo il sito, ma anche l’utente, proprio perché occorre un semplice link che porta ad una pagina di un sito non protetta per creare danni. Cliccando infatti incautamente su uno di questi link che si può trovare su un sito web o una mail , si può cadere vittima di questo attacco il cui fine è solitamente quello di raccogliere dati degli utenti , leggere i cookie, dirottare l’utente su un altro sito o visualizzare falsa pubblicità.
Analisi dell’attacco
Immaginate di essere su un forum o di scrivere su un guestbook
Nel testo scriveremo un cosa come:
<script>location='http://www.notrace.it/';</script>Successivamente salviamo il nostro testo su un forum non protetto da questo attacco e avremo come risultato che chi carica la pagina con il nostro messaggio , sarà reindirizzato al sito www.notrace.it
Detto così non sembra poi tanto dannoso, ma pensate se sul sito su cui effettuo il reindirizzamento , creo pagine che permettono la raccolta dei dati , ottengo ad esempio il risultato di poter leggere i cookie rilasciati dal sito vittima e di inviarli ad una pagina appositamente creata . Se i cookie non sono crittografati , come succede spesso , si ha che l’attaccher otterrà user e password di tutte le persone che visitano la pagina del forum contenente il suo messaggio. Si può pensare anche ad un codice che faccia comparire qualche messaggio di alert come finestre di errore o che carichi all’interno della pagina attaccata un sito esterno.
È possibile ad esempio, manipolare il tag <img> che in html si occupa di visualizzare le immagini in modo che faccia comparire una finestra di alert
La stessa cosa per eludere eventuali filtri del web master potrebbe essere scritta informato Hex
Oppure in decimale:
Il codice cosi scritto, potrebbe essere inserito in una mail e magari codificato in modo da renderlo poco visibile. Potrebbe essere spacciato per un collegamento del sito e renderebbe gli utenti più vulnerabili ad attacchi di phisching. Inserendo ad esempio un redirect nel codice iniettato l’utente crede di andare sul sito http://www.sito-vittima.xx/ mentre si trova sul sito http://www.furbetto.xxx ,
che in caso di attacco phishing sarà sicuramente creato ad immagine e somiglianza del sito vittima rendendo quindi ulteriormente complesso il riconoscimento del phishing .
Come difendersiPer gli sviluppatori è opportuno controllare minuziosamente ogni informazione inserita in input dagli utenti prima di inoltrarla alle proprie applicazioni .
Per gli utenti è necessario cercare di tenere sempre aggiornato il proprio browser, i browser permettono di disabilitare l’utilizzo di linguaggi come javascript, vbscript, activix .
Nessun commento:
Posta un commento