Le 5 principali scappatoie di sicurezza nelle installazioni di WordPress

La sicurezza della tua installazione WordPress è un aspetto completamente personalizzabile. Scopri i cinque pilastri fondamentali per una protezione efficace.

Le preoccupazioni riguardanti la sicurezza di WordPress non sono affatto nuove.

Se sei alla ricerca di un CMS e ti capita di consultare un fornitore di servizi che non propone WordPress, la sicurezza sarà probabilmente il primo argomento critico che sentirai menzionare. Questo significa che dovremmo abbandonare WordPress per passare a generatori di siti statici o CMS headless?

Assolutamente no, perché come spesso accade, la verità è più complessa e sfaccettata.

WordPress è davvero così insicuro?

Analizziamo alcuni siti web di spicco che sono stati realizzati con WordPress:

  • TechCrunch
  • The New Yorker
  • BBC America
  • Bloomberg
  • MTV News
  • PlayStation Blog

Cosa impedisce a queste aziende, con risorse finanziarie considerevoli e un personale altamente qualificato, di abbandonare WordPress? Se pensi che la risposta sia legata a un codice obsoleto, ti sbagli: per questi nomi, la sicurezza dei dati e l’immagine pubblica sono priorità assolute, molto più importanti di una semplice migrazione che costerebbe (a mio parere) meno di 200.000 dollari.

I loro ingegneri, di certo esperti, non riscontrano forse problemi di sicurezza insormontabili e intrinseci a WordPress?

Personalmente, ho il privilegio di gestire un’installazione WordPress che accoglie tra i 3,5 e i 4 milioni di visitatori al mese. Il numero totale di violazioni della sicurezza negli ultimi otto anni? Zero!

Quindi… WordPress è sicuro?

Mi scuso se la mia risposta può sembrare ambigua, ma la verità è che:

Affermo ciò perché, come molte cose nella vita, la situazione è complessa. Per fornire una risposta valida, dobbiamo prima comprendere che WordPress (o qualsiasi CMS preconfezionato) non è un sistema che si installa e si dimentica.

È un software complesso con numerose dipendenze:

  • PHP, il linguaggio su cui è costruito
  • Una macchina accessibile pubblicamente che ospita l’installazione
  • Il server web incaricato di gestire i visitatori (Apache, Nginx, ecc.)
  • Il database utilizzato (MySQL/MariaDB)
  • I temi (pacchetti di file PHP, CSS e JS)
  • I plugin (insiemi di file PHP, CSS e JS)
  • E molti altri fattori, a seconda delle funzionalità desiderate dall’installazione

In altre parole, una falla di sicurezza in uno di questi punti sarà considerata una violazione della sicurezza di WordPress.

Se la password di root del server era “admin123” ed è stata compromessa, è una carenza di sicurezza di WordPress?

Se la versione di PHP presentava una vulnerabilità, o se il nuovo plugin acquistato e installato conteneva una palese falla di sicurezza, e così via. In sintesi: un sottosistema difettoso viene interpretato come un errore di sicurezza di WordPress.

Non fraintendere, questo non significa che PHP, MySQL e Apache siano intrinsecamente insicuri. Ogni software presenta delle vulnerabilità, il cui numero è particolarmente alto nel caso dell’open source (poiché è accessibile a chiunque per essere analizzato).

Qualcuno ha detto “sicuro”? 😛

L’insegnamento di questa analisi è chiaro:

Nessun elemento è sicuro o insicuro di per sé. Sono i diversi componenti che formano gli anelli della catena, e la catena, come noto, è forte quanto l’anello più debole. Storicamente, la reputazione di “insicuro” di WordPress derivava da una combinazione di vecchie versioni di PHP, hosting condiviso e dall’aggiunta di plugin/temi provenienti da fonti inaffidabili.

Allo stesso tempo, alcune disattenzioni piuttosto comuni rendono la tua installazione WordPress vulnerabile a chi sa come sfruttarle e ha intenzione di farlo. Questo è l’argomento di questo articolo. Quindi, senza ulteriori preamboli (e digressioni), iniziamo.

Le principali vulnerabilità di WordPress che gli hacker possono sfruttare

Il prefisso della tabella di WordPress

La celebre installazione in 5 minuti è un grande vantaggio di WordPress, ma come tutti gli strumenti di installazione guidata, tende a renderci pigri e a farci accettare le impostazioni predefinite.

Questo implica che il prefisso predefinito per le tue tabelle WordPress sia “wp_”, il che si traduce in nomi di tabelle facilmente intuibili:

  • wp_users
  • wp_options
  • wp_posts

Consideriamo ora un attacco noto come SQL Injection, in cui query di database dannose vengono abilmente inserite ed eseguite all’interno di WordPress (nota: questo non è un attacco esclusivo di WordPress/PHP).

Sebbene WordPress disponga di meccanismi integrati per contrastare questi tipi di attacchi, nessuno può garantire la loro completa eliminazione.

Quindi, se un attaccante riuscisse in qualche modo a eseguire una query come “DROP TABLE wp_users; DROP TABLE wp_posts;”, tutti i tuoi account, profili e articoli verrebbero eliminati istantaneamente, senza possibilità di recupero (a meno che tu non abbia un sistema di backup attivo, ma anche in questo caso perderesti i dati dall’ultimo backup).

La semplice modifica del prefisso durante l’installazione può fare una grande differenza (senza richiedere alcuno sforzo).

Si consiglia di utilizzare un prefisso casuale come “sdg21g34_”, poiché è illogico e difficile da indovinare (più lungo è il prefisso, meglio è). Il vantaggio è che non deve essere memorabile; WordPress lo salverà e non dovrai più preoccupartene (proprio come non ti preoccupi del prefisso “wp_” predefinito!).

L’URL di accesso predefinito

Come si fa a capire se un sito web è basato su WordPress? Uno degli indizi è la visualizzazione della pagina di accesso di WordPress quando si aggiunge “/wp-login.php” all’indirizzo del sito.

Ad esempio, prendiamo il mio sito web (https://ankushthakur.com). È basato su WordPress? Prova ad aggiungere la parte di accesso. Se ti sembra faticoso, ecco cosa succede:

¯_(ツ)_/¯

WordPress, giusto?

Una volta che un attaccante è a conoscenza di ciò, può iniziare a mettere in atto le sue strategie.

La soluzione consiste nel modificare l’URL di accesso predefinito e divulgarlo solo a persone fidate.

Ad esempio, questo sito web è anch’esso basato su WordPress, ma se visiti https://winadmin.it.com/wp-login.php, rimarrai deluso. L’URL di accesso è celato ed è noto solo agli amministratori.

Modificare l’URL di accesso non è una procedura complicata. Prova questo plugin.

Congratulazioni, hai appena aggiunto un ulteriore livello di protezione contro gli attacchi di forza bruta.

La versione PHP e del server web

Abbiamo già sottolineato come ogni software, sia già sviluppato che in fase di realizzazione, sia pieno di bug in attesa di essere scoperti.

Lo stesso vale per PHP.

Anche se stai utilizzando l’ultima versione di PHP, non puoi avere la certezza di quali vulnerabilità esistano e possano essere individuate da un momento all’altro. La soluzione è nascondere una particolare intestazione inviata dal tuo server web (hai mai sentito parlare di intestazioni? Leggi questo articolo!) quando un browser si connette: x-powered-by.

Ecco come si presenta quando controlli gli strumenti di sviluppo del tuo browser preferito:

Come puoi vedere, il sito web rivela di funzionare con Apache 2.4 e di utilizzare la versione PHP 5.4.16.

Queste sono già molte informazioni che trasmettiamo senza motivo, aiutando l’attaccante a restringere il campo degli strumenti utilizzabili.

Queste (e simili) intestazioni devono essere oscurate.

Fortunatamente, la modifica è semplice; purtroppo, richiede competenze tecniche avanzate poiché è necessario intervenire direttamente nei file di sistema. Pertanto, il mio consiglio è di chiedere al tuo provider di hosting di farlo per te; se non è in grado di aiutarti, puoi rivolgerti a un consulente. Naturalmente, la fattibilità dipenderà in gran parte dalle impostazioni del tuo provider di hosting.

Se non funziona, potrebbe essere il momento di cambiare provider di hosting o di passare a un VPS e assumere un consulente per questioni di sicurezza e amministrazione.

Ne vale la pena? La decisione spetta a te. 🙂

Ah, e se vuoi approfondire l’argomento delle intestazioni di sicurezza, ecco la soluzione!

Numero di tentativi di accesso

Uno dei trucchi più antichi dell’hacker è il cosiddetto attacco dizionario.

L’idea è di provare un numero incredibilmente elevato (milioni, se possibile) di combinazioni di password fino a quando una non risulta corretta. Dato che i computer sono rapidissimi, questa strategia apparentemente insensata può dare risultati in tempi accettabili.

Una difesa comune (e molto efficace) consiste nell’introdurre un ritardo prima della visualizzazione dell’errore. Questo obbliga l’attaccante ad aspettare, e nel caso di uno script utilizzato da un hacker, richiederebbe troppo tempo. Ecco perché il tuo computer o la tua app preferita esita per qualche secondo prima di comunicare “Oops, password errata!”.

Ad ogni modo, il punto è che devi limitare il numero di tentativi di accesso per il tuo sito WordPress.

Superato un certo numero di tentativi (diciamo, cinque), l’account dovrebbe essere bloccato e recuperabile solo tramite l’indirizzo email del proprietario.

Per fortuna, è una procedura semplicissima, grazie a questo pratico plugin.

HTTP e HTTPS

Il certificato SSL per il quale il tuo fornitore ti ha insistito tanto è più importante di quanto pensi.

Non è solo un simbolo che mostra un lucchetto verde nel browser con la dicitura “Sicuro”; installare un certificato SSL e forzare tutti gli URL a funzionare su “https” è sufficiente per trasformare il tuo sito web da un libro aperto a un messaggio criptato.

Se non hai familiarità con questo concetto, ti consiglio di approfondire l’argomento del attacco man-in-the-middle.

Un altro metodo per intercettare il traffico dal tuo computer al server è lo sniffing dei pacchetti, una forma passiva di raccolta dati che non richiede necessariamente di posizionarsi “in mezzo” alla comunicazione.

Per i siti che utilizzano il semplice “HTTP”, le persone che intercettano il traffico di rete possono visualizzare password e numeri di carte di credito in chiaro, come testo semplice.

Fonte: comparitech.com

Allarmante? Decisamente!

Dopo aver installato un certificato SSL e convertito tutti gli URL in “https”, queste informazioni sensibili diventano indecifrabili, e solo il server può decrittografarle. Non lesinare su quei pochi euro all’anno. 🙂

Conclusione

Riuscirai a proteggere adeguatamente il tuo sito web prendendo le dovute precauzioni?

No, non è sufficiente. Come evidenziato in numerosi articoli sulla sicurezza, non si può mai essere sicuri al 100%, ma è possibile eliminare un’ampia gamma di problemi con un impegno ragionevole. Potresti valutare l’utilizzo di SUCURI cloud WAF per proteggere i tuoi siti in modo completo.