Mettere in sicurezza Joomla

La versione originale del testo può essere prelevata direttamente dal sito dell?autore Netshine Software Limited: http://www.netshinesoftware.com/joomla-security.html

Gli sviluppatori di Joomla cercano costantemente di migliorare la sicurezza del sistema mediante tecniche di buona programmazione e metodi di sicurezza. E? anche importante mantenere aggiornato il sistema con le ultime patch che vengono rilasciate per risolvere bug e buchi nella sicurezza (clicca su http://forum.joomla.org/index.php?action=notifyboard;board=8.0 per sottoscrivere il forum ufficiale di Joomla).

Caselle di input Ci sono parecchie caselle di testo in un sito Joomla (ad esempio caselle di ricerca, filtri, …) ed i dati inseriti sono sempre validati per assicurare che non contengano virgolette, in modo da proteggersi contro attacchi di tipo SQL injection.

Editor HTML E’ anche possibile permettere all’utente di inserire articoli, e questo apre le porte a possibili attacchi di tipo cross-site-scripting injection, nel momento in cui viene permesso di inserire codice HTML. Molti editor HTML impediscono di inserire codice Javascript o specifici tag (come <object>, <applet>) per questa ragione.

Ma un problema si pone proprio qui perchè il medesimo editor HTML viene usato sia nel frontend che nel backend. Così se un amministratore volesse inserire codice Javascript o altro contenuto proibito, verrebbe bloccato. Alcuni editor (come mosCE) permettono di specificare quali tag sono permessi e di aggiungere codice Javascript, ma bisogna assicurarsi di impedire agli utenti di usare tale editor.
E’ possibile fare ciò semplicemente inibendo la possibilità di scrivere all’utente oppure usando 2 editor HTML differenti, il default più restrittivo ed un secondo da far usare solamente agli utenti registrati.

Login utente Il meccanismo di login di Joomla, per backend e frontend, utilizza il metodo di codifica one-way. Quando si digita la password, Joomla vi applica l’algoritmo MD5 per trasformare la password in una stringa alfanumerica inintelleggibile di 40 caratteri, sempre gli stessi ad ogni codifica. La password non viene mai decodificata ma viene confrontata con la versione codificata memorizzata nel database.

Per determinare se si è loggati in un certo istante, Joomla utilizza un cookie, un piccolo file di testo memorizzato nel computer. Questo cookie non contiene username e passowrd, ma solamente un ID di sessione che Joomla può utilizzare per verificare chi siamo e se siamo loggati. Così anche se qualcuno dovesse rubare il cookie dal computer non otterrebbe nulla di più se non un ID di sessione o un qualche altro numero.

Note di rilascio I file di testo acclusi ad un’installazione standard di Joomla includono le note di rilascio così come un changelog, ossia la lista dei cambiamenti effettuati nell’ultima versione. Tali informazioni potrebbero dare indizii importanti circa le possibili debolezze che gli hackers potrebbero sfruttare. Quindi tutti i file sono protetti contro la lettura accidentale, essendo rinominati come file PHP impedendone la visualizzazione nel browser. Nonostante ciò, sarebbe più sicuro rimuovere tali file dal server, per essere veramente sicuri che nessuno possa leggerli. Allo stato attuale, i file che possono essere rimossi sono: CHANGELOG.php, COPYRIGHT.php, INSTALL.php e LICENSE.php.

File .htaccess Esiste un file fornito con Joomla chiamato htaccess.txt. Se mantenuto con questo nome, non ha nessun effetto sul sito. Ma se viene rinominato in .htaccess (con il punto davanti), influenza ogni richiesta che viene inviata al sito (nota: questo ha effetto solamente su siti che girano sotto server Apache, non IIS; se non siete sicuri se il vostro sito sta funzionando su Apache o su IIS, probabilmente sta funzionando su Apache! Il 99.99% dei siti di Joomla funzionano su Apache. Apache è il nome del software del web server, non il sistema operativo).

Tipicamente, si rinomina il file solamente nel caso in cui si vogliono utilizzare i SEF URL (indirizzi friendly per i motori di ricerca); le istruzioni contenute al suo interno permettono di convertire le pagine in un formato interpretabile da Joomla. Ci sono molti altri usi per il file .htaccess, tra cui la protezione con password di una directory, il blocco degli utenti basato su IP, e molte altre. Questo file può essere molto potente! Ed è per questo che è importante assicurarsi che persone non autorizzate possano visualizzarlo, o peggio modificarlo.

Oltre a settare i permessi sui file (vedi oltre), è possibile aggiungere le seguenti direttive all’inizio del file .htaccess per impedire che possa essere letto:

Direttive .htaccess

<Files .htaccess>
order allow,deny
deny from all
</Files>

Inoltre per prevenire alcuni dei più utilizzati attacchi rivolti a Joomla! è possibile inserire all’interno del file le seguenti righe:

########## Begin - Rewrite rules to block out some common exploits
#
# Block out any script trying to set a mosConfig value through the URL
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|%3D) [OR]
# Block out any script trying to base64_encode crap to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*(.*) [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (<|%3C).*script.*(>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|[|%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|[|%[0-9A-Z]{0,2})
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.php [F,L]
#
########## End - Rewrite rules to block out some common exploits

Dalla versione 1.0.8 di Joomla sono stati introdotti cambiamenti significativi nel file, ma non sono state incluse le direttive di cui sopra per alcuni motivi. Forse una futura versione lo farà. Nel frattempo, la loro aggiunta introduce un livello di sicurezza maggiore.

Sarebbe anche una buona idea proteggere il proprio sito contro tracking e tracing, e se si è su un server condiviso, il modo più semplice è aggiungere le righe seguenti (dopo il comando RewriteEngine On):

Direttiva RewriteEngine

RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
RewriteRule .* - [F]

Da notare che non tutte le modifiche fatte nel file verb|.htaccess| sono supportate dai server, dipende dalle configurazioni. E’ bene effettuare sempre una copia di backup del file prima di modificarlo, così se il sito inizia a mostrare errori, si può sempre tornare indietro.

Impostazioni del server Joomla specifica alcune impostazioni raccomandate per un perfetto funzionamento del sistema. Una lista di impostazioni viene fornita in fase di installazione. Una di esse è di avere Display Errors attivata, ma non è consigliata su un server di produzione. E’ molto utile durante lo sviluppo ed il debug del sito, ma ci sono alcune vulnerabilità di PHP (il linguaggio con cui è scritto Joomla) che permettono attacchi cross-site-scripting quando è abilitata.

Fortunatamente, dalla versione 1.0.10 di Joomla, è possibile sopprimere i messaggi di errore dal menu Sito/Configurazione globale, cliccando sulla sezione Server. Impostare Rapporto errori su Nessuno. Se si sta usando usando una versione antecedente la 1.0.10, sarebbe una buona idea aggiornarla!

Inoltre, per disattivare i messaggi di errori sul server, è necessario modificare alcune impostazioni nel file php.ini, al quale potreste non avere accesso se siete in hosting ma potete aggiungere un vostro file php.ini nella directory principale del sito per modificarne solo il suo comportamento. In alternativa, a seconda della configurazione del server, è possibile sovrascrive le impostazioni di php.ini direttamente nel file .htaccess.
Le impostazioni da modificare nel file php.ini sono:

Modifiche a php.ini

display_errors = Off
html_errors = Off
display_startup_errors = Off
log_errors = On

Se non si ha accesso al file php.ini è possibile aggiungere un proprio file php.ini nella root del sito; maggiori informazioni all’indirizzo http://www.washington.edu/computing/web/publishing/php-ini.html.
Non è necessario inserire tutte le impostazioni nel file php.ini ma solamente quelle che si vogliono personalizzare; dopodichè bisognerebbe chiedere al provider di riavviare Apache per rendere effettive le modifiche (Apache non il server). Nota: se si codificano i file con Zend Optimizer, usando la propria copia di php.ini potrebbe indurre PHP a pensare che Zend non è installato, sebbene lo sia.

Se il server lo permette è possibile inserire le seguenti linee nel file .htaccess senza bisogno di creare un file php.ini. Se il server non dovesse supportarlo, comparirà un messaggio di errore tentando di accedere al sito.

Modifiche a php.ini

php_flag display_errors "0"
php_flag html_errors "0"
php_flag display_startup_errors "0"
php_flag log_errors "1"

Queste impostazioni faranno sì che tutti gli errori PHP vengano salvati in un file anzichè visualizzati nel browser. E’ anche possibile scrivere un gestore degli errori personalizzato in PHP, ma questo esula dagli scopi di questo articolo.

Backup Joomla non ha nessuna opzione di backup. Sarebbe una buona idea utilizzare qualche sistema di backup. Anche se il tuo sito non è oggetto di attacchi, c’è sempre la possibilità di fare accidentalmente qualche errore.

La soluzione più semplice è tenere una copia di tutti i file e del database sul proprio computer, ed ancora meglio, su un supporto rimovibile (CD, DVD, …). Se il sito è in continuo mutamento, è necessario un qualche sistema automatico di backup. In molti casi i file non cambiano molto, ma il database sì. E? possibile utilizzare Auto mySQL Backup (script gratuito che esporta, comprime ed invia per email il database) o qualche altro componente specificamente studiato per Joomla, quali eBackup o baBackup.

Per schedulare un backup ad intervalli definiti, è necessario impostare un CRON job sul server. Per maggiori informazioni si consultino i link seguenti:

Amministrazione del sito Il backend di Joomla è uno strumento molto potente per controllare i contenuti del proprio sito, e quindi non si desidera che persone non autorizzate possano accedervi. Joomla permette anche agli amministratori di loggarsi nel frontend e modificare i contenuti direttamente da lì. Un’installazione standard di Joomla è sufficientemente sicura per usi non critici, ma se la sicurezza è un vincolo importante, è bene utilizzare SSL per il login e per tutte le attività che richiedono di essere loggati. Questa non è una caratteristica fornita con Joomla 1.0.10 e precedenti, ma è possibile comunque renderla operativa.

 
Tratto da www.joowiki.com/com_openwiki/manuale Ultima modifica: 2007/11/03 20:40 da neoviruz

Lista componenti che contengono dei BUG che consigliamo di non installare o tenere costantemente aggiornati:
http://help.joomla.org/component/option,com_easyfaq/task,view/id,186/Itemid,268/

Mambots AntiSpamm
http://www.teachmejoomla.net/news/latest/joomla-anti-spam.html

Premettendo che anche blindando le cartelle non si è mai sicuri al 100% qui il problema è magari … quali cartelle devono essere necessariamente scrivibili per il corretto funzionamento di Joomla.
Se reimpostiamo la domanda così magari è meglio, in quanto per funzionare al massimo joomla necessita di alcune cartelle scrivibili (cache e media) le altre … possiamo anche lasciarle non scrivibili però non sarà a noi possibile installare nessun tipo di add-on in futuro.

Se stiamo creando un nuovo sito è bene che tutte le cartelle indicate in fase installazione siano scrivibili…. quando siamo sicuri che il sito è terminato e non dovremo aggiungere nessus componente, modulo template o bot potremo chiudere le porte e rendere non scrivibili le cartelle
template
component
mambot
(potremmo anche per la cartella images… ma se vogliamo inserire nuove immagini nei nostri articoli è bene che questa sia scrivibile)

Poi in futuro facciam gli scongiuri … perchè per quanto sia forte la nostra barriera di sicurezza … esisterà sempre un signorino che a furia di picchia e ripicchia … poi la strada la trova ed entra lo stesso.
Se poi si pensa anche che, su server di qualsiasi hosting coabitano più siti con più programmi diversi, basta che uno di questi sia bacato … e tutti gli altri cadono giù come foglie al vento…
(esempio pratico: è inutile comprarsi la porta blindata se le mura sono di cartone)

Google ha rilasciato un nuovo prodotto, Google Code Search, che è capace di indicizzare ed infilarsi attraverso i file archiviati nelle directory contenute nei server web. Stiamo segnalando questo come avviso di sicurezza perché abbiamo scoperto che alcuni amministratori di siti web stanno lasciando archivi e backup nella directory radice loro spazio web.  Per questo motivo, Google Code Search può inserirsi negli archivi e leggere i file PHP non interpretati come se fossero testo normale. Perciò alcune informazioni sensibili potrebbero essere accessibili, comprese  le password di MySQL e le credenziali SMTP.
   
Abbiamo ritenuto che era necessario pubblicare un avviso di sicurezza per avvertire siti esposti al pericolo e allo stesso tempo proteggere ed istruire i nostri utenti su alcune pratiche lper mantenere il vostro sito sicuro.
   
1. Non immagazzinare mai una copia di sicurezza o una versione archiviata del vostro sito Web nelle cartelle accessibili pubblicamente del web server.
2. Non lasciare file nella directory principale se non si vuole che siano letti/indicizzati/scaricati.
3. Se è necessario assolutamente, chiedere al proprio Hosting Provider di disabilitare la generazione dell’indicizzazione della directory per quella directory.*
4. Password per proteggere le directory che contengono le informazioni sensibili.   

Ancora, se pensate che le informazioni di accesso al vostro sito siano compromesse in questo modo, prego rimuovete i backup/archivi immagazzinati nella radice dello spazio web, cambiate tutte le password collegate e se necessario, chiede al vostro Hosting Provider di ripristinare il vostro sito da un backup precedente e di essere sicuro che  rimuovano l’archivio che hanno usato ristabilire il vostro sito.

Se preferite la protezione più attiva contro l’indicizzazione ed il download degli archivi relativi, guardate questa discussione nel Forum di Sicurezza di Joomla, in cui si sta svolgendo una discussione su come proteggersi da questi problemi. http://forum.joomla.org/index.php/topic,101880.0.html   

* L’indicizzazione della directory è una caratteristica di mod_dir, un modulo di Apache che crea una lista di tutti i file in una directory se non esiste index.html /php/etc in quella directory. E’ in questo modo che probabilmente saranno trovati i vostri file con Google code Search.