Che cos’è l’XSS, il Cross-Site Scripting

Avevamo già accennato al Corss-Site Scripting (XSS) osservando degli esercizi pratici per principianti proposti dal sito hackthissite.org in questo post (in particolare ci interesserà leggere l’esercizio del livello 5), ma non ci eravamo mai particolarmente soffermati sulla sua importanza. Per comprendere, infatti, come proteggere il nostro sito internet da un possibile XSS, dobbiamo prima di tutto comprendere come questo funziona. Inoltre, se qualcuno volesse fare un po’ di effettiva pratica diretta Troy Hunt – consulente di sicurezza già nominato e conosciuto per aver creato Have I been pwned? di cui avevamo parlato in passato qui – ha costruito e messo a disposizione un sito, https://hack-yourself-first.com/, vulnerabile e pieno di falle che ci permette legalmente di metterci alla prova, soprattutto se alle prime armi.

Se siamo dei principianti potremo comprendere il funzionamento teorico dell’XSS, ma ricordiamoci che per quanto riguarda la pratica avremo bisogno di avere in nostro possesso delle basi di HTML o, per lo meno, essere in grado di leggere e comprendere, nonché muoverci, all’interno di un linguaggio di programmazione, altrimenti non saremo in grado di testare propriamente il nostro sito e comprenderne le potenziali debolezze.

Il Cross-Site Scripting può avvenire in diversi modi (HTML, Flash, codice eseguibile ovvero .exe), ma generalmente è portato a termine dall’invio di dati che entrano all’interno di un’applicazione web attraverso una fonte insicura (nella maggioranza dei casi via richiesta web); in altre parole, l’XSS si attua con l’invio di payloads (ovvero dei carichi) di dati la cui integrità non è verificabile ed il quale intento, ovviamente, è attaccare il nostro sito. Come, teoricamente, dovremo sapere l’integrità fa parte della triade su cui si basano i fondamenti della cybersicurezza, ovvero la CIA che è l’acronimo per confidentiality – integrity – accountability (riservatezza – integrità – responsabilità).

L’integrità è quella condizione per cui l’informazione, intesa come contenuto e dato, viene mantenuta, appunto, integra ed immodificata durante la sua archiviazione, la sua trasmissione ed il suo utilizzo. Un attacco di Cross-Site Scripting, pertanto, andrà a modificare l’integrità dei dati. Dobbiamo, quindi, aspettarci che i dati non siano affidabili; per esempio, un utente potrebbe facilmente manipolare i parametri di un URL, o gli oramai conosciuti cookie, oppure inviando un commento con dei dati non sicuri; che l’intento di questi dati sia malevolo e che gli stessi possano includere dei payloads, ovvero pacchetti contenenti codici binari con malware, XSS, file eseguibili per portare a termine un SQL injection, etc.; ma ricordiamoci che l’attacco potrebbe anche provenire dal nostro stesso archivio, se compromesso, o da servizi esterni a cui ci affidiamo. Per cui qualsiasi dato che viene a contatto con il nostro sito deve essere trattato come potenzialmente pericoloso.

Lo scopo di questo tipo di attacchi è riuscire ad utilizzare dei bugs dei siti web e leggere o rubare cookies, interferire con le informazioni appartenenti ad una sessione di un sito, ridirigere il traffico verso uno specifico sito prescelto e via dicendo.

Per proteggere il nostro sito possiamo, per esempio, utilizzare quello che viene definito processo di sanitizzazione e creare delle blacklist (liste nere, ovvero se vogliamo semplificarne la definizione “questa cosa non va bene, ma allora il resto che non si trova elencato è sicuro”) e whitelist (liste bianche, ovvero “sappiamo che queste cose vanno bene e saranno le uniche ad essere accettate”), le prime bloccheranno quello che è elencato al loro interno (cosa che potrebbe renderle incomplete per dimenticanze o altre motivazioni), mentre le seconde avranno un elenco di ciò che è sicuro e può essere accettato (quest’ultimo approccio viene considerato meno rischioso e più flessibile). Questo è per esempio il motivo per cui alcuni sistemi non permettono l’utilizzo di simboli come < > ‘ “/ \

Per effettuare una manipolazione dei dati in questo modo, generalmente, si utilizzano degli strumenti come Wireshark, di cui avevamo già parlato in passato, Burp Suite e Fiddler, BeEF (per Linux) scaricabili tutti gratuitamente.

Esistono due grosse tipologie di attacchi XSS da cui poi ne derivano gli altri; il primo è il reflected XSS, un tipo di attacco abbastanza frequente, facile da mettere in pratica e che spesso può richiedere anche un pizzico di social engineering (ingegneria sociale), in cui un codice iniettato (o injected) viene fatto ribalzare o riflesso da un web server sottoforma di messaggio d’errore o attraverso un diverso web server; un utente potrebbe essere ingannato e portato a cliccare su un link della pagina web o di un messaggio (per esempio un commento) eseguendo, così, il codice. In pratica, chi attacca inietta un codice eseguibile nel browser che andrà ad affligere solamente gli utenti che sceglieranno di interagire con il link inserito.

Il secondo macro-tipo di XSS è lo stored XSS che tende ad essere più pericoloso del primo menzionato soprattutto se messo in pratica in aree di un’applicazione web dove vi sono utenti con alti privilegi d’accesso mettendo a rischio informazioni sensibili e sessioni che richiedono l’autorizzazione via tokens. Questo attacco, infatti, può essere messo in pratica su qualsiasi applicazione web che permette all’utente che sta visitando il sito di archiviare dati. Normalmente un’applicazione web colleziona gli input dell’utente ed archivia i dati per utilizzarli in un secondo momento, un utente malintenzionato può approfittare di questo processo ed inviare input dannosi, in altre parole payload o pacchetti di dati inaffidabili, che potranno essere inavvertitamente eseguiti da un successivo visitatore ignaro dell’accaduto.

Uno degli attacchi XSS più conosciuti è il virus Samy, anche denominato JS. Spacehero; creato dall’allora diciannovenne Samy Kamkar e rilasciato su MySpace il 4 ottobre 2005 (ingenuamente generato e senza cattivi intenti, gli valse l’allontanamento dai computer per tre interi anni e il doversi ammettere colpevole del reato). Inizialmente, questo virus era stato caricato solamente per far comparire nel profilo degli utenti che si collegavano al suo la scritta “but most of all, samy is my hero” (ma al di sopra di tutti, samy è il mio eroe), ma senza successo poiché troppe poche persone si connettevano a lui. Così, in un secondo momento, Kamkar decise di modificare ulteriormente l’attacco ed in meno di venti ore dilagò fuori controllo legandosi ai profili degli utenti su MySpace i quali non solo si ritrovavano con l’enunciato citato poc’anzi sulla loro pagina, ma infettavano automaticamente tutti coloro che ne visitavano i loro profili.

Fondamentalmente, questo virus era un payload in Javascript che, originariamente, Kamkar aveva caricato sul proprio profilo. Però, Samy perse la situazione di mano e fortunatamente, come già detto, il suo intento non era ledere alcuno, ma aumentare la sua rete di amici sul social; al tempo stesso, questo attacco non solo obbligò MySpace a mandare offline l’intera piattaforma e cercare il più velocemente una soluzione, ma fece emergere l’importanza della sicurezza in rete e la presenza e necessità di correggere la falla trovata da Samy anche in altre realtà sul web.