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 |
Recupero di 1 fonte/i e segnalazione di 0 link interrotto/i.) #IABot (v2.0.1 |
||
Riga 117:
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=https://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|urlarchivio=https://web.archive.org/web/20120814151512/http://www.webappsecblog.com/CsrfAndSameOriginXss.html|dataarchivio=14 agosto 2012|urlmorto=sì}}</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>
| |||