Attacchi Cross-site Scripting

Salve a tutti! Ecco il secondo post, dopo una “leggera” sessione esami. Oggi tratteremo un argomento particolarmente interessante, nel campo della sicurezza informatica, ossia, come da titolo, il “Cross-site Scripting” o meglio conosciuto come html injection o xss.

Vedremo cos’è questo attacco, quali danni può provocare, come funziona e come difendere i nostri siti o applicazioni web da questa vulnerabilità.

hackedbig

Il web è popolato da milioni e milioni di siti, se vogliamo fare i precisini, il numero esatto si avvicina al miliardo.

Possiamo dire che sono stati fatti enormi passi avanti in questo campo, dal primo sito pubblicato dal creatore del “www” ossia Tim Berners-Lee, fino ad arrivare ai 17 milioni nel 2000, ad oggi toccando quasi il miliardo.

Come possiamo vedere la rete è popolatissima, ma il numero è ancora più alto se pensiamo a tutte le persone, o cose, che sono connesse ad internet in un singolo momento, non vi riporto statistiche, ma non è difficile immaginarsi quanto il numero sia elevato.

Tra tutti questi utenti connessi, ovviamente, non ci sono solo “brave” persone, ossia che si limitano alla visualizzazione della pagina, ma anche altre persone che si divertono a sfruttare le vulnerabilità di un sito internet, per sottrarre informazioni riservate, modificare il sito o semplicemente oscurarlo.

Uno sviluppatore deve tenere in considerazione anche queste vecchie volpi, e far in modo di proteggere le sue creazione da questi mal intenzionati.

Ci sono molti modi per mettere KO un applicativo web, dallo sfruttare una falla nel programma server (ad esempio Apache), all’utilizzare un errore di programmazione nel sito vero e proprio.

Nel primo caso basta configurare e tenere sempre aggiornato l’ambiente server, leggete questo nostro post per approfondire l’argomento.

Nel secondo caso, bisogna strutturare il proprio sito web in modo tale che esso non sia vulnerabile, ad esempio al “Cross-site Scripting.

 

Cos’è xss e come funziona

Ma vediamo ora cos’è questa specifica vulnerabilità.

Tipicamente, i siti che possono presentare questa vulnerabilità, sono detti “dinamici”, ossia che in base a certe condizioni, la pagina web mostra determinate scritte o immagini, ad esempio, un sito che ci saluta mostrandoci il nostro nome dopo il login, esso è un sito dinamico, poiché in base all’utente che effettua il login, mostra il suo username.

Non è difficile capire come funziona un sito di questo genere, generalmente, ci sarà un input che chiede il nostro username e una password. Una volta immessi cliccheremo su un tasto “login”, che ci indirizzerà nella home del sito, e essa ci mostrerà il nostro username.

 

loginOK1

loginOK2

 

Come possiamo vedere dalle due immagini sopra, è stato inserito un semplice nome, quello che normalmente ci si aspetta dall’utente. Ma cosa succede se proviamo ad inserire codice html?

 

loginxss1

loginxss2

Dalle due immagini sopra possiamo notare che il nostro sito dinamico ha avuto un comportamento anomalo, ossia ha fatto una cosa che noi non ci aspettavamo, ha stampato il nostro login come se fosse codice html.

Come mai è successo questo? Come ben sappiamo, un server web, come Apache, invia al client del codice html, che verrà poi processato e visualizzato dal browser del client.

Quindi se il server invia semplicemente “daniele”, il browser lo mostrerà correttamente, mentre se inviamo <h1>daniele</h1>, il browser, giustamente, vede che è codice html e quindi lo mostrerà come tale.

Ma cosa succede se al posto di mettere un semplice <h1> mettiamo una cosa del genere: <script>alert('Ciao daniele');</script> ?

 

alert

Questo significa che un sito con questa vulnerabilità può mandare al client anche degli script da eseguire!

Pensate se nell’esempio appena visto venga usato il metodo “GET”, e quindi il nome venga mostrato nella URL oltre che nella pagina:

http://localhost/tuxManiacs/xss/home.php?nome=daniele

Non è difficile modificare la URL per sfruttare la vulnerabilità, e magari inviarla all’ignara vittima.

 

Quanto dannosi?

Nell’ultimo esempio, abbiamo visto che è possibile agire anche sull’URL, questo vuol dire che un’utente malevolo può inviare una URL modificata, in modo da eseguire uno script, e una volta che la vittima ci clicca sopra, gli si potrà sottrarre dati e quant’altro.

 

Come può difendersi un utente?

Delle volte, il browser si accorge da solo che sta per essere sfruttata una vulnerabilità xss, infatti per fare l’esempio dell’alert, ho dovuto aggiungere questa riga di codice nel file php: header("X-XSS-Protection: 0") per far in modo di poter disabilitare la protezione dagli xss per gli script. Ma come appena detto, ciò non sempre basta, infatti quando ho inserito <h1>daniele</h1>, il browser non si è accorto di nulla anche senza quella stringa nel php.

In sintesi è bene da parte dell’utente verificare la provenienza dei link, se è affidabile o meno, come si suol dire: “prevenire è meglio che curare”!

 

Come può difendersi uno sviluppatore?

Come abbiamo notato poco fa, il server invia come output codice html, questo vuol dire che il browser processerà tutto come se fosse codice html! Prevenire, in questo caso, non è complicato, basta filtrare gli input degli utenti, o eventualmente gestire bene il metodo “GET”, o in alternativa utilizzare “POST”.

 

Conclusioni

Oggi abbiamo visto un tipo di attacco molto utilizzato nella rete internet, abbiamo capito che esso può essere molto dannoso, sia per l’utente, che per il sito web. Per fortuna, da parte dello sviluppatore, non è difficile gestire questa vulnerabilità, mentre per un’utente basta un po’ di attenzione in più.

 

FONTI

- Immagini di Joel Garia;

Dottore in Informatica. Da sempre appassionato di Linux, reti informatiche, sicurezza e, in modo amatoriale, all'elettronica. Il mio intento è quello di trasmettere le mie conoscenze ad altri appassionati.

Lascia un commento