Un tipo di attacco frequente sui siti web dinamici si basa sull'esecuzione di script malevoli sul sito, dopo aver sfruttato la possibilità di caricare i file attraverso funzioni del CMS, o di generare dei file cache opportunamente modificati.
Anche se il sito non prevede in nessun punto la possibilità di caricare file per l'utente non è da escludere totalmente questa possibilità, in quanto molti CMS hanno "a bordo" dei plugin che possono essere abilmente richiamati dall'attaccante.
E' prassi comune che i file caricati dall'utente o i file di cache, siano in genere posizionati in path predefiniti. La tecnica proposta per mitigare la vulnerabilità si basa sull'assunzione che in questi path non si prevede l'esecuzione di script (ma solamente l'accesso a file statici come immagini, html, pdf, etc.). Pertanto, inibendo l'esecuzione degli script si previene l'esecuzione di script malevoli senza compromettere la funzionalità del sito stesso.
In questo articolo esamineremo il linguaggio PHP eseguito come modulo di Apache, le informazioni possono comunque essere estese anche a altri linguaggi e web server.
Assumiamo che il CMS posizioni i file nel path (ed eventuali sottodirectory):
uploads
All'interno di uploads va creato un file .htaccess con la seguente direttiva:
php_flag engine off
Se il web server Apache è in grado di interpretare la direttiva, possiamo testare il risultato caricando un file di esempio test.php con qualche riga di codice, ad esempio:
<?php
echo "PHP viene interpretato?";
Se richiamando il file da Browser vediamo il sorgente PHP, significa che il codice non viene eseguito, diversamente, se viene visualizzato soltanto il messaggio tra doppi apici, PHP è stato eseguito.
Altre tecniche suggeriscono addirittura di negare l'accesso ai file di tipo *.php, tuttavia in genere far apparire il sorgente in definitiva ha lo stesso risultato.
Si suggerisce anche dal proteggere il file .htaccess stesso da possibili sovrascritture, infatti cosa succederebbe se l'attaccante riuscisse a sovrascrivere la direttiva indicata sopra?
Quindi il file .htaccess potrebbe avere a sua volta delle righe di "auto-protezione" tipo:
<Files .htaccess>
Order allow,deny
Deny from all
</Files>
E' importante capire che questo non è mettere in sicurezza un sito, in quanto il CMS dovrebbe essere in grado autonomamente da intercettare e inibire richieste potenzialmente pericolose, tuttavia è un sistema per mitigare i danni quando il sito utilizzare un CMS insicuro ad esempio perché non è aggiornabile per vari motivi.
Il suggerimento a lungo termine è quello di aggiornare il sito utilizzando un CMS sicuro.
Un articolo di A.De Zorzi