L’implementazione delle intestazioni di sicurezza è diventata estremamente importante in quanto il numero di violazioni e furti di dati aumenta rapidamente ogni giorno. Le intestazioni di sicurezza offrono una parte della soluzione facile da implementare: È sufficiente passare intestazioni HTTP specifiche per proteggere il sito Web da attacchi comuni come XSS, code injection, clickjacking e così via
Cosa sono le intestazioni di sicurezza?
Le applicazioni Web possono inviare comandi speciali al browser per proteggere i siti Web da violazioni o vulnerabilità lato client, note come intestazioni di protezione.
Quando un utente visita un sito Web nel proprio browser, il server risponde con le intestazioni di risposta HTTP. Queste intestazioni, composte da metadati, condividono le informazioni con il client e il server. Queste informazioni condivise definiscono il modo in cui i browser devono interagire con il sito Web. Le intestazioni di sicurezza forniscono una protezione efficace da varie vulnerabilità e minacce delle app Web.
Questo blog suddividerà le seguenti importanti intestazioni di sicurezza:
- Policy sulla sicurezza dei contenuti (CSP)
- X-Content-Type-Options
- Opzioni x-Frame
- Policy sulle risorse di origine incrociata (Corp)
- COEP (Cross-Origin Embedder Policy)
- Criterio di apertura Cross-Origin (COOP)
- Referrer-Policy
- Criteri di autorizzazione
- HSTS (HTTP Strict Transport Security)
Importanza delle intestazioni di sicurezza
Le intestazioni di sicurezza HTTP sono una parte fondamentale della sicurezza dei siti Web; tuttavia, solo il 1,6% dei primi milioni di siti Web ha implementato la politica di sicurezza dei contenuti (CSP) e solo lo 0,2% dei siti implementa la sola CSP-Report-Only.
Scioccante, giusto?! La mancanza di intestazione HTTP CSP riduce i meccanismi di difesa contro gli attacchi XSS (Cross-Site Scripting) e altri attacchi di tipo client-side injection. La violazione dei dati di British Airways è uno degli incidenti che illustra come a causa della mancanza di sicurezza sul lato client, i nomi, gli indirizzi, gli indirizzi e-mail, i numeri di carta di credito, le date di scadenza e i codici di sicurezza della carta di 380.000 clienti siano stati esposti, che sono rimasti inosservati per 15 giorni.
Aggiunta di sicurezza con EdgeJS di Layer0
Con la piattaforma di distribuzione di Layer0, elementi come TLS vengono configurati automaticamente per ogni link di distribuzione, in modo che gli sviluppatori possano fornire in modo sicuro per impostazione predefinita. In questo blog, esaminiamo attentamente importanti intestazioni di sicurezza e un esempio per mostrare quanto rapidamente è possibile proteggere un sito Web con la configurazione dei percorsi su Layer0.
Guida introduttiva alle intestazioni di sicurezza con Edgio
Policy sulla sicurezza dei contenuti (CSP)
In che modo CSP impedisce il caricamento delle risorse da origini non consentite
Content-Security-Policy fornisce un livello aggiuntivo per impedire attacchi XSS (Cross-Site Scripting) limitando il caricamento (ed esecuzione) di script, stili, immagini, font e supporti da specifiche origini consentite. Indipendentemente dalla sicurezza del back-end, se gli utenti malintenzionati possono attaccare il codice in esecuzione nel browser anziché nel server, i dati della sessione utente vengono compromessi e le informazioni riservate vengono esposte. Uno dei tanti esempi (come la British Airways Data Breach) è l’attacco MageCart al modulo di pagamento di Ticketmaster. La violazione di Ticketmaster ha causato 40.000 vittime di furto con carta di credito e ha continuato ad essere attiva per 5 mesi prima di essere catturata! Il tutto semplicemente inserendo uno script di skimming del modulo all’interno del browser.
Const { router } = require(‘@layer0/core/router’) const ContentSecurityPolicy = “default-src ‘self’; script-src ‘self’ ‘unsafe-eval”unsafe-inline’ *.layer0.co; style-src ‘self”unsafe-inline’ *.googleapis.com; img-src * blob: Data:; media-src-src-src .gstatic.com; * src-src-src; New router() .get(“/:Route”, ({ setResponseHeader }) => { setResponseHeader(“Content-Security-Policy”, ContentSecurityPolicy.replace(/\n/g, “”)) })
Content-Security-Policy consente di:
- Superare gli attacchi XSS (Cross Site Scripting)
- Evitare il clickjacking
- Segnalare violazioni alle regole CSP
X-Content-Type-Options
Come la configurazione di X-Content-Type-Options impedisce lo sniffing del tipo MIME
L’intestazione X-Content-Type-Options indica che i tipi MIME (Multipurpose Internet mail Extensions, un identificatore per i formati di file) specificati nelle intestazioni Content-Type devono essere rigorosamente seguiti. Con MIME Type Sniffing, operazioni come il caricamento delle immagini possono eseguire eseguibili dannosi, dove entra in gioco l’intestazione X-Content-Type-Options.
Const { router } = require(‘@layer0/core/router’) New router() .get(“/:Route”, ({ setResponseHeader }) => { setResponseHeader(“X-Content-Type-Options”, “nosniff”) })
Opzioni x-Frame
Intestazione X-Frame-Options
L’intestazione X-Frame-Options indica se un browser deve essere autorizzato a eseguire il rendering di una pagina in tag fotogramma, iframe, incorporati o oggetto da evitare Attacchi di click-jacking. Se impostato su NEGA o SAMEORIGIN assicura che il loro contenuto non sia incorporato in altri siti o solo incorporato in siti con la stessa origine, rispettivamente.
Const { router } = require(‘@layer0/core/router’) New router() .get(“/:Route”, ({ setResponseHeader }) => { setResponseHeader(“X-Frame-Options”, “SAMEORIGIN”) })
X-Frame-Options consente di:
- Prevenire gli attacchi di clickjacking
- Indicare se un browser deve essere autorizzato o meno a eseguire il rendering di una pagina in un <telaio>, <iframe>, <incorpora> oppure <oggetto>
Policy sulle risorse di origine incrociata (Corp)
CORP consente ai server di proteggersi da determinate incorporazioni tra origini o siti della risorsa richiesta (ad esempio, risposte API). Previene anche attacchi speculativi side-channel come Spectre.
Const { router } = require(‘@layer0/core/router’) New router() .get(“/:Route”, ({ setResponseHeader }) => { setResponseHeader(“Cross-origin-Resource-Policy”, “same-origin”) })
Cross-Origin Resource Policy è un’intestazione di risposta opt-in che può proteggere qualsiasi risorsa; non è necessario che i browser individuino i tipi MIME. – Documenti MDN
COEP (Cross-Origin Embedder Policy)
L’intestazione COEP impedisce il caricamento delle risorse di origine incrociata per le quali non è stata concessa l’autorizzazione (tramite cors o corr ). Utilizzare «require-corp» per applicare l’intestazione, mentre «unsafe-none» per consentire il recupero di documenti di origine incrociata.
Const { router } = require(‘@layer0/core/router’) New router() .get(“/:Route”, ({ setResponseHeader }) => { setResponseHeader(“Cross-Origin-Embedder-Policy”, “require-corp”) })
Criterio di apertura Cross-Origin (COOP)
L’applicazione dell’intestazione COOP assicura che il gruppo di contesto di navigazione di un documento di livello superiore non sia condiviso tra documenti di origine incrociata. Mentre «stessa origine» rompe le integrazioni che richiedono interazioni tra finestre di origine diverse, come OAuth e pagamento, i popup «stessa origine» mirano a condividere il contesto solo con i popup del SAMEORIGIN.
Const { router } = require(‘@layer0/core/router’) New router() .get(“/:Route”, ({ setResponseHeader }) => { setResponseHeader(“Cross-origin-Opener-Policy”, “same-origin-allow-popup”) })
Politica di riferimento
Quando un utente naviga (facendo clic su un collegamento) da un sito (l’origine) a un altro (la destinazione), quest’ultimo riceve informazioni sull’origine da cui proviene l’utente. L’intestazione «Referrer-Policy» controlla la quantità di tali informazioni che devono essere disponibili per la destinazione. Per tutte le direttive di Referrer-Policy, fare riferimento a Referrer-Policy — HTTP | MDN (mozilla.org).
Const { router } = require(“@layer0/core/router”) module.exports= New router() .get(“/”, ({ setResponseHeader }) => { setResponseHeader(“Referrer-Policy”, “origin-when-cross-origin”) })
Criteri di autorizzazione
Intestazione HTTP sperimentale che consente di consentire/negare le funzioni del browser nei propri frame e in qualsiasi iframe del documento. Per tutte le direttive di Referrer-Policy, fare riferimento a Feature-Policy — HTTP | MDN (mozilla.org)
Const { router } = require(“@layer0/core/router”) module.exports= New router() .get(“/”, ({ setResponseHeader }) => { setResponseHeader( “Permissions-Policy”, “camera=(), microfono=(), geolocation=()” ); })
HSTS (HTTP Strict Transport Security)
Intestazione di sicurezza del trasporto rigoroso HST
HTTP Strict-Transport-Security (HSTS) informa i browser di caricare il sito Web solo utilizzando HTTPS, invece di utilizzare il protocollo HTTP.
Const { router } = require(‘@layer0/core/router’) New router() .get(“/:Route”, ({ setResponseHeader }) => { setResponseHeader(“Strict-Transport-Security”, “max-age=31536000; includeSubDomains”) })
GLI HST consentono di:
- Protezione dagli attacchi di downgrade HTTP (attacchi di stripping SSL)
- Per impostazione predefinita, la difesa dei contenuti misti passa a HTTPS
Un esempio
Con Layer0, è più facile che mai implementare le intestazioni di sicurezza. Utilizzando EdgeJS di Layer0, è possibile aggiungere intestazioni di sicurezza a qualsiasi sito Web, indipendentemente dal framework utilizzato. Quanto segue cerca di implementare le intestazioni di sicurezza pertinenti in un sito web creato con Sapper tramite Layer0.
Esempio: https://rishi-raj-jain-security-headers-example-default.layer0-limelight.link
GitHub: rishi-raj-jain/Security-header-example
Report: Collegamento report intestazioni di sicurezza
Discussione
Aggiungete le intestazioni di sicurezza pertinenti per proteggere la vostra applicazione Web. Con Layer0 è possibile fare ancora di più, segreti, avvelenamento della cache e abilitare l’autenticazione di base in Edgio Documentation — Security.