Header di sicurezza HTTP: CSP e HSTS

Hai distribuito l'applicazione. Le pagine vengono caricate, i moduli funzionano e nulla sembra rotto. Quindi esegui una scansione e ritorna con un elenco di risultati relativi intestazioni - e niente di tutto ciò è ovvio.

Questa è una prima reazione normale. Le intestazioni non vengono visualizzate sullo schermo, quindi è difficile dire se contano o se lo scanner è solo pignolo. Questa guida esamina le intestazioni che vedrai più spesso, cosa fa effettivamente ciascuna in un linguaggio semplice e come controllare le tue senza congetture.

Le intestazioni di sicurezza sono istruzioni che il tuo server invia al browser insieme alla pagina. Il browser li legge e regola il modo in cui gestisce i tuoi contenuti: quali script possono essere eseguiti, se la pagina può essere caricata su un semplice HTTP, se un altro sito può incorporarla in un frame.

Non cambia nulla nella pagina. Questo è esattamente il motivo per cui questi risultati sembrano astratti: il sito può apparire e comportarsi perfettamente pur mancando una serie di protezioni che sarebbero importanti il ​​giorno in cui qualcosa andasse storto.

La definizione onesta è questa: le intestazioni riducono una specifica classe di rischio. Non rendono sicuro un sito da soli e un controllo pulito dell'intestazione non dimostra che un sito sia completamente sicuro. Considerali come uno strato tra tanti e uno dei livelli più economici da ottenere correttamente.

Quando un browser richiede una pagina, il tuo server risponde con la pagina e un blocco di metadati chiamato intestazioni di risposta. Puoi vederli tu stesso: apri gli strumenti per sviluppatori del tuo browser, vai alla scheda Rete, ricarica la pagina e fai clic sulla richiesta principale. Le intestazioni sono proprio lì.

Le intestazioni di sicurezza sono semplicemente quelle che dicono al browser di applicare una regola. Alcuni sono rigidi, altri sono consultivi e tutti sono impostati nella configurazione del server, nel framework o nella piattaforma di hosting, non nel codice HTML.

CSP indica al browser quali fonti di contenuto possono essere caricate sulla tua pagina. È l'intestazione più potente qui e quella che le persone trovano più intimidatoria.

In pratica, uno CSP spiega cose come: gli script possono provenire solo dal tuo dominio e da un CDN affidabile; le immagini possono provenire da qualsiasi luogo tramite HTTPS; la pagina non può essere inserita nel frame di un altro sito. Se qualcosa tenta di caricarsi da una fonte che non hai consentito, il browser lo blocca e registra il tentativo nella console.

CSP costituisce un'ulteriore difesa contro l'iniezione di script, oltre alla codifica e alla sanitizzazione sicura dell'output. È anche l'intestazione che ha maggiori probabilità di rompere qualcosa se la imposti in modo troppo aggressivo. Il percorso pratico per un principiante è iniziare in modalità solo report, osservare cosa sarebbe stato bloccato, risolvere i problemi reali e quindi applicarli.

HSTS dice al browser di comunicare con il tuo sito solo tramite HTTPS, per un periodo definito. Una volta che un browser ha visto questa intestazione, si rifiuterà di stabilire una connessione HTTP non sicura al tuo dominio, anche se un utente digita http:// o segue un vecchio collegamento.

Una volta che il browser riconosce la policy HSTS, aggiorna le richieste HTTP prima di inviarle. La prima visita può comunque utilizzare HTTP a meno che il dominio non sia già coperto da una voce di precaricamento HSTS.

L’unica cosa da rispettare qui è l’impegno. HSTS viene ricordato dal browser per tutto il tempo specificato, quindi inizia con una durata breve mentre confermi che ogni sottodominio funziona su HTTPS, quindi allungala una volta che sei sicuro.

X-Frame-Options controlla se un altro sito può caricare le tue pagine all'interno di un frame - an <iframe> sulla pagina di qualcun altro.

Perché preoccuparsi? Perché il framing è il meccanismo alla base del clickjacking, in cui un utente malintenzionato sovrappone alla tua pagina reale elementi invisibili o mascherati in modo che un utente faccia clic su qualcosa che non intendeva fare. Se la tua app presenta un'azione registrata (un pulsante di eliminazione, un pagamento, una modifica delle impostazioni), inquadrarla altrove è un rischio che non vuoi.

L'impostazione comune è SAMEORIGIN, che consente alle tue pagine di inquadrarsi a vicenda ma blocca tutte le altre. Se non hai mai intenzione di essere incastrato, di solito è l'impostazione predefinita giusta.

Referrer-Policy decide quanto del tuo URL viene condiviso con altri siti quando un utente fa clic su un collegamento fuori dalla tua pagina. I browser moderni normalmente utilizzano strict-origin-when-cross-origin: l'URL completo può essere inviato su richieste della stessa origine, mentre le richieste HTTPS multiorigine ricevono solo l'origine. Una politica esplicitamente più debole può rivelare di più.

Ciò è importante perché gli URL completi a volte contengono valori sensibili nelle stringhe di query: token, ID, indirizzi e-mail, termini di ricerca. Trasmetterli a terzi è un'operazione silenziosa ed è facile non notarli.

Una linea di base sensata è inviare solo l'origine, o niente, sulle richieste intersito. Non ti costa quasi nulla ed elimina una perdita accidentale di dati.

Qualche intestazione in più viene visualizzata abbastanza spesso da sapere per nome:

• X-Content-Type-Options: nosniff impedisce al browser di indovinare il tipo di file, che altrimenti potrebbe trasformare un file caricato in uno script eseguibile.

• Permissions-Policy disattiva le funzionalità del browser che non utilizzi, come fotocamera, microfono o geolocalizzazione.

• Cross-Origin-Opener-Policy e le relative intestazioni multiorigine isolano la tua pagina dalle altre, il che aiuta a contenere determinati attacchi.

Non ti servono tutti il primo giorno. Sapere cosa fanno ti aiuta a leggere un rapporto di scansione senza farti prendere dal panico.

Hai due modi per guardare.

Innanzitutto, il percorso manuale: strumenti per sviluppatori, scheda Rete, fai clic sulla richiesta della pagina e leggi le intestazioni di risposta. Ciò è utile per confermare che è presente una singola intestazione e impostarla nel modo previsto.

In secondo luogo, il percorso pratico per più di una pagina: eseguire una scansione. Uno scanner recupera il tuo sito come farebbe un browser e segnala quali intestazioni di sicurezza sono presenti, quali mancano e cosa espone ciascuna lacuna. Questo ti dà un elenco con priorità invece di un muro di testo grezzo e controlla le pagine che non avresti pensato di aprire manualmente.

Uno strumento generico come la scansione di sicurezza leggera e gratuita di VICE contrassegnerà i risultati dell'intestazione insieme ad altri problemi, con le prove dietro ciascuno in modo da poter capire perché è stato sollevato.

Le intestazioni risiedono nella configurazione, quindi la maggior parte delle correzioni sono piccole: aggiungi una riga alla configurazione del tuo server, un'impostazione nel tuo framework o un'opzione nella dashboard del tuo host. Modifica un'intestazione alla volta e conferma che il sito funziona ancora.

Quindi ripetere la scansione. Questo è il passaggio che le persone saltano. Modificare una configurazione non significa che ora l'intestazione sia corretta su ogni pagina e contrassegnare qualcosa come corretto in una dashboard non equivale a confermarlo. Solo una nuova scansione nello stesso ambito ti dice che la modifica ha effettivamente avuto effetto.

Inizia con una scansione gratuita, guarda cosa stanno realmente facendo le tue intestazioni e correggi i risultati principali uno alla volta. Si tratta di un primo passo ragionevole e di una posizione molto migliore rispetto alla speranza che le impostazioni predefinite andassero bene.