Oggi parliamo di Content Security Policy mostrando una lista di esempi di configurazione per implementarle. Vediamo quali argomenti andremo a trattare. Le Content Security Policy (CSP) sono un meccanismo di sicurezza che consente di specificare quali risorse possono essere utilizzate dal browser quando si visualizza una pagina web. Insieme ai CORS cono un utile strumento di protezione per il nostro sito web.
Indice dei contenuti
- Cosa sono le Content Security Policy?
- Perche sono importanti le CSP?
- Whitelist domini affidabili
- Come si configurano le Content Security Policy
- Quali risorse possiamo proteggere?
- Content Security Policy esempi di configurazione
- Come testare le direttive Content Security Policy
- Contributo video
- Conclusioni
Let’s go!
Cosa sono le Content Security Policy?
Le CSP forniscono un meccanismo che indica al browser quali fonti sono attendibili, e accettate dal browser, tenendosi così alla larga dall’utilizzo di contenuti pericolosi, quali ad esempio script dannosi o immagini contenenti malware.
Abbiamo già parlato di CSP nell’articolo dedicato agli al dns-prefetch , preload, preconnet e prerender.
Le CSP sono implementate tramite un header HTTP di risposta (response header), chiamato “Content-Security-Policy“, che può essere impostato dal server o dall’applicazione. Il valore di questo header specifica quali fonti sono attendibili per la pagina web che stiamo navigando, come ad esempio solo script e immagini provenienti dallo stesso dominio, o da uno o più domini specifici.
Possiamo considerare le CSP come un meccanismo molto utile per la sicurezza delle applicazioni web, in quanto consentono di prevenire attacchi come XSS (Cross-Site Scripting) che iniettano codice maligno nelle pagine web visitate dagli utenti. Tuttavia, la corretta configurazione di una CSP richiede una certa conoscenza e può essere complessa da implementare, sopratutto se l’applicazione utilizza molti contenuti provenienti da fonti esterni.
Perche sono importanti le CSP?
Quando il tuo browser carica una pagina web, insieme ad essa, e su indicazione della pagina stessa, carica una serie di altre risorse. Tra queste risorse ci sono fogli di stile (css) e caratteri (fonts), oltre ai files javascript e alle immagini.
Alcune di queste risorse sono caricate da domini esterni. Per fare qualche esempio troviamo Google Analytics, oppure un video da YouTube, oppure le utility di gestione dei Cookies. Il tuo browser carica queste risorse perché nel codice sorgente della pagina richiamata è specificato di farlo. Il browser però, non ha modo di sapere se sia corretto o meno caricare questi files. Tantomeno è al corrente se questi files possano essere dannosi.
Un ulteriore esempio è rappresentato da un utente malintenzionato che potrebbe aver inserito un commento, adeguatamente formattato, con l’obiettivo di caricare un javascript dannoso da un dominio esterno. Ovviamente il javascript, visto che è inserito all’interno del sorgente della pagina, verrà caricato dal tuo browser che, come detto, non ha modo di sapere che il contenuto che sta per scaricare è dannoso o no. Ed è qui che entrano in gioco le Content Security Policy, filtrando le risorse secondo le indicazioni che lo sviluppatore della pagina web ha dato.
Whitelist domini affidabili
Un’intestazione CSP ti consente di definire (da parte di chi gestisce o sviluppa il sito) le fonti affidabili e approvate, che il browser può caricare. Grazie alle CSP potrai specificare solo quelle fonti da cui desideri che il browser carichi i contenuti. Questo ci permette di proteggere i nostri visitatori da tutta una serie di problemi. Vediamo un primo esempio di intestazione CSP:
Content-Security-Policy: script-src 'self'Torniamo all’esempio precedente di un utente malintenzionato che utilizza un commento, appositamente predisposto per caricare javascript da un dominio esterno al nostro. Questa intestazione CSP fa proprio questo, ovvero impedisce al browser di caricare il contenuto di tipo SCRIPT da siti esterni. La direttiva script-src infatti specifica la whitelist delle fonti da cui il browser può caricare gli script.
Usare la parola chiave ‘self’ è più facile che specificare l’intero dominio e rende la politica un po’ più facile da leggere una volta che la lista delle direttive CSP inizia a crescere. Questa direttiva però, farà si che eventuali script, per esempio di Google Analytics, non verranno caricati. Questo perchè il dominio https://*.google-analytics.com non è nella whitelist degli script, il browser non caricherà quindi il suo contenuto.
Contenuto sponsorizzato
What is Effective Content Security Policy? Do we all define Content Security Policy in the same way? How to deal with Content Security Policy Changes? What vendors make products that address the Content Security Policy needs?
What other organizational variables, such as reward systems or communication systems, affect the performance of this CSP process? This extraordinary Content Security Policy self-assessment will make you the principal CSP domain master by revealing just what you need to know to be fluent and ready for any Content Security Policy challenge.
Compra Content Security Policy Complete Self-Assessment Guide (English Edition) su Amazon
Come si configurano le Content Security Policy?
Come al solito, prendiamo in considerazione Apache httpd come webserver.
Assicurati di avere il modulo mod_headers abilitato in Apache. Puoi verificarlo eseguendo il comando:
sudo apachectl -M e cercando headers_module nell’elenco dei moduli caricati. Se non è presente, puoi abilitarlo utilizzando il comando:
sudo a2enmod headersUna volta accertato che il mod_headers è attivo, possiamo iniziare a inserire le nostre configurazioni.
Le configurazioni possono essere inserite nel file di configurazione di Apache oppure nel file .htaccess
Il file di configurazione di solito si trova in /etc/apache2/sites-available/NOMEDELTUOSITO.conf, ma il suo posizionamento può variare a seconda del sistema operativo in uso.
Quali risorse possiamo proteggere?
Nell’ultimo esempio abbiamo visto che con la direttiva script-src possiamo scegliere i domini esterni dai quali caricare i file javascript. Ma possiamo filtrare molte altre tipologie di contenuto. Vediamo quali.
Nota importante per l’implementazione delle Content Security Policy.
Tutte le direttive che seguono fanno riferimento al dominio esterno che erogherà il contenuto. NON si riferiscono a un file specifico. Nelle direttive, andremo quindi a specifiche un FQDN (anche wildcard). Se per esempio vogliamo includere un video da Youtube, inseriremo in whitelist www.youtube.com, non il path dello specifico video che vogliamo incorporare.
script-src: Ne abbiamo già parlato e definisce quali script (es javascript) esterni possono essere caricati.
font-src: Definisce da dove il nostro sito può caricare i fonts (Utile per Google Fonts).
img-src: Definisce da dove possiamo caricare le immagini.
object-src: Definisce da dove il nostro sito può caricare i plugins.
frame-src: Definisce da dove il nostro sito può caricare gli iframes (Questo può risultare utile per alcuni prodotti pubblicitari o per i video incorporata di Youtube).
style-src: Definisce da dove il nostro sito può caricare i css.
media-src: Definisce da dove il nostro sito può caricare i contenuti di tipo media, come per esempio audio e video.
connect-src: Definisce da quali URI possiamo caricare le interfacce di script.
form-action: Definisce quali URI possono essere utilizzati come azione dalle form HTML.
script-nonce: Definisce l’esecuzione dello script richiedendo la presenza del nonce specificato negli elementi dello script
report-uri: Specifica un URI a cui il browser dell’utente invia rapporti sulla violazione dei criteri di protezione specificati dalle regole CSP.
Questi sono le direttive principali, quelle più utilizzate, ma ne esistono anche altre.
Content Security Policy esempi pratici di configurazione
Entriamo finalmente nel dettaglio delle configurazioni, mettendo le mani in pasta con alcuni esempi di Content Security Policy.
Quando configuriamo le Policy CSP, possiamo essere specifici, selezionando puntualmente le regole in modo che soddisfino esattamente i nostri requisiti. Oppure possiamo decidere di impostare regole più lasche, in modo che si possano perfezionare pian piano con il tempo.
Content Security Policy esempi base
Header set Content-Security-Policy "default-src 'self'; img-src 'self'; script-src 'self'"Questa è una configurazione CSP di base che consente solo script e immagini provenienti dallo stesso dominio (self) per il quale stiamo configurando le policy.
Content-Security-Policy: default-src httpsQuesta regola non mette alcun limite ai domini (FQDN) da cui le risorse posso essere prelevate, però richiede che qualunque risorsa sia erogata in HTTPS.
Content-Security-Policy: default-src https://iegri.com:443La regola accetta chiamate solo ed esclusivamente dal dominio iegri.com, specifica che il protocollo utilizzato sia https e la porta la 443. Al posto di 443 potremmo mettere un wildcard (*). Ciò significa accettare chiamate esterne, dal dominio iegri.com, in https, ma su qualunque porta.
I caratteri wildcard possono essere utilizzati solo per lo schema (http, https), la porta e la parte più a sinistra di un nome host (es. *.iegri.com).
Content-Security-Policy: script-src https://iegri.com https://google.comQuesta regola accetta il caricamento di script, come javascript, soltanto da iegri.com e da google.com
Content-Security-Policy: default-src https:; script-src https://iegri.com http://iegri.comCon questa regola accettiamo come default tutte le chiamate in https ma gli script possono essere richiamati solo da iegri.com, sia in https che in http.
Content Security Policy esempi avanzati
Finora abbiamo mostrato solo degli esempi molto semplici, ma con il passare del tempo e con il crescere dei contenuti del sito, le regole, sopratutto se si vogliono impostare molto restrittive, possono diventare lunghe e complesse. Ecco un esempio avanzato che potrebbe fare al caso vostro e che potrebbe tornare utile, quantomeno come spunto da cui partire.
Header set Content-Security-Policy default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://www.google.com https://tpc.googlesyndication.com https://www.gstatic.com https://www.google-analytics.com; connect-src 'self' https://www.google-analytics.com https://www.linkedin.com https://region1.google-analytics.com; img-src 'self' 'unsafe-inline' data: https://img.youtube.com https://pagead2.googlesyndication.com https://s.w.org https://www.google-analytics.com; frame-src 'self' https://www.google.com https://tpc.googlesyndication.com https://www.youtube.com; style-src 'self' 'unsafe-inline' https://www.gstatic.com https://fonts.googleapis.com; font-src 'self' 'unsafe-inline' data: https://fonts.gstatic.com; manifest-src https://iegri.com" Se avete letto bene l’articolo fino a questo punto, avrete capito che non servirà specificare nel dettaglio ogni singola voce. In questo esempio mi sono limitato a mettere insieme tutto quello che è stato spiegato finora. Quello che mi sento di consigliarvi è di analizzare i contenuti del vostro sito, tramite gli strumenti per gli sviluppatori. Aprite la sezione network e guardate quali sono le risorse che vi aspettate che vengano richiamate. Solo a questo punto, dopo aver aver messo a punto una prima configurazione, magari in un ambiente di test, andate a controllare la console, sempre negli strumenti per gli sviluppatori, e controllate che non ci siano errori. Qualora ci fossero ancora, adeguato<te le vostre policy, per sistemarli.
Altre opzioni oltre alla direttiva ‘self’
Abbiamo letto finora diverse volte la direttiva ‘self’ che significa, noi stessi, ovvero il nostro sito, quello su cui stiamo configurando le nostre regole di protezione. Vediamo quali sono le alternative.
‘none‘ blocca l’uso di usa risorsa.
‘self‘ solo noi stessi, escludendo i sottodomini.
‘unsafe-inline‘ accetta l’utilizzo di JS e CSS inline.
‘unsafe-eval‘ permette l’utilizzo di meccanismi di tipo eval().
Come testare le direttive Content Security Policy
Dopo aver creato le nostre policy, c’è una funzionalità moto utile che possiamo sfruttare per testarle. Invece di inviare l’intestazione Content-Security-Policy:, possiamo inviare Content-Security-Policy-Report-Only:. Ciò significa che il browser riceverà e agirà in base alla politica configurata, ma invece di applicarla, ti fornirà un feedback su quali sarebbero stati gli effetti della politica. Come detto in precedenza, sarebbe meglio eseguire i primi test in un ambiente di collaudo. Ma se non de disponete di uno, allora la direttiva Report Only, è una validissima alternativa.
Questo ci permette di testare le nostre policy senza rischiare di andare a bloccare accidentalmente e con brutti risultati, sia funzionali che visivi, il caricamento della nostra pagina.
Ma come capiamo se le policy CSP stanno bloccando qualche risorsa? Ci sono diversi modi per testare la configurazione della tua Content Security Policy (CSP).
- Utilizzando gli strumenti di sviluppo del browser: la maggior parte dei browser moderni, come Chrome, Firefox, e Safari, includono gli strumenti di sviluppo che mostrano gli errori CSP. Apri gli strumenti di sviluppo e vai alla scheda “Console” per vedere eventuali violazioni della CSP.
- Utilizzando un servizio online. Ci sono diversi servizi che consentono di testare la configurazione delle CSP. Ad esempio, CSP Evaluator e CSP Validator.
- Utilizzando un tool di analisi. Ci sono diversi tool di analisi che consentono di scansionare il tuo sito web e di identificare eventuali violazioni delle CSP. Ad esempio, Mozilla Observatory e securityheaders.com
- Utilizzando “curl” dal terminale. E’ possibile utilizzare “curl” dal terminale per effettuare una richiesta alla pagina web e verificare che l’header CSP
Testare le Content Security Policy con curl
Ecco un esempio di come utilizzare “curl” per testare la configurazione della Content Security Policy (CSP) su un sito web:
curl -I https://urldeltuosito.comQuesto comando invierà una richiesta HTTP di tipo “HEAD” alla pagina web e restituirà solo gli header della risposta. Tra gli header deve essere presente “Content-Security-Policy” con la configurazione impostata.
Se invece vuoi vedere anche il contenuto della pagina puoi utilizzare il comando:
curl https://urldeltuosito.comIn entrambi i casi, se la configurazione della CSP è corretta, dovresti vedere l’header “Content-Security-Policy” con il valore configurato. In caso contrario, l’header non sarà presente nella risposta.
Contributo video su CSP
Come di consueto, per integrare i contenuti riportati nell’articolo, vi lascio anche un utile contributo video in cui vengono spiegati i CSP.
Per la cronaca, questo video non sarebbe visibile in questa pagina se non fosse configurata un’adeguata policy CSP. Ve la riporto per utilità.
Header set Content-Security-Policy "default-src 'self'; img-src 'self' https://img.youtube.com; frame-src https://www.youtube.com"La direttiva img-src serve a mostrare l’immagine di anteprima del video, prima che questo vada in riproduzione. Mentre la direttiva frame-src serve a permettere al video di includere l’iframe che conterrà il video vero e proprio.
Conclusioni
Come avete notato le informazioni sono molte a senza un po’ di pratica possono anche sembrare complesse da mettere in atto. Vi assicuro però che una volta capiti i concetti base, sarà estremamente semplice attuarli e vedrete che otterrete risultati sfavillanti 🙂 .
Spero che il contenuto vi risulti utile.
Se avete dubbi, sentitevi liberi di commentare. Sarò felice di aiutarvi.
Buon lavoro
Se volete restare aggiornati, potete iscrivervi alla mia newsletter su LinkedIn.
Principal Web Solutions Architect – Technology & Architecture Manager @ Accenture – Google Cloud Certified – Professional Cloud Architect
Parla di #web, #cloud, #websecurity, #webperformance e #webarchitecture