Indietro

ⓘ Cross-site scripting




                                     

ⓘ Cross-site scripting

Il cross-site scripting è una vulnerabilità che affligge siti web dinamici che impiegano un insufficiente controllo dellinput nei form. Un XSS permette a un cracker di inserire o eseguire codice lato client al fine di attuare un insieme variegato di attacchi quali, ad esempio, raccolta, manipolazione e reindirizzamento di informazioni riservate, visualizzazione e modifica di dati presenti sui server, alterazione del comportamento dinamico delle pagine web, ecc.

Nellaccezione odierna, la tecnica ricomprende lutilizzo di qualsiasi linguaggio di scripting lato client tra i quali JavaScript, VBScript, Flash. Il loro effetto può variare da un piccolo fastidio a un significativo rischio per la sicurezza, a seconda della sensibilità dei dati trattati nel sito vulnerabile e dalla natura delle strategie di sicurezza implementate dai proprietari del sito web.

Secondo un rapporto di Symantec nel 2007, l80% di tutte le violazioni è dovuto ad attacchi XSS.

                                     

1. Origine e trasformazione del concetto

La sicurezza nel web dipende da una varietà di meccanismi incluso il concetto di fiducia noto come Same origin policy. Questo afferma in sostanza che se al contenuto del primo sito viene concessa lautorizzazione di accedere alle risorse di un sistema, allora qualsiasi contenuto da quel sito condividerà queste autorizzazioni, mentre il contenuto di un altro sito deve avere delle autorizzazioni a parte.

Gli attacchi Cross-site scripting usano vulnerabilità note delle applicazioni web, nei loro server o dei plugin su cui si basano. Sfruttando una di queste vulnerabilità, gli aggressori iniettano contenuto malevolo nel messaggio fornito dal sito compromesso in modo che quando arriva nel web browser lato client risulti inviato dalla fonte attendibile, così da operare secondo le autorizzazioni concesse a quel sistema. Iniettando script malevoli lutente malintenzionato può ottenere privilegi di accesso al contenuto di pagine sensibili, ai cookie di sessione e a una varietà da altre informazioni gestite dal browser per conto dellutente.

Gli ingegneri della sicurezza di Microsoft hanno introdotto il termine cross-site scripting nel gennaio del 2000.

Lespressione cross-site scripting originariamente si riferiva unicamente ad attacchi basati sullutilizzo di frammenti di codice JavaScript inseriti allinterno di chiamate di richiesta a pagine web dinamiche poste su un web-server tecnica facente parte dei metodi di code injection in modo che il server remoto eseguisse operazioni diverse da quelle previste originariamente dallapplicativo web. Tale definizione gradualmente si è estesa comprendendo anche altre modalità di "iniezione di codice" basate non solo su JavaScript ma anche su ActiveX, VBScript, Flash, o anche puro HTML. Ciò ha generato una certa confusione nella terminologia riferita alla sicurezza informatica; il termine, infatti, ricomprende oggi tutto un insieme di tecniche di attacco e non esclusivamente quella basata su manipolazione di codice JavaScript.

Vulnerabilità XSS sono state segnalate e sfruttate dal 1990. Siti noti sono stati compromessi nel passato, inclusi siti di social-network come Twitter, Facebook, MySpace, YouTube e Orkut. Negli anni successivi, i problemi di cross-site scripting hanno superato quelli di buffer overflows diventando la vulnerabilità di sicurezza più comunemente segnalata, tantè che alcuni ricercatori nel 2007 hanno supposto che il 68% dei siti probabilmente sarebbero esposti ad attacchi XSS.

                                     

2. Tipologie

La maggior parte degli esperti distingue almeno due principali tipi di vulnerabilità XSS: non persistente e persistente. Alcune fonti dividono ulteriormente questi due gruppi in tradizionale causate da problemi nel codice lato server e DOM-based nel codice lato client.

                                     

2.1. Tipologie Reflected non-persistent

Le vulnerabilità cross-site scripting di tipo reflected sono sicuramente le più comuni. È possibile sfruttarle quando i dati forniti dallutente di solito tramite form HTML sono usati immediatamente dallo script lato server per costruire le pagine risultanti senza controllare la correttezza della richiesta.

Dato che i documenti HTML hanno una struttura piatta in cui sono mescolate istruzioni di controllo, di formattazione e di contenuto effettivo, se tutti i dati forniti dallutente non validati sono inclusi nella pagina risultante senza unadeguata codifica HTML, questo può portare a iniezione di codice di markup. Un esempio classico di un potenziale vettore è il motore di ricerca del sito: se si cerca una stringa, in genere questa verrà visualizzata di nuovo nella pagina dei risultati per indicare cosa si è cercato. Se questa risposta non evita o rigetta i caratteri di controllo HTML si consegue che è vulnerabile ad attacchi cross-site scripting.

Un attacco non persistente è tipicamente inviato via mail o da un sito web neutrale. Lesca è un URL dallaspetto innocente, che punta a un sito attendibile ma che contiene un vettore XSS. Se il sito affidabile è vulnerabile a quel vettore, il click sul link può causare lesecuzione di script iniettato nel browser della vittima.



                                     

2.2. Tipologie Persistent

Una vulnerabilità XSS persistente o stored è una variante più devastante di cross-site scripting: si verifica quando i dati forniti dallattaccante vengono salvati sul server, e quindi visualizzati in modo permanente sulle pagine normalmente fornite agli utenti durante la normale navigazione, senza aver eliminato dai messaggi visualizzati dagli altri utenti la formattazione HTML.

Ad esempio, supponiamo che ci sia un sito di incontri in cui i membri visionano i profili degli altri membri per cercare interessi comuni. Per motivi di privacy, questo sito nasconde a tutti il vero nome e la mail degli utenti. Queste informazioni sono tenute segrete dal server. Lunico momento in cui il nome reale e lemail sono visualizzati è quando il membro si autentica, non potendo vedere comunque i dati di chiunque altro.

Supponiamo che un attaccante si colleghi al sito e voglia capire i veri nomi delle persone che vede sul sito. Per fare ciò scrive uno script progettato per essere eseguito dal browser delle altre persone quando visitano il suo profilo. Lo script invia un breve messaggio al suo server che raccoglie queste informazioni.

Per fare questo, per il quesito" Descrivi il tuo primo appuntamento ideale”, lattaccante dà una risposta breve dallaspetto consueto ma il testo alla fine della risposta è lo script per rubare i nomi le mail. Se lo script è racchiuso allinterno di un elemento non verrà visualizzato a schermo. Quindi supponiamo che Bob, membro del sito di incontri, raggiunga il profilo dellattaccante, dove viene visualizzata la risposta alla domanda riguardo al primo appuntamento ideale. Lo script viene automaticamente eseguito dal browser e ruba il nome reale e la mail di Bob direttamente dalla sua macchina.

Le vulnerabilità XSS di tipo persistente possono essere molto più significative rispetto alle altre perché lo script dannoso dellattaccante è fornito automaticamente senza la necessità di indirizzare la vittima o attirarla nel sito di terze parti. In particolare nel caso di siti di social-network, il codice potrebbe essere progettato per propagarsi autonomamente tra gli account, creando un tipo di worm lato client.

I metodi di iniezione possono variare tantissimo, in alcuni casi lattaccante non ha nemmeno bisogno di interagire con le funzionalità web per sfruttare una falla. Tutti i dati ricevuti da una applicazione web che possono essere controllati da un utente malintenzionato potrebbero diventare vettore di iniezione.

                                     

2.3. Tipologie Server-side vs vulnerabilità DOM-based

Storicamente le vulnerabilità XSS sono state trovate in applicazioni che svolgevano tutto il processamento dei dati lato server. Linput dellutente tra cui un vettore XSS sarebbe stato inviato al server per poi essere rimandato indietro come una pagina web. La necessità di migliorare la user experience ha dato popolarità ad applicazioni che avevano una logica di presentazione scritta in JavaScript che inviava i dati, su richiesta, al server usando AJAX.

Mentre il codice JavaScript processa anche gli input dellutente e li visualizza nella pagina web, la nuova sottoclasse di attacchi XSS di tipo reflected ha iniziato ad apparire ed è stata chiamata DOM-based cross-site scripting. Negli attacchi XSS DOM-based, i dati malevoli non sono toccati dal server web, piuttosto, sono riflessi dal codice JavaScript interamente sul lato client.

Un esempio di vulnerabilità XSS DOM-based è un bug trovato nel 2011 in una serie di plugin JQuery. Le strategie di prevenzione per gli attacchi XSS DOM-based includono misure molto simili alle strategie tradizionali di prevenzione XSS, ma implementate in codice JavaScript e incluse nelle pagine. Alcuni framework JavaScript hanno creato contromisure contro questi e altri tipi di attacchi - ad esempio Angular.js.

                                     

3. Un esempio di attacco

Gli attaccanti che tentano di sfruttare le vulnerabilità di cross-site scripting devono affrontare ogni classe di vulnerabilità in modo differente. Per ogni classe, è descritto uno specifico vettore di attacco. I nomi utilizzati in seguito sono nomi tecnici comunemente usati nellambito della sicurezza informatica.

                                     

3.1. Un esempio di attacco Non-persistent

  • La pagina visualizza alertxss; non trovato" insieme a un messaggio di errore con il testo" xss”
  • Viene visualizzato un box di avviso che dice" xss”
  • Quando si visita la pagina di ricerca, si inserisce un termine nella casella di ricerca e si fa click sul tasto invio, se non ci sono risultati la pagina visualizzerà il termine cercato seguito dalle parole" non trovato”, e lURL sarà
  • Con una normale query di ricerca, come la parola" cuccioli”, la pagina visualizzerà semplicemente" cuccioli non trovato” e lURL è questo è un comportamento normale.
  • Alice visita spesso un particolare sito web, che è ospitato da Bob. Il sito web di Bob permette ad Alice di autenticarsi con username e password e di memorizzare dati sensibili come i dati di fatturazione. Quando accede nel sistema, il browser mantiene un cookie di autenticazione, che si presenta come un insieme di caratteri illeggibili, in modo che entrambi i computer client e server si ricordino della sua autenticazione.
  • LURL sfruttabile è alertxss;
  • Tuttavia, quando si invia una query anomala di ricerca, come alertxss;,
  • Mallory nota che il sito di Bob contiene una vulnerabilità XSS di tipo reflected
  • Invia una mail ad alcuni ignari membri del sito di Bob, in cui scrive:" Controlla alcuni simpatici cuccioli”
  • Mallory crea un URL per sfruttare lexploit
  • Crea lURL. Sceglie di convertire i caratteri ASCII in esadecimale, ad esempio in modo che eventuali lettori umani non possano immediatamente decifrare lURL dannoso.
  • Il programma authstealer.js esegue nel browser di Alice come se fosse stato inviato dal sito di Bob. Prende una copia del cookie di autenticazione di Alice e lo invia al server di Mallory, dove Mallory lo recupererà.
  • Alice riceve la mail e, dato che ama i cuccioli, apre il link. Andrà quindi sul sito di Bob per la ricerca; non trovando nulla visualizzerà" Cuccioli non trovato”, ma lo script di Mallory, authstealer.js, eseguirà, invisibile sullo schermo, scatenando lattacco XSS.
  • Mallory adesso inserisce il cookie di autenticazione di Alice nel suo browser come se fosse il proprio. Va poi sul sito di Bob, adesso è autenticato come Alice.
  • Ora che è riconosciuta dal sito come Alice, Mallory va nella sezione fatturazione del sito e guarda il numero di carta di credito e lo copia. Cambia anche la password in modo che Alice non possa nemmeno più entrare.
  • Decide di fare un ulteriore passo avanti e invia un collegamento simile a Bob stesso, guadagnando così i privilegi di amministratore.

Affinché questo attacco non si verifichi oppure per ridurne gli effetti nel casi si verificasse si possono adottare differenti strategie:

  • Il server web potrebbe rilevare un accesso simultaneo da due diversi indirizzi IP e invalidare le sessioni.
  • Linput del campo di ricerca potrebbe essere analizzata per correggere o eliminare eventuali codici.
  • Il server web potrebbe essere impostato in modo da reindirizzare le richieste non valide.
  • Il sito web potrebbe visualizzare solo le ultime cifre della carta di credito utilizzata in precedenza.
  • Il server web potrebbe rilevare un accesso simultaneo e invalidare le sessioni.
  • Gli utenti potrebbero essere istruiti a non cliccare link dallaspetto innocente in realtà malevoli
  • Il sito web potrebbe richiedere agli utenti di inserire nuovamente la propria password prima di cambiare le informazioni di registrazione.


                                     

3.2. Un esempio di attacco Attacco persistente

  • Mallory osserva che il sito di Bob contiene una vulnerabilità XSS. Se si va nella sezione News e si posta un commento, verrà visualizzato ciò che è stato digitato. Ma se il testo del commento contiene dei tag HTML i tag verranno visualizzati così come sono. Lo stesso accadrà per eventuali tag di script.
  • Quando Alice o chiunque altro utente carica la pagina con il commento, lo script di Mallory viene eseguito, ruba il cookie di sessione di Alice e lo invia al server segreto di Mallory.
  • Mallory legge larticolo nella sezione News e scrive in un commento. Nel commento inserisce questo testo: Io amo i cuccioli di questa storia. Sono così carini!,
  • Mallory può quindi sfruttare la sessione di Alice e usare il suo account fino a una eventuale invalidazione del cookie.
  • Mallory crea un account sul sito di Bob.

Il software del sito di Bob avrebbe potuto analizzare i commenti nella sezione notizie e rimuovere o correggere eventuali script, ma non lha fatto, in questo risiede il bug di sicurezza.

                                     

4.1. Come difendersi Encoding delloutput contestuale/escaping delle stringhe di input

Questa misura dovrebbe essere usata come meccanismo primario di difesa per fermare gli attacchi XSS. Ci sono diversi schemi di escaping che possono essere usati, tra cui HTML entity encoding, JavaScript escaping, CSS escaping, e URL encoding. Molte applicazioni web che non accettano rich data possono usare lescaping per eliminare la maggior parte dei rischi derivati da attacchi XSS in modo abbastanza semplice.

                                     

4.2. Come difendersi Convalidare in modo sicuro linput non attendibile

Molte operazioni di particolari applicazioni web permettono agli utenti di utilizzare un sottoinsieme limitato di markup HTML. Quando si accetta linput HTML da parte degli utenti, ad esempio molto largo", la codifica in uscita, come molto largo", non sarà sufficiente dal momento che deve essere reso come HTML dal browser. Fermare un attacco XSS quando si accettano input HTML dallutente, è molto complesso in questa circostanza. Linput HTML non attendibile deve essere eseguito attraverso un HTML sanitization engine per garantire che non contenga codice XSS.

                                     

4.3. Come difendersi Sicurezza dei cookie

Oltre al filtraggio dei contenuti, sono comunemente usati altri metodi per mitigare il cross-site scripting.

Un esempio è luso di controlli di sicurezza aggiuntivi durante la manipolazione della sessione basata sui cookie. Molte applicazioni web si basano sui cookie di sessione per gestire lautenticazione tra le diverse richieste HTTP, e dato che gli script lato client hanno generalmente accesso a questo cookie, semplici XSS possono rubarli. Per mitigare questa particolare minaccia, molte applicazioni web legano il cookie di sessione allindirizzo IP dellutente che ha ottenuto laccesso in origine, quindi permette solo a tale IP di utilizzare il cookie. Questo è efficiente nella maggior parte dei casi ma ovviamente non funziona in situazioni in cui un attaccante si trova dietro lo stesso NATed indirizzo IP lo stesso web proxy della vittima, o la vittima sta cambiando il proprio IP mobile.

Unaltra soluzione è presente in Internet Explorer dalla versione 6, Firefox dalla versione 2.0.0.5, Safari dalla versione 4, Opera dalla versione 9.5 e Google Chrome; è il flag HttpOnly che consente a un server web di settare un cookie non accessibile dallo script lato client. Se usata, la funzione può prevenire completamente il furto di cookie ma non gli attacchi allinterno del browser.



                                     

4.4. Come difendersi Disabilitare gli script

Mentre le applicazioni web 2.0 e Ajax favoriscono luso di JavaScript, alcune applicazioni web sono scritte per consentire il funzionamento senza la necessità di qualsiasi script lato client. Questo permette agli utenti, se lo desiderano, di disattivare qualsiasi script nei loro browser prima di utilizzare lapplicazione. In questo modo, gli script lato client, anche potenzialmente dannosi, potrebbero essere inseriti senza caratteri di escape in una pagina e gli utenti non sarebbero suscettibili di attacchi XSS.

Alcuni browser o plugin per browser possono essere configurati per disattivare gli script lato client in base al dominio. Questo approccio ha valore limitato se gli script sono abilitati di default, dato che verranno bloccati quando lutente li avrà riconosciuti come pericolosi, ma ormai sarà troppo tardi. Una funzionalità che blocca tutti gli script e inclusioni esterne di default, e che quindi permette agli utenti di abilitare in base al dominio, è più efficiente. Questo è stato possibile per un lungo periodo su Internet Explorer dalla versione 4 impostando le cosiddette" zone di sicurezza” e in Opera dalla versione 9 usando le" preferenze specifiche del sito”. La soluzione per Firefox e altri Gecko-based browser è ladd-on open source NoScript che oltre ad abilitare gli script per dominio, fornisce una certa protezione XSS anche quando gli script sono abilitati.

Il problema più rilevante dato dal blocco di tutti gli script in tutti i siti web di default è la sostanziale riduzione delle funzionalità e della reattività.Un altro problema con il blocco dello script è che molti utenti non lo capiscono e non sanno come proteggere adeguatamente il loro browser. Un altro svantaggio che molti siti non funzionano senza scripting lato client, costringendo gli utenti a disattivare la protezione per il sito. Lestensione per Firefox NoScript consente agli utenti di abilitare gli script da una determinata pagina ma non consente lesecuzione ad altri della stessa pagina. Ad esempio, gli script da example.com possono eseguire, gli script da advertisingagency.com che sta tentando di eseguire sulla stessa pagina possono essere disabilitati.

                                     

4.5. Come difendersi Tecnologie di difesa emergenti

Ci sono tre classi di difesa da XSS che stanno emergendo. Queste includono Content Security Policy, JavaScript sandbox tools, e auto-escaping templates. Questi meccanismi sono ancora in evoluzione, ma promettono un futuro dove gli attacchi XSS saranno fortemente ridotti.

                                     

5. Servizi di scanning

Alcune aziende offrono un servizio di scansione periodica, sostanzialmente simulando un attacco dal proprio server al server del cliente per verificare se lattacco ha successo. Se ciò avviene, il cliente riceve informazioni dettagliate su come è stato eseguito lattacco e quindi ha la possibilità di risolvere il problema prima che lo stesso attacco sia fatto da qualcun altro. Lo scanner non può trovare tutte le possibili vulnerabilità, pertanto, i siti scansionati possono essere ancora vulnerabili a nuovi tipi di attacchi, ma le scansioni può rilevare alcuni problemi noti. Dopo che il cliente ha risolto i bug di sicurezza, il sito sarà sicuramente più sicuro di prima. Per i siti che richiedono una soluzione completa delle vulnerabilità XSS sono necessarie tecniche di valutazione come una revisione manuale del codice.

                                     

6. Vulnerabilità correlate

In un attacco Universal Cross-Site Scripting UXSS, o Universal XSS vengono sfruttate le vulnerabilità del browser stesso, piuttosto che le vulnerabilità nei siti web, come per gli attacchi XSS. Tali attacchi sono comunemente usati da Anonymous, insieme a DDoS, compromettendo il controllo della rete.

Diverse classi di vulnerabilità o tecniche di attacco sono legate a XSS: i cross-zone scripting permettono lesecuzione di codice con maggiori privilegi in alcuni browser. HTTP header injection può essere usato per creare le condizioni necessarie per il cross-site scripting sfuggendo a problemi di HTTP protocol level oltre a consentire attacchi come il HTTP response splitting.

Cross-site request forgery CSRF/XSRF è quasi lopposto del XSS, nel senso che invece di sfruttare la fiducia degli utenti in un sito, lattaccante e la sua pagina malevola, sfrutta la fiducia del sito nel software del client, facendo richieste che il sito ritiene azioni consapevoli e intenzionali di un utente autenticato. Vulnerabilità XSS anche in altre applicazioni in esecuzione nello stesso dominio consentono agli aggressori di bypassare gli sforzi di prevenzione CSRF.

Covert Redirect sfrutta client di terze parti suscettibili ad attacchi XSS o Open Redirect. Covert Redirect è stato scoperto dal dottorato di ricerca dello studente Wang Jing del Nanyang Technological University, in Singapore." Tentativi di normale phishing possono essere facilmente individuati, perché lURL della pagina malevola è di solito diversa al massimo un paio di lettere rispetto a quella del sito vero e proprio. La differenza con Covert Redirect è che un utente malintenzionato potrebbe utilizzare il sito web vero e proprio anziché violare il sito web con un pop-up di login dannoso.”

Infine, SQL injection sfrutta una vulnerabilità nel livello di database dellapplicazione. Quando linput dellutente non viene filtrato in modo corretto, possono essere eseguite dallapplicazione tutte le istruzioni SQL.