Le WordPress Security Headers.

 

7 + 1 Vulnerabilità di sicurezza in WordPress e come correggerle facilmente.
(senza utilizzare alcun plugin inutile)

 

Le WordPress Security Headers che è il CMS più popolare sul web ed attualmente è installato in oltre il 32,4% di tutti i siti web.

Una quota di mercato così ampia, comporta sempre ulteriori problemi di sicurezza e, di conseguenza, aumenta il rischio di attacchi quando vengono scoperte delle vulnerabilità.

Questo post nasce con lo scopo di darti alcuni suggerimenti, su cosa puoi fare per rafforzare la sicurezza in WordPress, in particolare come mettere in sicurezza le WordPress Security Headers, per aiutarti ad evitare di essere hackerato, o di diventare vittima del prossimo attacco di brute force (forza bruta).

Durante l’esposizione, verranno usati i termini WordPress Security Headers e HTTP Security Headers con lo stesso significato.

 

Vulnerabilità di WordPress tramite le Security Headers

 

Qual è il rischio maggiore in WordPress?

Secondo WP Scan, uno degli scanner di vulnerabilità per WordPress più utilizzati in rete, finora sono state segnalate 20108 vulnerabilità (tra core di WP, plugin e temi): il 52% delle vulnerabilità segnalate sono state trovate nei plugin di WordPress, il core di WordPress rappresenta il 37% e i temi WordPress l’11%.

Questi dati sono stati confermati anche dai risultati di Wordfence, che ha scoperto che il 58,6% delle vulnerabilità proviene dai plugin.

 

Che tipo di vulnerabilità sono state trovate?

Sempre secondo WP Scan, il 39% delle vulnerabilità di WordPress sono di tipo cross-site scripting (XSS).

Ecco la ripartizione in ordine di importanza:

XSS: 39%
SQLI: 15%.
Carica: 11%
CSRF: 7%.
Multi: 6%
Sconosciuto: 6%
LFI: 3%
RCE: 3%
FPD: 2%.
Auth Bypass: 2%.
RFI: 2%
Bypass: 2%.
Reindirizzamento: < 1%
XXE: < 1%.
DOS < 1%
SSRF: < 1%.

 

 

Gli attacchi che si compiono ogni minuto nella rete mondiale, stanno aumentando esponenzialmente di mese in mese, tant’è che qualcuno stima che, il 19% di tutto il traffico globale, sia dato proprio dagli attacchi ai siti ed ai server web.

Ci sono molte cose da considerare quando si mette in sicurezza il proprio sito web o web application, ma un buon punto di partenza è quello di esplorare le WordPress Security Headers per assicurarsi di stare utilizzando le migliori strategie.

Spesso sono molto facili da implementare, e richiedono solo una leggera modifica della configurazione del server web.

Queste  HTTP Security Header forniscono un ulteriore livello di protezione, contribuendo a mitigare gli attacchi e le vulnerabilità.

In questo post ne esploreremo alcune, per aiutarti a capire meglio il loro scopo e come implementarle.

Cosa sono le WordPress Security Headers (o HTTP Security Headers)?

Ogni volta che un browser richiede una pagina da un server web, questi risponde con il contenuto insieme alle
intestazioni di risposta HTTP.

Alcune di queste, contengono metadati di contenuto come il Content-Encoding, Cache-Control, codici di stato, ecc.

Inoltre ci sono anche le HTTP Security Headers che dicono al browser come comportarsi quando si gestiscono dei contenuti multimediali.

Ad esempio, utilizzando la Strict-Transport-Security (STS), è possibile forzare il browser a comunicare esclusivamente tramite HTTPS.

Ci sono 7+1 diverse WordPress Security Headers che esploreremo qui di seguito (in nessun ordine particolare), di cui dovresti essere a conoscenza e che ti consigliamo di implementare.

 

1. Content-Security-Policy (CSP)

L’header Content-Security-Policy indica ai browser quali risorse dinamiche è consentito caricare.

Questa intestazione è particolarmente utile per fermare gli attacchi XSS e altre attività dannose, e fornisce ampie opzioni di configurazione, che dovranno essere correttamente settate per corrispondere alle risorse specifiche richieste dal tuo sito.

Altrimenti, se la configurazione dell’intestazione non dovesse corrispondere ai requisiti richiesti, alcune risorse potrebbero non caricarsi (o funzionare) correttamente.

Per questo motivo, non c’è uno script di esempio comune dal quale prendere spunto, perchè ognuno consente diversi tipi di soluzioni.

Esempio 1

Una direttiva CSP che permette di utilizzare risorse da un CDN e non permette di inserire contenuti o plugin multimediali tramite iframe.

# Content-Security-Policy - Example 1
<IfModule mod_headers.c>
Content-Security-Policy: default-src https://cdn.example.com; child-src 'none'; object-src 'none'
</IfModule>

Esempio 2

Questa direttiva CSP abilita le risorse di script caricate da un sottodominio jQuery e limita i fogli di stile e le immagini al dominio corrente (self).

# Content-Security-Policy - Example 2
<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'none'; img-src 'self'; script-src 'self' https://code.jquery.com; style-src 'self'"
</IfModule>

Esempio 3

Questo esempio qui sotto, consente di utilizzare script sia dal dominio corrente (definito da ‘self’) che da google-analytics.com.

# Content-Security-Policy - Example 3
<IfModule mod_headers.c>
Content-Security-Policy: script-src 'self' https://www.google-analytics.com
</IfModule>

Esempio 4

In questo quarto esempio, viene utilizzato esclusivamente il protocollo HTTPS, per tutte le fonti presenti nel sito:

# Content-Security-Policy - Example 4
<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src https:; font-src https: data:; img-src https: data:; script-src https:; style-src https:;"
</IfModule>

Per avere un’idea più chiara di quello che stiamo facendo, possiamo anche formattare il codice nel seguente modo:

<IfModule mod_headers.c>
Header set Content-Security-Policy "

default-src https:;
font-src https: data:;
img-src https: data:;
script-src https:;
style-src https:;

"
</IfModule>

A questo punto dovresti avere un’idea più chiara: l’intestazione sta impostando la sorgente o le sorgenti consentite per i font, le immagini, gli script e gli stili.

Per ognuna di queste è necessaria una connessione HTTPS sicura: l’unica eccezione è quella di consentire gli URI di dati come fonte per i font e le immagini.

Quindi, per ognuno di questi esempi, quando viene aggiunto al file .htaccess del sito o al file di configurazione del server, il codice indica ai browser quali sono le risorse dinamiche consentite e quelle non consentite.

2. X-XSS-Protection

L’header X-XSS-Protection è stata progettata per abilitare il filtro cross-site scripting (XSS) integrato in tutti i moderni browser web.
Aggiunto al file .htaccess del vostro sito o al file di configurazione del server, questo codice istruisce i browser, a bloccare qualsiasi richiesta contenente script dannosi.

Ecco un esempio di come appare l’header:

# X-XSS-Protection
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
</IfModule>

3. HTTP Strict Transport Security (HSTS)

L’header Strict-Transport-Security è un miglioramento della sicurezza che limita l’accesso dei browser ai server web esclusivamente tramite HTTPS.

Questo garantisce che la connessione non possa essere stabilita attraverso una connessione HTTP non sicura perchè in chiaro, la quale potrebbe essere suscettibile di attacchi.

In questa direttiva è possibile includere la max-age, i sottodomini e il preload.

Ecco un esempio di come potrebbe essere l’intestazione:

# Strict-Transport-Security
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=31588000; includeSubDomains"
</IfModule>

Aggiunto al file .htaccess del sito o al file di configurazione del server, questo codice indica ai browser di usare sempre l’HTTPS per le connessioni.

In questo modo la direttiva aiuta a fermare gli attacchi man-in-the-middle (MITM) e simili, che mirano a connessioni HTTP in chiaro.

 

4. X-Frame-Options

L’header di X-Frame-Options (XFO) fornisce una protezione contro il clickjacking non permettendo il caricamento di iframe sul vostro sito web.

Aggiunto al file .htaccess del vostro sito o al file di configurazione del server, questo codice istruisce i browser a bloccare qualsiasi fotogramma/contenuto richiesto esternamente.

Quindi, se il vostro sito include un iframe che carica una risorsa dallo stesso dominio, il contenuto verrà caricato normalmente, se invece è incluso un iframe che carica risorse da qualsiasi altro dominio, il contenuto sarà bloccato (ad esempio se hai incluso un video da YouTube o Vimeo tramite iframe).

Ecco un esempio di come sarebbe l’intestazione:

# X-Frame-Options
<IfModule mod_headers.c>
Header set X-Frame-Options "SAMEORIGIN"
</IfModule>

 

5. Expect-CT

L’header Expect-CT impedisce l’utilizzo di certificati emessi in modo errato, consentendo ai siti web di segnalare e, facoltativamente, di far rispettare i requisiti di trasparenza dei medesimi.

La policy dell’header Expert-CT significa che gli user-agent, ad esempio i browser, devono bloccare l’accesso a un sito web con un certificato non registrato nei “public Certificate Transparency logs” (nato dopo l’ottobre 2017).

L’omissione della direttiva di applicazione farà funzionare il sito solo in modalità report-uri.

Viceversa, la direttiva report-uri non ha senso se utilizzata insieme alla direttiva di “enforce“.

max-age
Il tempo, in secondi, che l’user-agent deve considerare l’host ricevuto come Expect-CT Host.

report-uri
Una direttiva opzionale che indica l’URI a cui l’user-agent deve segnalare i malfunzionamenti di Expect-CT.

enforce
Una direttiva facoltativa e senza valore che, se presente, segnala all’user-agent di bloccare le richieste future che violano le policy di Certificate Transparency.

Ecco un esempio di come potrebbe essere l’header:

<IfModule mod_headers.c>
Header set Expect-CT "max-age=304800, enforce"
</IfModule>

#{Expect-CT: max-age=304800, enforce, report-uri=”https://www.example.com/report”}

 

6. X-Content-Type-Options

L’header di sicurezza X-Content-Type-Options consente ai browser di supporto di proteggersi dagli exploit di sniffing di tipo MIME.

Lo fa disabilitando la funzione di sniffing MIME del browser e costringendolo a riconoscere il tipo MIME inviato dal server.

Questa intestazione è molto flessibile e può essere configurata in modo estensivo: l’implementazione più comune si presenta in questo modo:

# X-Content-Type-Options
<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
</IfModule>

Aggiunto al file .htaccess del vostro sito o al file di configurazione del server, questo codice indica ai browser di utilizzare il tipo MIME dichiarato dal server di origine.

Ci sono però un paio di precauzioni da tenere a mente.

In primo luogo, come per qualsiasi intestazione di sicurezza, non arresta il 100% di tutti gli attacchi o minacce, ma ne blocca alcuni, fornendo così un altro livello di protezione per il vostro sito.

In secondo luogo, questa intestazione non è attualmente supportata da tutti browser: si spera che anche gli altri browser aggiungeranno questa funzionalità in futuro.

 

7. Feature-Policy

L’header Feature-Policy indica ai browser quali funzioni del browser sono consentite.

Ad esempio, se si vuole garantire che siano consentite solo le funzioni di geolocalizzazione, è possibile configurare l’header Feature-Policy di conseguenza.

Essa consente anche di controllare l’origine, per ogni caratteristica specificata.

Ecco un esempio di come appare questo header:

# Feature-Policy
<IfModule mod_headers.c>
Header set Feature-Policy "geolocation 'self'"
</IfModule>

Aggiunto al file .htaccess del vostro sito o al file di configurazione del server, questo codice indica ai browser di abilitare solo le funzioni di geolocalizzazione.

Tieni presente che questa WordPress Security Headers non riguarda tanto la sicurezza quanto piuttosto l’assicurare una certa “smooth experience” ai tuoi utenti.

 

8. Referrer-Policy

L’intestazione di sicurezza Referrer-Policy istruisce i browser moderni su come gestire o escludere l’intestazione Referer (sì, l’intestazione è normalmente scritta in modo errato, manca una “r”).

Per coloro che non hanno familiarità, l’intestazione Referer contiene informazioni sulla provenienza della richiesta.

Quindi, ad esempio, se ci si trova su example.com e si clicca su un link che porterà a domain.tld, l’intestazione del Referer specificherà example.com come URL “di riferimento”.

Tenendo presente questo, la Referrer-Policy consente di controllare se l’intestazione Referer è inclusa o meno nella richiesta.

Ecco un esempio che mostra come aggiungere l’intestazione Referrer-Policy tramite Apache:

# Referrer-Policy
<IfModule mod_headers.c>
Header set Referrer-Policy "same-origin"
</IfModule>

Aggiunto al file .htaccess del vostro sito o al file di configurazione del server, questo codice indica ai browser di supporto di impostare solo l’intestazione del referrer per la richiesta dal dominio corrente (same-origin).

Tieni presente che questo header non riguarda tanto la sicurezza, quanto il controllo delle informazioni del referrer, come richiesto da varie norme e regolamenti ad esempio, quello del GDPR.

 

Tutti gli script insieme

Per facilitare il copia/incolla, ecco una porzione di codice che unisce tutte le security headers sopra descritte.

Importante: prima di aggiungere questo codice al tuo sito, assicurati di leggere ogni script come spiegato nelle sezioni corrispondenti più sopra.

Potrebbero esserci note e informazioni importanti che devi comprendere riguardo ad ogni direttiva, inclusa in questo snippet di codice.

# Security Headers
<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
Header set X-Frame-Options "SAMEORIGIN"
Header set Expect-CT "max-age=304800, enforce"
Header set X-Content-Type-Options "nosniff"
Header always set Strict-Transport-Security "max-age=31588000; includeSubDomains"
# Header set Content-Security-Policy ...
Header set Referrer-Policy "same-origin"
Header set Feature-Policy "geolocation 'self'"
</IfModule>

Come per tutti gli script elencati nella pagina, questo codice può essere aggiunto al tuo sito tramite .htaccess o Apache config.

Comprenderai che questa tecnica include configurazioni comunemente usate per ciascuna delle intestazioni incluse.

Potrai (e dovresti) passare attraverso ognuna di esse per assicurarti che la configurazione corrisponda ai requisiti del tuo sito.

Ricordati di fare sempre un test approfondito prima di usarlo in un “production environment”.

Nota: # Header set Content-Security-Policy ...

Il simbolo dell’hashtag significa che la linea è disabilitata e viene ignorata dal server.

Questo significa che la direttiva sulla sicurezza del contenuto è “commentata” e quindi non è attiva.

Perché?

Perché, come spiegato in precedenza, non esiste uno script di esempio di CSP unico consigliato, che funzioni perfettamente in tutti i siti web.

Al contrario, sarà necessario sostituire la linea commentata con la propria intestazione di Content-Security-Policy (CSP) correttamente configurata, come spiegato in precedenza.

Bene, arrivati a questo punto, non ti resta altro da fare che controllare se tutte le direttive che hai applicato, sono state eseguite in maniera corretta.

Come controllare, quindi, le HTTP security headers?

Un modo rapido ed efficace per controllare le tue HTTP security header è la scansione del tuo sito web sulle intestazioni di sicurezza.

Il sito che ti consiglio di usare è un servizio gratuito fornito da

https://www.securityheaders.io

Si tratta di un piccolo e pratico strumento sviluppato da Scott Helme, un consulente per la sicurezza delle informazioni.

Da al tuo sito web un punteggio, basato sulle attuali intestazioni di sicurezza HTTP, da un grado A+ fino a un grado F.

Ecco un esempio di voto A+ sul suo sito web.

 

 

 

Ecco un esempio di grado F senza alcuna delle intestazioni di sicurezza HTTP presenti sul sito web aziendale di Citi.

 

 

Il report fornisce anche gli HTTP Security Headers grezzi con un bel riassunto di ognuna, indicando anche quello eventualmente mancante.

 

Conclusioni

Come puoi vedere, le HTTP Security Headers possono aiutare a migliorare la sicurezza di un sito web e, nella maggior parte degli scenari, non c’è motivoper non utilizzarle.

In questo lungo post, come avrai visto, si è scelto di utilizzare le WordPress Security Headers esclusivamente tramite il file .htaccess che trovi nella cartella principale del tuo spazio web.

Perché è stata scelta questa strada?

Perchè ho pensato che tu abbia un hosting condiviso, il quale al 99% delle volte, non ti darà accesso ai file di configurazione del tuo server web Apache o NGINX che sia.

Oltre a questo, se in un futuro volessi spostare il o i tuoi siti dal tuo attuale fornitore di hosting ad un altro come il nostro, non dovrai far altro che trasferire la cartella radice del tuo sito compreso il file .htaccess che hai già creato, senza perdere tempo in configurazioni dispendiose.

Se non hai il completo accesso ai tuoi server web, sappi che un voto F negli HTTP Security Headers non è mai una buona cosa!

Avete qualche altra idea sulle WordPress Security Headers?

Se sì, lascia un commento qui sotto.