Il Cross-Site Scripting, in gergo XSS, è una vecchia conoscenza nel mondo dell’hacking e della cyber security. Date certe della sua comparsa non ce ne sono, ma è assodato che verso la fine del 1999 il Security Response Center di Microsoft iniziò a raccogliere parecchie segnalazioni di una forma di attacco che prevedeva l’iniezione di codice malevolo all’interno di pagine web. Si trattava, però, solo una piccola parte di un processo più ampio, nel quale a una potenziale vittima veniva inviato un link al fine di accedere ai suoi cookie di navigazione.
Torneremo in seguito sui dettagli di un XSS, concentrandoci adesso sul motivo per cui è il caso di tornare a parlare di questa tecnica: da quel 1999 non solo non è mai stata neutralizzata ma, anzi, negli ultimi tempi ha conosciuto un ritorno sotto i più blasonati riflettori. Non tanto come attacco fine a sé stesso, ma come payload per veicolare vulnerabilità e concorrere, dunque, ad attacchi più strutturati.
Indice degli argomenti
La moda del Cross-Site Scripting non passa mai
Edgescan, per esempio, rileva che il Cross-Site Scripting sia ben in cima a un’ipotetica classifica delle principali minacce di livello “High Risk”, con un 37,20% di casi contro il 12,40% di chi si trova al secondo posto: brute force e autenticazione debole. In questo caso si parla di versioni avanzate di XSS, cioè la reflected e la DOM, ma anche la più classica “stored” gode di un insospettabile successo e lo fa addirittura nella categoria delle minacce di livello “Critical Risk”: se ne sta in seconda posizione, con un 18,2%, dietro al sempiterno SQL Injection e davanti a mostri sacri quali il malicious file upload (9,8%) ed executable code injection (6,3%).
I perché della longevità del Cross-Site Scripting
Due i motivi che potrebbero spiegare la longevità del Cross-Site Scripting. Da una parte, appunto, una reingegnerizzazione che lo ha trasformato in un alleato perfetto in un’architettura d’attacco più ampia e complessa. Dall’altra, una sua vocazione alla versatilità: un XSS ha un elevato livello di efficacia e si applica a piattaforme web molto eterogenee tra loro. Senza contare che è uno dei pochi attacchi che colpiscono senza alcuna differenza sostanziale sia la web application stessa che i suoi utenti.
Il fattore-chiave è la sua architettura: si tratta di una tecnica di code-injection lato client, quindi a livello di browser e non di server. Da una parte si ha il vantaggio di una più semplice applicabilità, dall’altro un’efficacia sufficiente a sottrarre credenziali di accesso e autenticazione, dati di una sessione, cookie, key-log.
L’utilizzo del crypto-jacking
Senza contare, e anche questo è uno dei motivi del ritorno alla ribalta del cross-site scripting, dell’utilizzo nel crypto-jacking, nel quale la macchina della vittima è utilizzata per il mining di valuta elettronica per conto del criminale informatico.
Un fenomeno capace di rallentare di 5-10 volte l’esecuzione di applicazioni, con relative perdite in termini economici ed energetici, e che nel 2021 ha segnato un 25% di aziende colpite.
Le due versioni di cross-site scripting
La versatilità di un XSS si deve principalmente al fatto di essere disponibile in più versioni, le cui principali sono il reflective XSS e lo stored XSS. Il primo si verifica quando un utente clicca su un link per accedere a un’altra pagina o sezione di una web application, avviando tuttavia l’esecuzione di codice JavaScript malevolo, che di solito è parte del link stesso.
Si definisce reflected proprio perché l’attacco, a questo punto, si riflette sull’utente medesimo.
Lo XSS Stored, invece, si basa su modifiche semi-permanenti nel codice stesso della web application, così che utilizzarne certe sezioni o servizi porti a interagire con contenuti malevoli creati ad hoc. Lo stored XSS, non a caso, è utilizzato proprio nel cryptojacking.
Codice JavaScript pronto all’uso
Vi sono JavaScript pronti all’uso, infatti, che se integrati in pagine web trasformano i rispettivi visitatori in inconsapevoli miner, pronti a regalare, a loro insaputa, potenza di calcolo per attività di mining su determinati account.
Sebbene il pioniere del settore, Coinhive, sia stato chiuso qualche anno fa, il testimone è stato raccolto da numerosi altri servizi. Tra questi, per esempio, CoinImp, che genera JavaScript pronti per essere integrati in pagine web e trasformare il traffico in potenza di calcolo per il mining. Una volta autenticati, si accede a una dashboard che consente di scaricare poche righe di codice che puntano a un apposito JS. Di per sé non si tratta di codice malevolo, ma può essere veicolato tramite XSS per sfruttare traffico di altri siti web in modo illegale.
Non a caso, alcuni dei più noti tool di sicurezza lo hanno inserito in black list.
Rimedi sempre efficaci
L’apparente semplicità con è possibile eseguire un cross-site scripting viene spesso percepita con una sua scarsa efficacia, ma non ci si deve trarre in inganno.
L’utilizzo del XSS come payload sposta, semplicemente, la complessità di un attacco sul codice. E visto che nella maggior parte dei casi si tratta di codice JavaScript, il più diffuso linguaggio front-end, è lecito aspettarsi che il consenso ottenuto dal cross-site scripting non sia destinato a diminuire nel breve termine.
Proprio per questo, vanno sempre tenute a mente le buone regole che consentono di mitigarne l’efficacia.
Verificare ed eventualmente sanificare gli input, impostare regole di sicurezza nella gestione dei cookie, bloccare o limitare previo controllo l’inserimento di codice HTML.
Infine, per web-app di grande utilizzo e votate alla forte interazione con gli utenti, pensare all’adozione di un Web Application Firewall. Si tratta di una tecnologia che si occupa, in completa autonomia, di verificare, filtrare e bloccare traffico anomalo da e verso web-app.
