Un attacco XSS reale: furto della sessione

Nel file allegato a questo articolo ("XssDemo.aspx") viene mostrato un esempio concreto di attacco XSS: attraverso un sito vulnerabile un utente malintenzionato è in grado di appropriarsi dello stato della sessione di un altro utente. Schematicamente l'attacco viene portato in questo modo:

• l'hacker convince l'utente a visitare una pagina vulnerabile XSS, ad esempio inviando una mail che reciti "Complimenti! Sei stato selezionato per l'estrazione finale di un premio da 10.000 Euro. Collegati subito a <link> per confermare la tua partecipazione";
• lo script iniettato nella pagina (potrebbe semplicemente essere la QueryString del link fornito all'utente a contenere lo script) forza il cookie di sessione impostando un SessionID noto all'hacker e una scadenza oltre la normale durata di sessione;
• l'utente ignaro prosegue la sua navigazione nel sito Web inserendo dati personali che vengono salvati in variabili di sessione;
• l'hacker, collegandosi al sito, è in grado - sempre via XSS - di ottenere lo stesso SessionID della vittima e quindi di visualizzare i dati personali dell'utente!

Il risultato della simulazione di attacco è il seguente:

Nel caso specifico lo script sfrutta anche una debolezza intrinseca di ASP.NET per cui, sebbene i cookie di tipo HttpOnly non siano leggibili lato client, risultano comunque modificabili via JavaScript.

A questo proposito è utile verificare sempre la corretta impostazione del cookie "ASP.NET_SessionId", ad esempio con un codice simile al seguente:

Si noti che, applicando un codice JavaScript analogo a quello presentato nell'esempio allegato al cookie utilizzato per il salvataggio dell'autenticazione, un hacker ha la possibilità di impossessarsi anche delle credenziali della vittima (Page.User.Identity).

Difendersi dagli attacchi tramite script

La vulnerabilità a XSS può dipendere dai seguenti errori:

• i valori in ingresso (input dell'utente) non vengono verificati;
• l'output inviato al client non viene codificato correttamente (encoding);
• i dati provenienti da sorgenti condivise (ad esempio un database utilizzato anche da altre applicazioni) vengono considerati sicuri.

Le contromisure per difendersi da attacchi di scripting sono fondamentalmente due:

• verificare l'input;
• codificare l'output.

Per difendersi da attacchi di Cross-Site Scripting la prima regola da tenere presente è: considerare sempre inattendibile qualsiasi valore in ingresso e quindi verificare in ogni caso il tipo, la lunghezza, il formato e l'eventuale intervallo ammissibile (range). In secondo luogo è opportuno codificare sempre l'output HTML fornito al client, così da rendere inoffensivo un eventuale codice iniettato.

Linee guida

• Se possibile utilizzare i meccanismi di validazione di ASP.NET (ValidateRequest, EnableEventValidation).
• Utilizzare i controlli di validazione di ASP.NET (RegularExpressionValidator, RangeValidator o CustomValidator).
• Usare la classe Regex per verificare la consistenza dei dati ricevuti (ad esempio dalla querystring; per migliorare le performance si consiglia l'uso del metodo statico IsMatch).
• Per parametri di tipo definito (numeri, date, boolean, ecc.) utilizzare la conversione al tipo corrispondente del .NET Framework (cast).
• Se il testo viene visualizzato come proprietà di un controllo HTML, utilizzare "InnerText" anziché "InnerHTML".
• Codificare sempre i dati prima di visualizzarli (HttpUtility.HtmlEncode per i testi visualizzati, HttpUtility.UrlEncode per gli indirizzi costruiti via codice) - Attenzione: il solo uso della codifica non è sufficiente; è sempre necessario validare in modo esaustivo i valori in ingresso. Ad esempio questo script non può essere bloccato con HtmlEncode: <img src="javascript:alert('ciao mondo!');" />.
• Se l'applicazione accetta un determinato set di tag HTML non eliminare i tag non ritenuti validi (qualcuno può sempre scappare!) ma procedere nel seguente modo:
  
  
  • codificare l'intero testo ricevuto con HttpUtility.HtmlEncode;
  • riabilitare selettivamente i tag ammessi.
  
  Di seguito una funzione d'esempio per ammettere solo i tag "<b>" e "<i>":
  
  
  public static string StripHtmlTags(string text)
{
  StringBuilder sb = new StringBuilder(HttpUtility.HtmlEncode(text));
  sb.Replace("&lt;b&gt;", "<b>");
  sb.Replace("&lt;/b&gt;", "</b>");
  sb.Replace("&lt;i&gt;", "<i>");
  sb.Replace("&lt;/i&gt;", "</i>");
  return sb.ToString();
}

  
  
• Utilizzare la codifica dei caratteri corretta e verificare tutti i caratteri UNICODE.
• Utilizzare la libreria "Microsoft Anti-Cross Site Scripting" (download) per proteggersi da attacchi XSS; per un esempio di utilizzo si veda "Microsoft Anti-Cross Site Scripting Library V1.5: Protecting the Contoso Bookmark Page".
• Utilizzare strumenti di verifica delle proprie applicazioni come "XSS Detect Code Analysis Tool" (download); per maggiori informazioni è possibile fare riferimento al blog di ACE Team.

Conclusioni

In questa prima parte abbiamo preso in esame il Cross-Site Scripting, un tipo di attacco basato sull'esecuzione di script che possono rendere molto spiacevole la navigazione dell'utente. Nella seconda parte, in linea su ASPItalia.com il prossimo 29 gennaio 2008, prenderemo in esame gli aspetti di sicurezza legati allo strato di accesso ai dati.

Attenzione: Questo articolo contiene un allegato

Contenuti dell'articolo

• Pagina 1
  • Protezione da Cross-Site Scripting (XSS)
• Pagina 2
  • Un attacco XSS reale: furto della sessione
  • Difendersi dagli attacchi tramite script
  • Conclusioni