Minacce in Rete: come difendersi dal Cross Site Scripting

Vi sarà  capitato spesso di leggere che la vostra sicurezza sul Web è compromessa da vari tipi di minaccia, spesso identificati con delle sigle.
Ad esempio il CSS significa Cross Site Scripting ed è una tipologia di attacco che può essere portato a compimento se solo uno dei tre attori principali della società  informatica è incauto: utente, sviluppatore o amministratore di sistema.

Si tratta di un attacco informatico prodotto da un hacker, che consiste nell’iniettare uno script in una applicazione web vulnerabile, la quale inconsapevolmente farà  eseguire lo script nel browser dei suoi utenti (i dati vulnerabili all’interno di un sito sono quelli prelevabili con richieste Get/Post/XmlHttp, cookies persistenti o Xml usati ad esempio da Ajax).
Questo tipo di attacchi si può suddividere in persistente e volatile.

Persistente: gli attacchi persistenti consistono nell’iniettare lo script nel web server in modo che venga salvato e riproposto agli utenti che lo visitano. Nel contesto di forum e blog questo potrebbe non essere difficile, visto che di norma gli ultimi messaggi/post vengono mostrati per primi agli utenti e vengono eseguiti dai browser. In questo modo l’hacker può arrivare a carpire credenziali e dati sensibili all’utente.

Volatile: ovviamente gli hacker sono interessanti soprattutto ad altri tipi di siti, ma in questo caso l’attacco può essere perpetrato solo durante una sessione attiva. Sarà  l’utente stesso ad iniettare lo script malevolo nel sito vulnerabile, il quale restituirà  all’utente lo script immediatamente eseguito nel suo browser con la stessa capacità  dirompente già  vista in precedenza.

Un attacco-tipo potrebbe essere una mail ricevuta che invita a cliccare su un sito che l’hacker ha prescelto in quanto vulnerabile al cross site scripting e di cui il ricevente potrebbe essere cliente, ipotizziamo una banca.

Cliccando sul link nella mail, il browser del malcapitato esegue una GET o POST della pagina vulnerabile del sito trasmettendo lo script avvelenatore. Lo script, essendo stato scaricato dal dominio del sito della banca, ha accesso al cookie che incautamente custodisce le credenziali per accedere alle operazioni sul conto corrente, e che viene prontamente trasmesso all'hacker.
Infine, viene subito caricata un'altra pagina per non insospettire l'utente: l’utente non fa in tempo a vedere il caricamento della pagina della banca in quanto esso avviene in tempi rapidissimi. Il furto delle credenziali è avvenuto e l'utente con tutta probabilità  non si è accorto di nulla.

Strumenti per proteggere l’applicazione web

La validazione è un controllo di congruità  che è tanto più efficace quanto è meno generico. Se ad esempio ci aspettiamo un indirizzo email, la validazione con un’espressione regolare (regular expression) è sicuramente il sistema più efficiente.

Se invece è il messaggio di un post in un forum il controllo sarà  evidentemente più complesso perché il corpo del messaggio potrebbe contenere emoticon o una formattazione html che potrebbero nascondere delle pericolose insidie.

Il primo passo è quello di identificare nell’applicazione tutti i punti di ingresso dei dati che provengono dall'utente, siano essi diform, QueryString, database condiviso con un’altra applicazione o pagina che usa Ajax.

Il tipo di validazione dipenderà  dalla destinazione dei dati: una pagina web oppure ad un database.

Se il rimedio migliore è ovviamente quello di applicare le tecniche di validazione dell'input e di codifica dell'output, esiste un modo per mitigare il problema del furto dei cookie ed è un attributo specifico di Internet Explorer chiamato HttpOnly che è disponibile a partire dalla IE6 Service Pack 1 – quindi accertatevi di aver aggiornato il vostro browser IE almeno a questa versione.

HttpOnly è utilizzabile anche con Asp Classic. Grazie a questo attributo le tipologie di attacchi di cross site scripting che si basano sul furto delle informazioni presenti dentro un cookie, sono scongiurate. In pratica uno script che, eseguito ad esempio in Internet Explorer 7, dovesse tentare di leggere document.cookie, otterrebbe una stringa vuota.

HttpCookie CookieNome = new HttpCookie(“Nome”, “Raffaele”);
CookieNome.HttpOnly = true;
Response.Cookies.Add(CookieNome);

Questo non significa però che HttpOnly sconfigga la totalità  degli attacchi cross site scripting.

Fin dalla versione 1.1 Asp.net offre un controllo sull'input utente grazie a validateRequest che scongiura gli attacchi più comuni come il post di tag Html, la presenza di script nei cookie, nei form o nelle QueryString.

Un altro valido strumento di difesa che deve essere sempre usato congiuntamente, e non in modo alternativo, è la codifica di ciò che presentiamo sulla pagina. Parliamo dei metodi statici HttpUtility.HtmlEncode e HttpUtility.UrlEncode.

Interessante è anche la libreria creata dal team Microsoft, per i problemi legati alla sicurezza, chiamata “Anti-Cross Site Scripting Library” arrivata alla versione 3.0 Beta.

Lo scopo di questa libreria è dare allo sviluppatore dei collaudati e robusti metodi di codifica di tutto ciò che proviene da una sorgente non completamente fidata, tipicamente i dati letti da un form utente o di un database condiviso con altre applicazioni.

L’articolo, più in dettaglio lo trovate qui: MSDN Microsoft