Home Blogs Utilizzo di EdgeJS di Layer0 per configurare intestazioni di protezione personalizzate
Applications

Utilizzo di EdgeJS di Layer0 per configurare intestazioni di protezione personalizzate

About The Author

Outline

L’implementazione delle intestazioni di sicurezza è diventata estremamente importante poiché 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, ecc.

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 sicurezza.

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 descrive le seguenti importanti intestazioni di sicurezza:

  • Criteri di sicurezza dei contenuti (CSP)
  • X-Content-Type-Options
  • Opzioni fotogramma X.
  • Politica sulle risorse cross-origin (Corp)
  • Policy di ricovero cross-origin (COEP)
  • Policy Opener Cross-Origin (COOP)
  • Politica di riferimento
  • Permessi-criterio
  • HSTS (Strict Transport Security) HTTP

L’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 Content Security Policy (CSP) e solo il 0,2% dei siti implementa solo CSP-Report.

Scioccante, giusto?! La mancanza di CSP HTTP Header elimina i meccanismi di difesa contro 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 di una mancanza di sicurezza sul lato client, nomi, indirizzi, indirizzi e-mail, numeri di carte di credito, sono state esposte le date di scadenza e i codici di sicurezza della carta di 380.000 clienti, che non sono stati rilevati per 15 giorni.

Aggiunta della sicurezza con EdgeJS di Layer0

Con la piattaforma di distribuzione di Layer0, elementi come TLS vengono configurati automaticamente per ogni collegamento di distribuzione, in modo che gli sviluppatori possano spedire in modo sicuro per impostazione predefinita. In questo blog, esaminiamo attentamente importanti intestazioni di sicurezza e un esempio per mostrare quanto velocemente è possibile proteggere un sito Web con la configurazione dei percorsi su Layer0.

Guida introduttiva alle intestazioni di sicurezza con Edgio

Criteri di 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 gli attacchi XSS (Cross-Site Scripting) limitando il caricamento (ed esecuzione) di script, stili, immagini, font e supporti da origini specifiche consentite. Indipendentemente dalla sicurezza del backend, se gli utenti malintenzionati possono attaccare il codice eseguito nel browser anziché sul 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 di carte di credito e rimase attiva per 5 mesi prima di essere catturata! Il tutto semplicemente iniettando 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:; ‘src ‘font-src; ‘no-src; ‘.gstatic.com; ‘font; ‘rc’; ‘ New router() .get(“/:Route”, ({ setResponseHeader }) => { setResponseHeader(“Content-Security-Policy”, ContentSecurityPolicy.replace(/\n/g, “”) })

Content-Security-Policy offre la possibilità di:

  1. Superare gli attacchi XSS (Cross Site Scripting)
  2. Evitare il clickjack
  3. Segnalare violazioni alle regole CSP

X-Content-Type-Options

In che modo la configurazione di X-Content-Type-Options impedisce lo sniffing di 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 fotogramma X.

Intestazione X-Frame-Options

L’intestazione X-Frame-Options indica se a un browser deve essere consentito di eseguire il rendering di una pagina in una cornice, iframe, incorporare o tag oggetto da evitare attacchi click-jacking . Se impostato su NEGA o SAMEORIGIN, il contenuto non viene incorporato in altri siti o solo 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:

  1. Prevenire gli attacchi di clickjacking
  2. Indicare se a un browser deve essere consentito o meno di eseguire il rendering di una pagina in <telaio>, <iframe>, <incorporare> oppure <oggetto>

Politica sulle risorse cross-origin (Corp)

CORP consente ai server di proteggersi da determinate integrazioni tra origine o tra 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 con consenso esplicito che può proteggere qualsiasi risorsa; non è necessario che i browser eseguano analisi dei tipi MIME. – MDN Docs

Policy di ricovero cross-origin (COEP)

L’intestazione COEP impedisce il caricamento di risorse cross-origin per le quali non è stata concessa l’autorizzazione (tramite CORS o Corp). 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”) })

Policy Opener Cross-Origin (COOP)

L’applicazione dell’intestazione COOP assicura che il gruppo di contesto di esplorazione 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 incrociata come OAuth e pagamento, «SAME-Origin-allow-popup» mira 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 politica di riferimento controlla la quantità di queste informazioni che saranno disponibili per la destinazione. Per tutte le direttive della politica di riferimento, fare riferimento alla politica di riferimento — HTTP | MDN (mozilla.org).

Const { router } = require(“@layer0/core/router”) module.exports= New router() .get(“/”, ({ setResponseHeader }) = { setResponseHeader> (“Referrer-Policy”, “origin-when-cross-origin”) })

Criterio autorizzazioni

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 della politica di riferimento, 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=(), Microphone=(), geolocation=()” ); })

HSTS (Strict Transport Security) HTTP

Intestazione HST Strict Transport Security

HTTP Strict-Transport-Security (HSTS) informa i browser di caricare il sito Web utilizzando solo 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 offrono la possibilità di:

  1. Protezione dagli attacchi HTTP downgrade (attacchi SSL stripping)
  2. 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 protezione 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-headers-example
Rapporto: Collegamento al rapporto intestazioni di sicurezza

Discussione

Aggiungete le intestazioni di sicurezza pertinenti per proteggere la vostra applicazione Web. Con Layer0 puoi fare ancora di più: Segreti, avvelenamento della cache e abilitazione dell’autenticazione di base in Edgio Documentation — Security.