Loading...

Difendiamo i nostri siti con i secure headers

By |09 novembre 2017|Guide|

Difendiamo i nostri Siti con i Secure Headers

Content Security Policy: cosa sono e come implementarle

La sicurezza nel web non è mai garantita al 100% ma con un po’ di accortezza si possono limitare molto i danni che i vari malintenzionati posso recare al vostro sito o application server.

In questo articolo tratterò principalmente l’implementazione degli header di sicurezza che potete applicare a siti che girano su server Apache.

Le Content Security Policy non sono nient’altro che una serie di regole che vanno a definire chi e cosa può interagire con il nostro sistema.

Ricordate che una minuziosa politica di sicurezza deve essere definita  tenendo sempre presente le varie esigenze del vostro sito.

Le modalità con le quali applicare le istruzioni che vi fornirò sono controverse nel settore e vanno in ogni caso valutate una ad una in relazione alla vostra situazione specifica.

Qui di seguito troverete  le implementazioni più comuni, ma vi consiglio fin da ora la lettura di questo approfondimento, che contiene, tra le altre cose, anche la sintassi per applicare gli header in webserver diversi da Apache.

Innanzi tutto il file principale sul quale lavoreremo è .htaccess il quale regola cosa può o non può essere visionato dall’esterno. Per esempio il file .htaccess predefinito di WordPresse è il seguente:

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Quali sono gli header che mi servono ?

Bene, adesso dobbiamo inserire gli header per aumentare la sicurezza. Ne esistono diversi che vi elenco qui sotto:

X-XSS-Protection “1; mode=block”
In Chrome e Internet Explorer blocca quegli attacchi XSS che inviano codice malevolo come parte della richiesta http.

Strict-Transport-Security “max-age=31536000; includeSubdomains;”
Se il vostro sito è raggiungibile sia da http che da https, la richiesta http potrebbe essere intercettata, anche in caso di immediato redirect verso https. Questo header dice al browser di utilizzare solamente https, evitando questa possibilità.

X-Frame-Options “deny”
Impedisce l’inclusione della pagina sia nei frame che negli iframe.

X-Content-Type-Options nosniff
Impedisce al browser di sovrascrivere a propria discrezione i mime-type degli elementi inclusi in pagina, evitando così possibili attacchi XSS.

Content-Security-Policy: “…”
Versione avanzata della  X-XSS-Protection. Questa direttiva è molto utile per mitigare gli attacchi XSS, ma è davvero complicato gestire gli effetti dei parametri che verranno inseriti al posto dei puntini. Per questo motivo, purtroppo, molti scelgono di non usarla.

Inseriamo i primi header

A questo punto possiamo iniziare a inserire i primi heder nel nostro .htaccess, rigorosamente prima della regola generale del WordPress.

partiamo da X-XSS-Protection. 

aggiungete questo in alto prima di tutto.

Header set X-XSS-Protection “1; mode=block”

Nota, a seconda del vostro motore potrebbe essere necessario attivare il modulo header del php: nel caso la dicitura iniziale sarà così composta: 

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

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Adesso implementiamo anche gli altri, ad eccezione delle policy di content.

Header set Strict-Transport-Security "max-age=31536000" env=HTTPS
Header set X-XSS-Protection "1; mode=block"
Header always append X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options nosniff

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

Come controllo se la protezione è attiva ?

Per fare le dovute verifiche potete utilizzare diversi strumenti.

Io ho usato questo sito https://securityheaders.io/ che vi dà, oltre al rating, anche alcuni suggerimenti su come risolvere eventuali problemi. Inoltre se usate Chrome esiste una simpatica estensione che trovate qui http headers crome extension.

Se avete terminato i vostri controlli, adesso la sicurezza dovrebbe essere aumentata. Ma attenzione: alcune di queste direttive non vanno d’accordo con i sistemi di cache tipo vanish, quindi se non vi cambia il grado di rating provate a disabilitare momentaneamente la cache.

Il Content-Security-Policy

Come vi accennavo, questa direttiva è un po’ impegnativa da sistemare, perché con essa andate a calibrare, riga per riga, tutto quello che passa per il vostro sito e dal vostro sito.

Vediamo un piccolo esempio:

Header always set Content-Security-Policy “default-src ‘self’ *.tawk.to *.twimg.com *.google-analytics.com https://syndication.twitter.com;

Qui indichiamo la prima parte della policy dove diciamo al server che accettiamo solo sorgenti che provengono dal dominio stesso default-src ‘self’ , poi aggiungiamo le fonti che possono avere un dialogo con noi, per esempio le analitycs di google *.google-analytics.com , e terminiamo la riga con un ;

Bene, se avete inserito questa regole così come vi ho descritto …. probabilmente non funziona più niente !!!!   :-)))

Tranquilli: è normale.  Si perché sono innumerevoli le fonti esterne che  usiamo quando montiamo un sito:  vediamo quali altre servono.

script-src ‘self’  *.twimg.com *.twitter.com *.googletagmanager.com ‘unsafe-inline’ ‘unsafe-eval’ *.google-analytics.com *.jsdelivr.net https://sharebutton.net *.sharebutton.net http://maps.googleapis.com https://maps.gstatic.com https://ajax.googleapis.com https://www.google.com https://www.gstatic.com https://cdn.syndication.twimg.com/ ;

Eccoci al dunque: mancano i vari script che regolano e fanno funzionare i nostri plug-in. Come sopra, la regola principale è self  , poi aggiungiamo i domini autorizzati.

Ok.

Abbiamo fatto tutto bene.

Adesso dobbiamo solo fare un test!

E invece no! :-)))   Mancano ancora alcune cosette, tipo i font e i frame, le font css e gli oggetti.  Esattamente come vi ho detto prima, andiamo ad aggiungerli.

style-src ‘self’ ‘unsafe-inline’ *.jsdelivr.net  http://fonts.googleapis.com https://ton.twimg.com/ http://platform.twitter.com;

img-src ‘self’ data: *;font-src ‘self’ data: * ;

frame-src *.example.com https://www.google.com/recaptcha/ https://platform.twitter.com/ https://syndication.twitter.com/;

object-src ‘self'”

Riassumendo i Content Secuity Policy

E’ estremamente importante che tutti questi ultimi header siano scritti in una unica fila, quindi la regola nel nostro esempio sarà:

Header always set Content-Security-Policy “default-src ‘self’ *.tawk.to *.twimg.com *.google-analytics.com https://syndication.twitter.com ; script-src ‘self’  *.twimg.com *.twitter.com *.googletagmanager.com ‘unsafe-inline’ ‘unsafe-eval’ *.google-analytics.com *.jsdelivr.net https://sharebutton.net *.sharebutton.net http://maps.googleapis.com https://maps.gstatic.com https://ajax.googleapis.com https://www.google.com https://www.gstatic.com https://cdn.syndication.twimg.com/ ;style-src ‘self’ ‘unsafe-inline’ *.jsdelivr.net http://cdn.iubenda.com http://fonts.googleapis.com https://ton.twimg.com/ http://platform.twitter.com;img-src ‘self’ data: *;font-src ‘self’ data: * ; frame-src *.example.com https://www.google.com/recaptcha/ https://platform.twitter.com/  https://syndication.twitter.com/;object-src ‘self'”

In conclusione vi dico che applicare questa metodologia è complicato e sicuramente non adatto ai principianti.  Ad ogni modo sapere come aumentare la sicurezza del vostro sito non è affatto tempo perso.  Se volete, altre fonti le trovate qui:

E in caso abbiate bisogno di aiuto o vogliate semplicemente approfondire, sapete che potete contattarmi in qualsiasi momento.