Impedire il Cross-site scripting XXS e riparare le vulnerabilità
Con Cross-site scripting (XSS) si indica lo sfruttamento di vulnerabilità nelle applicazioni web. Gli script dannosi vengono inseriti su siti sconosciuti e riescono così ad accedere al sistema dell’utente. Gli script sono programmi sviluppati con linguaggi di scripting come JavaScript, che vengono inseriti nel browser. In caso di varianti innocue si tratta per esempio di finestre pop-up con saluti di benvenuto. Nel peggiore dei casi, grazie a questi script, gli hacker riescono ad accedere ad informazioni riservate o al computer dell’utente.
Il pericolo di un cross-site scripting sorge se le rispettive applicazioni web inoltrano i dati utente al browser senza previa verifica. In questo modo gli script dannosi riescono ad arrivare ai clients coinvolti e così le applicazioni danneggiate manipolano gli script lato server come moduli per immissione dei dati utente. Mentre all’utente tutta la procedura sembra criptata e anonima, i dati vengono in realtà trasmessi in modo non filtrato.
Non tutti gli attacchi XSS mirano a rubare informazioni sensibili o a danneggiare in modo diretto il client coinvolto. Ugualmente diffusi sono gli script che abusano del rispettivo client trasformandolo in un iniziatore di attacchi phishing e malware o che modificano negativamente il contenuto del sito; i veri autori restano di solito anonimi.
Esempi Cross-site scripting: quali tipi di attacchi XXS esistono?
Per illustrare meglio cosa significa concretamente il Cross-site scripting per i gestori di siti e visitatori, trovate di seguito una breve lista e spiegazione dei diversi tipi di XSS.
Cross-site scripting riflesso/XSS
Richiamando un URL manipolato o inviando un modulo già pronto, lo script dannoso viene inviato al web server, che lo rimanda nuovamente al client senza verificarlo. Il codice dannoso non viene salvato sul server ed esiste solo temporaneamente nella produzione del sito attraverso il client danneggiato. Gli obiettivi più diffusi sono siti web dinamici o applicazioni e-mail.
Esempio: in questa variante XSS l’aggressore colloca il suo script in un link già pronto. In seguito tenta di inoltrare il link (soprattutto tramite e-mail). Il codice dannoso contenuto viene attivato solo se l’utente apre il link ricevuto e a quel punto, gli si presenta per esempio una schermata di login simile a quella del suo online banking. Invece di mandare i dati al server della banca, lo script fa in modo che avvenga una deviazione nell’indirizzo che l’hacker ha precedentemente definito.
Cross-site scripting XSS persistente
Con un XSS persistente o costante gli script dannosi vengono salvati sul server e, ad ogni chiamata, consegnate tramite il client. A tale scopo queste applicazioni web vengono selezionate per l’attacco, salvano i dati utente lato server e in seguito li consegnano senza verifica o codificazione. Particolarmente soggetti a questo tipo di scripting sono blog e forum.
Esempio: in un forum gli interventi degli utenti vengono salvati in un database, spesso senza un sufficiente controllo. Questa è l’occasione giusta per gli hacker, che aggiungono ad un post normale uno script dannoso. Gli utenti ignari ricevono il relativo link del post per e-mail o arrivano in modo casuale alla voce corrispondente ed eseguono lo script aprendolo.
Cross-site scripting basato su DOM
Questo tipo di attacco viene chiamato anche XSS locale. Con l’inserimento di un URL manipolato, il codice dannoso viene eseguito senza verifica attraverso una vulnerabilità in uno script del client. Al contrario che in un XSS persistente e riflesso, il server web non prende parte a questo processo. Di conseguenza anche siti statici, che supportano i relativi linguaggi di scripting, vengono danneggiati tramite queste varianti di scripting.
Esempio: lo scripting basato su DOM, come il Cross-site scripting riflesso, presuppone che il link venga aperto dall’utente. Dopo l’apertura del link lo script legge sulla pagina web il valore dell’argomento dell’URL ed esegue poi lo script contenuto al suo interno. In questo modo possono essere per esempio rubati i cookie di sessione.
Come proteggersi da attacchi XSS
Le conseguenze negative che un Cross-site scripting ha per gli utenti e i gestori di siti non vanno sottovalutate: come utenti rischiate la perdita dei vostri dati o passate inconsapevolmente come complici involontari degli hacker. Come gestori di un sito siete responsabili dei dati dei vostri clienti e dei vostri visitatori, i quali possono essere coinvolti in modo diretto in seguito ad attacchi: contenuti dannosi e interruzioni del server riducono il numero di visitatori e, a lungo termine, motori di ricerca come Google reagiscono con penalizzazioni e potenziali clienti cominciano a mostrare sfiducia. Questo può causare perdite finanziarie, pertanto sia che siate gestori di siti sia semplici utenti dovreste prendere assolutamente misure per evitare i Cross-site scripting.
Misure di sicurezza per gli utenti
Il modo più semplice per evitare i Cross-site scripting è disattivare il supporto JavaScript nel browser. Se JavaScript è disattivato, gli XSS basati su DOM che puntano a JavaScript non hanno alcun effetto, in quanto l’applicazione dannosa non può neanche essere avviata. Per alcuni browser esistono inoltre add-on che aiutano a proteggersi da attacchi XSS come ad esempio le estensioni NoScript per Mozilla. Nelle impostazioni predefinite tutti i contenuti attivi dei siti come JavaScript, Java-Applets, Adobe Flash o Microsoft Silverlight sono bloccati in modo automatico. Su richiesta potete bloccare temporaneamente una pagina o metterla nella whitelist, se siete assolutamente sicuri che sia affidabile. Un ultimo consiglio valido non soltanto per gli attacchi XSS: siate sempre scettici nei confronti di dati esterni, come i link, e metteteli sempre sotto la lente d’ingrandimento prima di utilizzarli.
Cosa fare contro attacchi XSS in qualità di gestori
Affinché le vostre applicazioni web non offrano una base per attacchi XSS dovete in primo luogo considerare come insicuri tutti i valori di input. Prima che il server li riceva, dovrebbero essere analizzati. In questo caso il metodo più sicuro, come avviene con l’add-on NoScript per i client, è quello di creare una whitelist. Se siete in grado di eseguire la scansione di informazioni sul vostro sito e abilitare soltanto contenuti affidabili, create in questo modo una protezione eccellente contro attacchi Cross-site scripting.
Oltre ai valori immessi, anche i dati in uscita dovrebbero essere messi al sicuro. Sarebbe quindi necessario che i problematici metacaratteri HTML vengano sostituiti dai relativi riferimenti di caratteri; per questo i metacaratteri vengono visti come caratteri normali e script potenzialmente dannosi non vengono avviati. La maggior parte dei linguaggi di programmazione e di scripting come Perl, JavaScript o PHP hanno a tale scopo funzioni già predefinite per la sostituzione o il mascheramento di caratteri, che potete utilizzare senza esitazione. Semplici attacchi XSS possono essere respinti grazie all’uso di firewalls.
Il Cross-site scripting costituisce spesso solo lo stadio iniziale per attacchi più aggressivi, che potete sventare già sul nascere con una protezione completa dei flussi di dati in entrata e in uscita del vostro server web.