Attenzione ai file con più estensioni in Apache!
giugno 22, 2009 Scripting e dintorni, Security
Visto che parliamo anche di sicurezza informatica oggi mi tolgo questo sassolino dalla scarpa.
Spesso troviamo in vari script per l’upload dei file in PHP un controllo del tipo:
$ext = substr ($nome_file, (strlen($nome_file)-4), 4);
Questo script semplicemente ricava l’estensione analizzando gli ultimi 4 caratteri del nome del file. Successivamente ci sarà una porzione di codice che si occuperà di verificare che l’estensione trovata sia tra quelle consentite ( ovvero presenti in una qualche whitelist ).
Ma attenzione se la nostra applicazione dovrà girare su un server Apache!
Se infatti non facciamo nessun altro controllo sul resto del nome del file potremmo lasciar passare un nome tipo
bad.php.gif
Se ora vi andate a leggere la documentazione di Apache vedrete che di DEFAULT i file possono avere più di una estensione! Per cui se avete abilitato l’esecuzione di script .php con la classica istruzione direttiva:
AddType application/x-httpd-php .php .phtml .php3
o simili allora sarete in guai seri in quanto un file terminante in “.php.gif” sarà comunque eseguito come codice PHP risultando in un grave problema di sicurezza.
Ci sono due metodi adatti a scongiurare il pericolo:
- Il primo consiste nel controllare come visto l’estensione del file ma successivamente utilizzare un nome totalmente randomico costruendo così un nome finale del tipo “7ddf32e17a6ac5ce04a8ecbf782ca509.gif”. In questo modo non ci sarà la possibilità di doppie estensioni.
- In alternativa si può creare nella cartella di destinazione dei file uploadati un file .htaccess con il seguente contenuto:
SetHandler NO_EXECUTION_HANDLER
Il nome dell’handler è puramente casuale e potete anche sbizzarrirvi se volete. Ovviamente dovete assicurarvi che sia attivata l’opzione “AllowOverride All” nella vostra configurazione del server.
E per oggi è tutto. Mi raccomando, scrivete codice sicuro!
AGGIORNAMENTO
Dato che ora l’informazione è di pubblico dominio, dopo che secunia.com l’ha pubblicata, posso dirvi che questa stessa vulnerabilità l’ho trovata in MKPortal 1.2.2, l’ultima versione ad oggi, dopo che gli sviluppatori avevano tentato di correggerla a seguito di una precedente advisory pubblicata per la versione 1.2.1, segno che la vulnerabilità non era stata compresa completamente.
