Content Security Policy: più sicurezza per i contenuti sul web

I contenuti attivi presenti sui siti web, come ad esempio JavaScript, CSS e ActiveX, rappresentano un pericolo per gli utenti e per i gestori delle pagine web poiché potreste essere manipolati dai cosiddetti Cross Site Scripting. Per fare sì che le pagine Internet possano essere utilizzate in modo esaustivo senza correre rischi, è stata introdotta la Content Security Policy (CSP). Questo standard di sicurezza, supportato dalla maggioranza dei browser moderni, ha l’obiettivo di difendere i siti web dagli attacchi cibernetici e, contemporaneamente, di proteggere gli utenti. Ma cosa si nasconde dietro la CSP e come funziona?

La Content Security Policy ha origini nel 2014 ed era inizialmente conosciuta con il nome di “Content Restriction”. La nascita di questo progetto è stata provocata dalla quantità crescente di falle di sicurezza negli script di Internet; in particolare il Cross Site Scripting (XSS), un metodo criminale per far entrare clandestinamente dei malware in un determinato sito web, molto rischioso per gli utenti.

Può infatti accadere che si apra un sito Internet considerato affidabile, ma poi viene eseguito uno script che carica dati dannosi da una fonte sconosciuta. I criminali informatici possono utilizzare a questo scopo le falle di sicurezza presenti, ad esempio, nella funzione di inserimento commenti di un sito web. In questo modo i malintenzionati possono riuscire ad ottenere l’accesso al PC dell’utente senza che questo se ne accorga. Neanche i webmaster riescono a capire immediatamente quand’è che un codice esterno entra clandestinamente in un sito Internet.

Per ovviare a questo problema, Mozilla Foundation ha deciso di accelerare lo sviluppo della CSP. Il vantaggio degli standard di sicurezza consiste nel fatto che è possibile stabilire quali script devono essere eseguiti dal software e quali no. Per fare questo la Content Security Policy ricorre agli header HTTP.

Durante la trasmissione di informazioni tramite Internet, tra i client e i server avviene uno scambio di dati mediante l’Hypertext Transfer Protocol (HTTP). Una delle componenti principali delle request e delle response sono gli header HTTP: questi campi vengono utilizzati per trasmettere parametri e argomenti, importanti per lo scambio dei dati tra emittente e ricevente, ossia tra client e server. Sono generalmente suddivisi in campi di richiesta e risposta e, ad esempio, possono contenere informazioni sul set di caratteri, sulla lingua e sui cookie. La CSP viene implementata in qualità di campo di intestazione della risposta. Ciò significa che il server fornisce le informazioni e il browser le elabora.

L’header della Content Security Policy viene implementato dal webmaster e inserito in tutte le sottopagine del sito web a cui si desidera applicare lo standard di sicurezza. Il gestore del sito Internet, inoltre, ha la possibilità di stabilire provvedimenti per la sicurezza che si differenziano da pagina a pagina. È possibile implementare il concetto di sicurezza più facilmente creando un file .htaccess nelle stesse cartelle (o in quelle gerarchicamente più alte) delle pagine web corrispondenti o ancorando la CSP direttamente nella configurazione del server.

In una Content Security Policy e al fine di prevenire lo scripting tra siti diversi, i webmaster dovrebbero memorizzare tutti gli script in file separati e non incorporarli direttamente nel codice sorgente del proprio sito Internet. Questo indica che la CSP funziona secondo il principio della whitelist: nell’header vengono elencate le fonti da cui è possibile caricare gli script e i dati. Dunque, nel momento in cui viene inserito uno script sconosciuto nel codice HTML della pagina, il browser dell’utente deve proibire il caricamento di dati esterni. Per impostazione predefinita, la CSP blocca tutti gli script inseriti direttamente nel codice (inline scripting). Questo protegge sia il sito web che gli utenti, e soprattutto i loro dati sensibili.

Per i cybercriminali le manipolazioni tramite Cross Site Scripting sono relativamente semplici da attuare. Infatti quasi tutti i siti Internet sono dotati di un campo di input, come ad esempio la funzione di inserimento commenti, la barra di ricerca o il campo per effettuare il login: in queste sezioni, invece di inserire delle semplici parole, spesso vengono eseguiti degli script.

Dunque, se il server non è correttamente cautelato, i criminali informatici possono implementare interfacce di phishing, causare un blocco del sito web oppure utilizzare dei malware per ottenere il controllo dell’utente tramite browser. La CSP (o più precisamente: l’header corrispettivo) comunica al browser web da quali fonti è consentito caricare dei dati. Se la policy è implementata nel codice del sito web, al tentativo di recuperare quel codice introdotto tramite XSS viene risposto con un messaggio di errore.

Tramite l’utilizzo della Content Security Policy i webmaster possono modificare numerose impostazioni, ad esempio, tramite le seguenti direttive:

• base-uri: limita gli URL che possono comparire nell’elemento <base> della pagina web.
• child-src: stabilisce le fonti da cui trarre i dati che possono apparire nei frame, ad esempio i video forniti da terzi.
• connect-src: limita le fonti alle quali il sito Internet può connettersi, ad esempio tramite link.
• font-src: stabilisce da quali fonti possono essere caricati i font
• form-action: fornisce una lista di moduli endpoint validi.
• frame-ancestors: stabilisce quali domini possono strutturare la pagina in frame e iFrame.
• img-src: stabilisce da quali fonti possono essere caricate le immagini.
• media-src: determina da quali fonti possono essere caricati formati audio e video.
• object-src: controlla Flash e altri tipi di plug-in.
• plugin-types: limita le tipologie di plug-in.
• report-uri: specifica un URL a cui inviare i report in caso di violazione delle misure di sicurezza.
• script-src: determina quali fonti sono consentite per JavaScript.
• style-src: funziona come script-src, ma è usato per i fogli di stile.
• upgrade-insecure-requests: stabilisce che le pagine HTTP non protette vengano considerate come pagine HTTPS.
• sandbox: sposta la pagina in un sandbox in cui sono vietati moduli, pop-up e script.

Queste direttive sono valide solo se esplicitamente riconosciute, altrimenti restano aperte di default, costituendo così una falla di sicurezza nel sistema. Tuttavia tramite il default-src è possibile eludere questo problema: con questo metodo si stabiliscono le impostazioni di tutte le direttive che terminano con -src. Ad esempio, è possibile stabilire che il proprio sito Internet carichi soltanto i dati, a meno che non sia stato specificato diversamente nell'header HTTP di una singola pagina. Nelle direttive specifiche, inoltre, è possibile anche aggiungere atre fonti.

Nell’header è possibile immettere un numero potenzialmente infinito di direttive. Se si desidera includere più direttive, è necessario separarle con punto e virgola. Inoltre, il webmaster deve specificare tutte le sorgenti e le fonti all’interno di una direttiva. Non sono consentite citazioni multiple delle stesse direttive con fonti aggiuntive. L’esempio seguente mostra un comando non ammesso: