L’assenza di software tradizionale all’interno delle soluzioni di web hosting (di quello da installare ed utilizzare in locale sul proprio PC o Mac, per intenderci) pone alcune problematiche che finiscono per rendere l’utente medio abbastanza incauto. Una buona porzione di webmaster arriva addirittura a ritenere che sia sufficiente mettere in piedi il sito e farlo funzionare per finire il lavoro con successo. Ma le cose non stanno affatto così, ed è invece bene seguire delle strategie precise per mettere in sicurezza non solo i propri dati, ma anche – ed è il caso degli hosting condivisi – quelli degli altri utenti e del provider che ci sta ospitando. Si tratta spesso di piccole accortezze che, nonostante la relativa facilità di esecuzione, possono preservarci tutti noi da sgradite sorprese…
Perchè molti siti rischiano attacchi?
Se non avete idea di come possa avvenire un attacco al vostro sito sarà necessario fare alcune premesse fondamentali, che riguardano le modalità con cui solitamente avvengono gli attacchi. In realtà si tratta di “approfittare” delle debolezze intrinseche del sito perchè l’attaccante possa, almeno potenzialmente:
- danneggiare/manipolarne i contenuti;
- avere accesso a contenuti esclusivi, come password e username;
- oscurare la visualizzazione delle pagine (ad esempio sostituendo la home con una propria, pratica definita in gergo defacing);
- rallentare le prestazioni del sito o, in casi estremi, dell’hosting stesso.
Per evitare questo la prima cosa che dobbiamo conoscere è la SQL injection: si tratta della circostanza in cui un attaccante sfrutta un form di un sito (un modulo di ricerca, uno di iscrizione al sito oppure, non di rado, di login) manipolando la stringa in ingresso per ottenere un accesso illecito al nostro database. Il meccanismo sfrutta una caratteristica del codice scritto male (ad esempio in PHP) per generare un messaggio di errore e, più in generale, stoppare l’esecuzione della query corrente ed eseguirne una successiva a proprio piacere. L’utilizzo delle query con l’accortezza di filtrare le variabili in ingresso (oppure parametrizzando) permette, nella pratica, di impedire questo genere di rischio. Per capire meglio di cosa stiamo parlando consideriamo la seguente query annessa ad un’ipotetica procedura di login ad un sito:
SELECT * FROM utenti WHERE username = '" + usernameinserita + "';
Se l’attaccante inserisse come username la stringa ‘ or ‘1’=’1 questo provocherebbe una stringa SQL modificata come segue:
SELECT * FROM utenti WHERE username = '' OR '1'='1';
Poichè la condizione 1=1 sarà sempre soddisfatta per definizione, questo metterà nelle condizioni l’attaccante di eseguire una qualunque query in ingresso a proprio piacere (ad esempio DELETE FROM utenti). Un ulteriore pericolo per la sicurezza dei nostri siti deriva dal cosiddetto “Cross Site Scripting” (XSS) che, similmente al caso precedente, fa in modo che l’attaccante possa eseguire codice malevolo a piacere agendo sempre su una form (login, autenticazione, ricerca e via dicendo).
Prima regola per la sicurezza? Ridimensionare i messaggi di errore
Dopo aver fatto questo genere di premesse bisogna tenere d’occhio quello che, fin dall’inizio, potrebbe diventare il punto di debolezza del nostro sito: facciamo riferimento alla notifica degli errori che, specie nella prima fase di vita dello stesso, presenta dei rischi decisamente grossi. Quando un sito è in fase di sviluppo, tuttavia, oppure se state effettuando delle personalizzazioni al codice, è comune far pubblicare al server tutti gli errori che si incontrano, query SQL incluse. Questo può andare bene in fase di sviluppo ma deve necessariamente essere abolito in fase di pubblicazione del sito, in quanto un attaccante potrebbe generare questi errori volutamente per curiosare all’interno del nostro sistema e, sotto opportune condizioni, riuscire a stabilire un primo contatto allo scopo di commettere danni anche molto seri. I messaggi di errore di una finestra di login, quindi, dovrebbero essere molto generici e far capire semplicemente che, ad esempio, esiste un errore di autenticazione (non a caso si usa scrivere “username o password errate” per non far intuire ad un utente malevolo quale abbia sbagliato delle due, e prevenire accessi illeciti per tentativi o brute-force).
Ecco quindi, finalmente, 16 suggerimenti utili per mettere in sicurezza il proprio sito web.
- Utilizzare software open source come WordPress, Drupal, Joomla, Magento e via dicendo: questo una serie di caratteristiche potenti e versatili per i propri scopi, oltre al costante monitoraggio della sicurezza del codice da parte dei vari sviluppatori impegnati nel progetto. Piuttosto che progettare un sito da zero (salvo casi davvero molto specifici), è sempre consigliabile adattare tema e/o core di un CMS esistente di questo tipo.
- Aggiornare sempre le versioni del software, facendo attenzione al fatto che gli update possono in certi casi rimuovere le personalizzazioni. Quindi massima attenzione a come intervenite ad es. sul vostro tema WordPress, il quale per evitare questa evenienza ha realizzato i child theme proprio per permettere customizzazioni sicure. In genere ogni CMS richiede aggiornamenti di sicurezza tempestivi, in caso di dubbi prima di operare consultate attentamente i forum di assistenza specifici.
- Utilizzare password “forti”, ovvero evitare di inserire la propria data di nascita o parole banali o facili da rilevare per tentativi: la password perfetta, si usa dire spesso, deve essere difficile da indovinare e semplice da ricordare, e per fare questo si può pensare ad una combinazione di una o più parole con almeno due numeri. Per stare ancora più tranquilli, un bel carattere non alfabetico (punteggiatura, asterisco ecc) andrebbe inserito nella vostra password.
- Non utilizzare l’email amministrativa del sito nella pagina dei contatti, e questo allo scopo di evitare phishing o spam su questa importante casella di posta (che spesso può essere indovinata perchè standard, ad esempio admin@nomedominio.est).
- Rinominare il prefisso delle tabelle dei vostri database: ad esempio in WordPress è predefinita la stringa “wp_” prima del nome di ognuna, sarebbe consigliabile rinominare queste informazioni (mettendo nomi di fantasia quali “pippo123_” e simili) e poi, naturalmente, aggiornare il prefisso di conseguenza all’interno del file wp-config.php. Questo eviterà che hacker esperti possano, mediante SQL injection, andare a curiosare nel database a vostra insaputa.
- Assicuratevi che gli accessi al database avvengano rigorosamente con username e password: accedere alle tabelle senza autenticazione (come sbrigativamente fanno alcuni) è un potenziale rischio per la sicurezza.
- Sempre a proposito del punto precedente, tenete conto che l’utilizzo ordinario dei CMS non vi obbliga affatto a creare utenze amministrative (con diritti di GRANT elevati ovvero possibilità di rimuovere, rinominare, creare tabelle o eseguire script SQL): in altri termini è bene creare utenze ad hoc con privilegi minimali di lettura e scrittura.
- Validate sempre i campi delle vostre form (ad esempio di login o di ricerca interna nel sito) perchè, in generale, molti attacchi arrivano direttamente da questa fonte (anche qui, SQL injection).
- Le cartelle di installazione del CMS, una volta conclusa la procedura, possono (e spesso devono!) essere rimosse. Ricordatevi di farlo, quindi, perchè altrimenti un utente dall’esterno potrebbe ri-eseguire l’installazione provocando un reset globale del sito (ad esempio eliminando le vostre personalizzazioni e/o i vostri articoli o pagine).
- Alcuni script (specie se datati o sui generis) richiedono i permessi CHMOD 777 per poter funzionare in fase di installazione: è molto pericoloso lasciare invariata questa impostazione durante il normale uso del sito, quindi ricordatevi di settare a 755 o 644 rispettivamente file e cartelle. Questa procedura limita fortemente i rischi derivanti dalla code-injection (XSS).
- Assicuratevi che le password di accesso alla sezione amministrativa del sito siano criptate con SHA1 o almeno MD5 (i più diffusi CMS come WordPress sono già realizzati in questo modo, sui siti fatti a mano la cosa deve necessariamente essere implementata da voi).
- Utilizzare accessi FTP autenticati con username e password e, anche qui, evitare di utilizzare utenze di root o amministrative (spesso queste credenziali coincidono con quelle di accesso al cPanel del sito, ad esempio).
- Se utilizzate server con Linux (qualunque sia il piano di hosting) assicuratevi che nella root del filesystem ci sia un file .htaccess che possa preservare, ad esempio, dalla possibilità di effettuare il listing delle cartelle del sito. Molte impostazioni di sicurezza passano da questo semplice file nascosto, che può preservare dai guai più di quanto si possa pensare.
- Utilizzare un file robots.txt che eviterà (o comunque ridurrà di molto la possibilità) che cartelle amministrative siano incautamente indicizzate sui motori di ricerca, esponendovi così a rischi involontari davvero enormi.
- Proteggete sempre le cartelle amministrative del sito (ad esempio miosito.it/admin), se non c’è un vero e proprio login di autenticazione, con username e password di Apache (sistemi Linux) in modo da impedire la visualizzazione della pagina dall’esterno (e da chi ad esempio potrebbe indovinare il nome della cartella).
- Sfruttate sempre i plugin per la sicurezza – come WP Security Scan per WordPress – e fate in modo di farli girare periodicamente sul vostro sito per tenere la situazione sotto controllo.
- Evitate di installare temi e plugin di “dubbio” contenuto (ad esempio quelli per WP che promettono modo facili per posizionarsi sui motori senza fare nulla) in quanto, molto spesso, contengono codice malevolo che non riuscirete a rilevare se non mediante plugin come quello citato al punto precedente.
- Tenete sempre d’occhio i blog per la sicurezza per saperne di più sugli ultimi attacchi e sulle novità del settore, ad esempio leggendo Wired oppure il blog Krebsonsecurity.