Attacco directory traversal

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: 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 [...]

Leggi tutto l'articolo