Security header: il controllo base che fallisce

Quando il browser carica un sito web, il server restituisce più della sola HTML. Invia anche una serie di header di risposta HTTP: piccole istruzioni che dicono al browser come comportarsi. La maggior parte è tecnica invisible, ma cinque di questi sono controlli di sicurezza e, se assenti o configurati male, il browser non ha modo di proteggere i tuoi visitatori contro un'intera classe di attacchi.

Eseguiamo questo controllo su ogni sito in Noroshi. Nel nostro insieme di dati di siti web di PMI europee, oltre l'80% fallisce almeno tre di questi cinque header. La buona notizia: correggerli non costa nulla e richiede meno di un pomeriggio.

Cosa fanno davvero i security header

I security header sono il modo del server di fissare regole di base per il browser. Senza di essi il browser ricade nei suoi valori predefiniti più permissivi: esegue qualunque script, mostra la pagina dentro il frame di qualunque altro sito, invia cookie via HTTP e rivela il tipo di server a chiunque lo chieda. Ognuno di quei valori predefiniti è stato sfruttato infinite volte.

I cinque header che contano di più:

1. Content-Security-Policy (CSP)

La CSP dice al browser quali script, fogli di stile, font e altre risorse possono essere caricati. Una CSP restrittiva blocca gli script iniettati sul nascere: anche se un attaccante riesce a inserire un tag script nella tua HTML (tramite una vulnerabilità del tuo CMS o una libreria di terze parti compromessa), il browser semplicemente si rifiuta di eseguirlo.

Senza CSP il tuo sito è vulnerabile al cross-site scripting (XSS). L'XSS è costantemente nella OWASP Top 10 dei rischi di sicurezza web più critici ed è l'attacco dietro la maggior parte degli incidenti di manomissione del checkout: uno script iniettato nella tua pagina di pagamento invia i numeri della carta al server dell'attaccante mentre la transazione appare normale a tutti i coinvolti.

Una policy iniziale restrittiva per un sito che carica solo le proprie risorse: Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'. Se usi font esterni, analytics o un widget di pagamento, quei domini vanno elencati esplicitamente.

2. Strict-Transport-Security (HSTS)

L'HSTS dice ai browser di usare sempre HTTPS per il tuo dominio, per un periodo definito, e di rifiutare qualunque connessione HTTP, redirect inclusi. Senza di esso un attaccante sulla stessa rete (un hotspot Wi-Fi pubblico, un router compromesso) può intercettare la prima richiesta e degradare la connessione a HTTP in chiaro prima che il redirect avvenga.

L'header si presenta così: Strict-Transport-Security: max-age=31536000; includeSubDomains. Il max-age è un anno, il minimo che Google raccomanda per l'idoneità all'HSTS preload. Aggiungi preload alla direttiva e invia il tuo dominio alla lista preload dei browser per proteggere gli utenti fin dalla primissima visita.

3. X-Frame-Options

Questo header impedisce che la tua pagina venga incorporata in un <iframe> su un altro sito. Senza di esso un attaccante può caricare la tua pagina di login invisibilmente dentro la sua pagina e sovrapporvi elementi dell'interfaccia falsi. L'utente crede di cliccare il tuo pulsante; sta cliccando quello dell'attaccante. Si chiama clickjacking.

La correzione è una sola riga: X-Frame-Options: DENY (oppure SAMEORIGIN se incorpori le tue stesse pagine). La direttiva CSP frame-ancestors è l'equivalente moderno e ha la precedenza su X-Frame-Options quando entrambi sono presenti.

4. X-Content-Type-Options

I browser provano a essere utili indovinando il tipo di una risorsa quando il server non lo dichiara chiaramente. Si chiama MIME sniffing ed è un problema di sicurezza: un caricamento di immagini che in realtà è uno script può essere eseguito se il browser decide che somiglia a JavaScript.

X-Content-Type-Options: nosniff disattiva completamente questo indovinare. È l'header più semplice della lista: una riga, nessuna configurazione, nessun effetto collaterale.

5. Referrer-Policy

Quando un utente clicca un link dal tuo sito verso un altro, il browser invia un header Referer contenente l'URL della pagina di provenienza. Se i tuoi URL contengono dati sensibili (un token di reset della password, un identificatore di sessione, un riferimento d'ordine), quei dati finiscono al sito di destinazione.

Referrer-Policy: strict-origin-when-cross-origin è il valore predefinito sicuro: invia l'origine (il tuo nome di dominio, senza percorso) ai siti esterni e l'URL completo al tuo stesso dominio. L'opzione più riservata è no-referrer, ma rompe alcune integrazioni di analytics.

Come controllare il tuo sito

Il modo più rapido è aprire gli strumenti per sviluppatori del browser (F12), caricare la homepage, andare nella scheda Network, cliccare la prima richiesta e guardare la sezione Response Headers. Oppure usa Noroshi: crea un account gratuito, aggiungi il tuo dominio, e lo scanner controlla tutti e cinque gli header, li valuta e spiega esattamente cosa aggiungere e dove.

Dove impostarli

I security header si impostano sul web server, non nel tuo CMS. Dove esattamente dipende dal tuo setup di hosting:

Apache: nel file .htaccess o in httpd.conf con direttive Header always set. Il modulo mod_headers deve essere attivato.
Nginx: nel blocco server con direttive add_header. Mettile nel blocco server o location che gestisce il tuo sito.
Caddy: nel Caddyfile con la direttiva header. Caddy imposta X-Content-Type-Options: nosniff automaticamente; gli altri vanno aggiunti a mano.
Cloudflare o un altro proxy: alcuni proxy permettono di aggiungere header di risposta dal loro pannello (Cloudflare: Transform Rules, Modify Response Header). È l'opzione più semplice se non puoi toccare la configurazione del server.
WordPress: plugin come Wordfence, Headers Security Advanced e HSTS Preload impostano gli header senza richiedere accesso al server. È una via di fuga ragionevole se il tuo hosting provider controlla la configurazione del server.

Cosa aspettarti dal punteggio

Aggiungere tutti e cinque gli header porta tipicamente un punteggio di sicurezza Noroshi dalla fascia 40-60 alla fascia 70-80 in una sola sessione. Non sono l'unica cosa che conta (configurazione TLS, DNS, porte aperte e file esposti entrano tutti nel punteggio), ma sono la correzione con il miglior rapporto sforzo-beneficio disponibile per la maggior parte dei siti web.

Un sito ben configurato non attira l'attenzione. Scanner automatizzati sonda milioni di siti al giorno alla ricerca di header mancanti, porte aperte e vulnerabilità software note. Un sito che invia gli header giusti viene scartato più in fretta e preso di mira meno. Non è sicurezza tramite oscuramento: è rendere indisponibili le vittorie facili.

L'angolo del monitoraggio continuo

Gli header possono regredire. Un aggiornamento del CMS, un nuovo plugin, una migrazione del server o una modifica di configurazione del tuo hosting provider possono rimuovere silenziosamente un header che c'era ieri. Lo scanner Noroshi controlla tutti e cinque gli header a ogni scansione e ti avvisa nel momento in cui uno scompare, così che una finestra di manutenzione non diventi, senza volerlo, una finestra di sicurezza.

Crea un account gratuito, aggiungi il tuo dominio e vedi il tuo punteggio attuale degli header in pochi minuti. Piano gratuito, senza carta di credito.

← Torna al blog

Scritto da David Hildering, l'ingegnere dietro Noroshi. Di più su Noroshi.