Il cross-site scripting (XSS) è una vulnerabilità informatica che affligge siti web dinamici che impiegano un insufficiente controllo dell'input 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.

Nell'accezione odierna, la tecnica ricomprende l'utilizzo 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 l'80% di tutte le violazioni era dovuto ad attacchi XSS.

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 l'autorizzazione 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 l'utente 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 dell'utente.

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

L'espressione cross-site scripting originariamente si riferiva unicamente ad attacchi basati sull'utilizzo di frammenti di codice JavaScript inseriti all'interno 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 dall'applicativo 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.

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).

Reflected (non-persistent)

Le vulnerabilità cross-site scripting di tipo reflected sono sicuramente le più comuni. È possibile sfruttarle quando i dati forniti dall'utente (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 dall'utente non validati sono inclusi nella pagina risultante senza un'adeguata 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. L'esca è un URL dall'aspetto 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 l'esecuzione di script iniettato nel browser della vittima.

Persistent

Una vulnerabilità XSS persistente (o stored) è una variante più devastante di cross-site scripting: si verifica quando i dati forniti dall'attaccante 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. L'unico momento in cui il nome reale e l'email 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”, l'attaccante dà una risposta breve (dall'aspetto consueto) ma il testo alla fine della risposta è lo script per rubare i nomi e le mail. Se lo script è racchiuso all'interno di un elemento ,

  1. Viene visualizzato un box di avviso che dice “xss”
  2. La pagina visualizza " non trovato" insieme a un messaggio di errore con il testo “xss”
  3. L'URL sfruttabile è http://bobssite.org?q=
  • Mallory crea un URL per sfruttare l'exploit
    1. Crea l'URL http://bobssite.org?q=cuccioli. Sceglie di convertire i caratteri ASCII in esadecimale, ad esempio http://bobssite.org?q=cuccioli in modo che eventuali lettori umani non possano immediatamente decifrare l'URL dannoso.
    2. Invia una mail ad alcuni ignari membri del sito di Bob, in cui scrive: “Controlla alcuni simpatici cuccioli”
  • 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 l'attacco XSS.
  • 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à.
  • 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:

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

    Attacco persistente

    1. Mallory crea un account sul sito di Bob.
    2. 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.
    3. Mallory legge l'articolo nella sezione News e scrive in un commento. Nel commento inserisce questo testo: Io amo i cuccioli di questa storia. Sono così carini!