Un criterio di sicurezza del contenuto (CSP) contribuisce a garantire che tutti i contenuti caricati nella pagina siano considerati attendibili dal proprietario del sito. I CSP mitigano gli attacchi cross-site scripting (XSS) perché possono bloccare gli script non sicuri inseriti da utenti malintenzionati. Tuttavia, il CSP può essere facilmente ignorato se non è abbastanza rigoroso. Per saperne di più, consulta l'articolo Mitigare il cross-site scripting (XSS) con un severo criterio di sicurezza del contenuto (CSP). Lighthouse raccoglie i CSP applicati al documento principale e segnala i problemi da CSP Evaluator se possono essere aggirati.
Pratiche obbligatorie per un CSP non ignorabile
Implementa le seguenti pratiche per garantire che non sia possibile aggirare il criterio CSP. Se è possibile bypassare il criterio CSP, Lighthouse emette un avviso di gravità elevata.
CSP targetizza XSS
Per scegliere come target XSS, un CSP deve includere le istruzioni script-src, object-src e base-uri. Inoltre, il CSP deve essere privo di errori di sintassi.
script-src e object-src proteggono una pagina rispettivamente da script non sicuri e plug-in non sicuri. In alternativa, è possibile utilizzare default-src per configurare un criterio ampio al posto di molte istruzioni, tra cui script-src e object-src.
base-uri impedisce l'inserimento di tag <base> non autorizzati, che possono essere utilizzati per reindirizzare tutti gli URL relativi (come gli script) a un dominio controllato da un utente malintenzionato.
CSP utilizza nonce o hash per evitare l'esclusione dalla lista consentita
Un CSP che configura una lista consentita per script-src si basa sul presupposto che tutte le risposte provenienti da un dominio attendibile siano sicure e possano essere eseguite come script. Tuttavia, questa ipotesi non è valida per le applicazioni moderne; alcuni modelli comuni e innocui come l'esposizione delle interfacce JSONP e l'hosting di copie della libreria AngularJS consentono agli utenti malintenzionati di sfuggire ai confini di CSP.
In pratica, anche se potrebbe non essere ovvio per gli autori delle applicazioni, la maggior parte delle liste consentite di script-src può essere aggirata da un utente malintenzionato con un bug XSS e fornire una protezione scarsa contro l'iniezione di script. Al contrario, gli approcci basati su nonce e hash non soffrono di questi problemi e semplificano l'adozione e la gestione di criteri più sicuri.
Ad esempio, questo codice utilizza un endpoint JSONP ospitato su un dominio attendibile per inserire uno script controllato da un utente malintenzionato:
CSP:
script-src https://trusted.example.com
HTML:
<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>
Per evitare di essere aggirato, un CSP dovrebbe consentire singolarmente gli script utilizzando nonce o hash e utilizzare "strict-dynamic" invece di una lista consentita.
Ulteriori suggerimenti per un CSP sicuro
Implementa le seguenti pratiche per una maggiore sicurezza e compatibilità. Se il CSP non segue uno dei consigli, Lighthouse emette un avviso di gravità media.
Configurare i report CSP
Configurare una destinazione per i report aiuterà a monitorare eventuali interruzioni. Puoi impostare la destinazione dei report utilizzando le istruzioni report-uri o report-to. report-to non è attualmente supportato da tutti i browser moderni, quindi si consiglia di usare entrambi o solo report-uri.
Se sono presenti contenuti che violano i CSP, il browser invierà un report alla destinazione configurata. Assicurati di avere configurato un'applicazione a questa destinazione che gestisce questi report.
Definisci il criterio CSP in un'intestazione HTTP
Un CSP può essere definito in un meta tag come questo:
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
Tuttavia, se puoi, devi definire un criterio CSP in un'intestazione della risposta HTTP. Un'iniezione prima del meta tag ignorerà il CSP. Inoltre, frame-ancestors, sandbox e i report non sono supportati nei CSP dei meta tag.
Assicurati che CSP sia compatibile con le versioni precedenti
Non tutti i browser supportano nonce/hash CSP, pertanto è consigliabile aggiungere unsafe-inline come metodo di riserva per i browser non conformi. Se il browser supporta nonce/hash, unsafe-inline verrà ignorato.
Analogamente, strict-dynamic non è supportato da tutti i browser. Ti consigliamo di impostare una lista consentita come riserva per tutti i browser non conformi. La lista consentita verrà ignorata nei browser che supportano strict-dynamic.
Come sviluppare un CSP rigoroso
Di seguito è riportato un esempio di utilizzo di un CSP rigoroso con una norma basata sul nonce.
CSP:
script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;
HTML:
<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>
random123 corrisponde a qualsiasi stringa base64 generata sul lato server ogni volta che viene caricata la pagina. unsafe-inline e https: vengono ignorati nei browser moderni a causa del nonce e di strict-dynamic. Per ulteriori informazioni sull'adozione di un CSP rigoroso, consulta la guida relativa ai CSP rigorosi.
Puoi verificare la presenza di potenziali bypass in un CSP utilizzando Lighthouse e CSP Evaluator. Se vuoi testare un nuovo CSP senza il rischio di danneggiare le pagine esistenti, definisci il CSP in modalità di solo report utilizzando Content-Security-Policy-Report-Only come nome dell'intestazione. Le violazioni CSP verranno inviate a tutte le destinazioni dei report configurate con report-to e report-uri, ma in realtà non verrà applicato alcun criterio CSP.