Cross-site scripting: differenze tra le versioni

Versione delle 11:10, 12 apr 2019

Versione delle 21:15, 30 apr 2019

Riga 13:

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 = httphttps://jeremiahgrossman.blogspot.com/2006/07/origins-of-cross-site-scripting-xss.html |data = 30 luglio 2006|accesso = 15 settembre 2008}}</ref>

Vulnerabilità XSS sono state segnalate e sfruttate dal 1990. Siti noti sono stati compromessi nel passato, inclusi siti di social-network come [[Twitter]]<ref>{{Cita web |url = httphttps://www.theguardian.com/technology/blog/2010/sep/21/twitter-bug-malicious-exploit-xss |titolo = Twitter users including Sarah Brown hit by malicious hacker attack |cognome = Arthur |nome = Charles |sito = the Guardian |data = 21 settembre 2010 |accesso = 21 maggio 2016}}</ref>, [[Facebook]]<ref>{{Cita web |url = httphttps://www.theregister.co.uk/2008/05/23/facebook_xss_flaw/ |titolo = Facebook poked by XSS flaw |cognome = Hacking |accesso = 21 maggio 2016}}</ref>, [[Myspace|MySpace]], [[YouTube]] e [[Orkut]]<ref>{{Cita web |url = httphttps://www.zdnet.com/blog/security/obama-site-hacked-redirected-to-hillary-clinton/1042 |titolo = Obama site hacked; Redirected to Hillary Clinton {{!}} ZDNet |cognome = Dignan |nome = Larry |sito = ZDNet |accesso = 21 maggio 2016}}</ref>. Negli anni successivi, i problemi di cross-site scripting hanno superato quelli di buffer overflows diventando la vulnerabilità di sicurezza più comunemente segnalata<ref>{{Cita web |url = https://cwe.mitre.org/documents/vuln-trends/index.html|titolo=CWE -

Vulnerability Type Distributions in CVE |sito = cwe.mitre.org |accesso = 21 maggio 2016}}</ref>, tant'è che alcuni ricercatori nel 2007 hanno supposto che il 68% dei siti probabilmente sarebbero esposti ad attacchi XSS<ref>{{Cita web |url = http://www.csoonline.com/article/221113 |titolo = Software Vulnerability Disclosure: The Chilling Effect - CSO Online - Security and Risk |data = 18 aprile 2008 |accesso =21 maggio 2016 |urlmorto = sì |urlarchivio = https://web.archive.org/web/20080418072230/http://www.csoonline.com/article/221113 |dataarchivio = 18 aprile 2008}}</ref>.

Riga 46:

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=httphttps://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=httphttps://docs.angularjs.org/api/ng.$sce|titolo=AngularJS|sito=docs.angularjs.org|accesso=21 maggio 2016}}</ref>.

== Un esempio di attacco ==

Riga 95:

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=httphttps://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=httphttps://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|urlmorto=sì|urlarchivio=https://web.archive.org/web/20080323040609/http://www.modsecurity.org/projects/modsecurity/apache/feature_universal_pdf_xss.html|dataarchivio=23 marzo 2008}}</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 name="modsecurity.org"/>.

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

=== Disabilitare gli script ===

Mentre le applicazioni [[web 2.0]] e [[AJAX|Ajax]] favoriscono l'uso di JavaScript<ref>{{Cita web|url=httphttps://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=httphttps://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=httphttps://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=httphttps://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. Queste includono Content Security Policy<ref>{{Cita web|url=httphttps://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:

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. Tali attacchi sono comunemente usati da [[Anonymous]], insieme a [[Denial of Service|DDoS]], compromettendo il controllo della rete.

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|sito=www.h-online.com|accesso=21 maggio 2016}}</ref>. HTTP header injection può essere usato per creare le condizioni necessarie per il cross-site scripting sfuggendo a problemi di HTTP protocol level (oltre a consentire attacchi come il HTTP response splitting)<ref>{{Cita web|url=httphttps://www.adobe.com/support/security/bulletins/apsb06-18.html|titolo=Adobe - Security Advisories : Update available for HTTP header injection vulnerabilities in Adobe Flash Player|sito=www.adobe.com|accesso=21 maggio 2016}}</ref>.

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