Quando apriamo un sito web, pensiamo normalmente a ciò che vediamo nella pagina: testi, immagini, pulsanti e funzionalità.
Ma una parte importante della comunicazione tra browser e server avviene dietro le quinte, attraverso gli HTTP response headers.
Alcuni di questi header possono fornire al browser istruzioni aggiuntive su come comportarsi con i contenuti ricevuti e possono contribuire a ridurre alcune classi di attacchi.
Sono i cosiddetti security headers.
Cosa sono gli HTTP security headers?
Ogni volta che visitiamo una pagina web, il server restituisce una risposta HTTP.
Ad esempio:
HTTP/2 200
Content-Type: text/html
Content-Length: 18452
Oltre alle informazioni necessarie per gestire la risposta, il server può includere header dedicati alla sicurezza:
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Il browser legge questi valori e, quando supportati, li utilizza per applicare determinate regole.
Gli header di sicurezza non sostituiscono autenticazione, autorizzazione, aggiornamenti del software o una corretta configurazione dell'applicazione. Sono però uno degli elementi che possono contribuire alla sicurezza complessiva di un sito.
Quali security headers bisogna controllare?
Non esiste una lista universale in cui ogni sito debba necessariamente avere gli stessi header.
La configurazione dipende dal tipo di applicazione, dalle funzionalità utilizzate e dalle risorse che il sito deve caricare.
Alcuni header sono però particolarmente importanti da conoscere.
Strict-Transport-Security
L'header HSTS, o HTTP Strict Transport Security, comunica al browser che il sito deve essere raggiunto tramite HTTPS per un determinato periodo.
Un esempio è:
Strict-Transport-Security: max-age=31536000
In una configurazione reale possono essere presenti anche direttive aggiuntive, come includeSubDomains.
HSTS è particolarmente utile quando un sito deve essere utilizzato esclusivamente tramite HTTPS.
X-Content-Type-Options
Un'altra impostazione comune è:
X-Content-Type-Options: nosniff
Serve a impedire che il browser tenti di interpretare una risorsa con un tipo diverso da quello dichiarato dal server in determinate situazioni.
È un'impostazione semplice, ma utile per ridurre comportamenti indesiderati legati al MIME sniffing.
Content-Security-Policy
La Content-Security-Policy, abbreviata CSP, è molto più articolata.
Un esempio semplificato potrebbe essere:
Content-Security-Policy: default-src 'self'
La CSP permette di definire quali origini possono essere utilizzate per script, immagini, fogli di stile, font e altre risorse.
Una configurazione CSP troppo restrittiva può però rompere funzionalità perfettamente legittime.
Per questo non è una buona idea copiare una policy trovata online e applicarla senza verificare prima come funziona l'applicazione.
Referrer-Policy
Questo header controlla quali informazioni sul referrer possono essere trasmesse quando l'utente segue un collegamento.
Un'impostazione comune è:
Referrer-Policy: strict-origin-when-cross-origin
L'obiettivo è limitare la quantità di informazioni condivise quando una richiesta viene effettuata verso un'altra origine.
Un header mancante significa automaticamente "vulnerabilità"?
No.
Questo è un punto importante quando si parla di security scanning.
La presenza o assenza di un header deve essere interpretata nel contesto dell'applicazione.
Ad esempio, un header mancante può rappresentare:
- una configurazione migliorabile;
- una raccomandazione di hardening;
- una condizione potenzialmente rilevante;
- oppure, in determinati casi, un problema di sicurezza concreto.
Non sono necessariamente la stessa cosa.
Per questo un report di sicurezza dovrebbe distinguere tra vulnerabilità, misconfiguration, informazione e raccomandazione.
Come controllare gli header di un sito
Un controllo molto semplice può essere effettuato anche da terminale:
curl -I https://example.com
Il risultato mostrerà gli header restituiti dal server.
Ad esempio:
HTTP/2 200
content-type: text/html
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
Naturalmente, controllare gli header di una singola risposta non significa aver verificato l'intera applicazione.
Potrebbero infatti esistere configurazioni differenti per:
/
/login
/api/
/admin/
/static/
oppure per risposte con status code diversi.
Perché controllarli dall'esterno?
Dal punto di vista della sicurezza web, quello che conta non è soltanto ciò che è configurato sul server, ma ciò che viene effettivamente esposto all'esterno.
Una configurazione apparentemente corretta può produrre infatti una risposta diversa da quella prevista a causa di:
- reverse proxy;
- CDN;
- web server;
- framework;
- configurazioni per singolo virtual host;
- applicazioni diverse sullo stesso dominio.
Per questo l'analisi esterna può essere utile per verificare il comportamento effettivamente osservabile.
Una piccola checklist
Quando controlli un'applicazione web, puoi partire da questi punti:
- [ ] il sito utilizza HTTPS;
- [ ] HSTS è configurato quando appropriato;
- [ ]
X-Content-Type-Optionsè presente; - [ ]
Referrer-Policyè configurato; - [ ] esiste una Content Security Policy quando appropriata;
- [ ] gli header sono coerenti tra le diverse sezioni dell'applicazione;
- [ ] non vengono utilizzate configurazioni obsolete o inutilmente permissive;
- [ ] eventuali problemi vengono valutati nel contesto dell'applicazione.
Security headers e MiHakero
I security headers sono un buon esempio di controllo che, preso da solo, può sembrare banale.
In realtà fa parte di un quadro più ampio: capire come appare un'applicazione dall'esterno e quali configurazioni possono essere migliorate.
MiHakero analizza proprio questo tipo di superficie, mettendo insieme informazioni diverse per aiutarti a capire cosa merita attenzione e cosa invece rappresenta semplicemente un'opportunità di hardening.
La sicurezza di un sito non dipende da un singolo header, ma da un insieme di configurazioni e controlli che devono funzionare correttamente.