Un criterio di sicurezza del contenuto (CSP) contribuisce a garantire che tutti i contenuti caricati nella pagina siano attendibili dal proprietario del sito. I CSP mitigano gli attacchi di cross-site scripting (XSS) perché possono bloccare gli script non sicuri iniettati dagli aggressori. Tuttavia, il CSP può essere facilmente ignorato se non è abbastanza rigoroso. Per saperne di più, consulta l'articolo Mitigare gli attacchi cross-site scripting (XSS) con un Criterio di sicurezza del contenuto (CSP) rigoroso. Lighthouse raccoglie i CSP applicati al documento principale e segnala i problemi di CSP Evaluator se possono essere aggirati.
Pratiche richieste per un CSP non eludibile
Implementa le seguenti pratiche per assicurarti che il tuo CSP non possa essere aggirato. Se il CSP può essere ignorato, Lighthouse emette un avviso di gravità elevata.
I target CSP sono XSS
Per scegliere come target gli attacchi XSS, un CSP deve includere le direttive script-src, object-src e base-uri. Il CSP deve inoltre essere privo di errori di sintassi.
script-src e object-src proteggono una pagina rispettivamente da script e plug-in non sicuri. In alternativa, default-src può essere utilizzato per configurare un criterio generale al posto di molte direttive, 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 utenti malintenzionati.
CSP utilizza nonce o hash per evitare le esclusioni della 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, questo presupposto non vale per le applicazioni moderne; alcuni pattern comuni e benigni, come l’esposizione di interfacce JSONP e l’hosting di copie della libreria AngularJS, consentono agli aggressori di uscire dai confini di CSP.
In pratica, anche se potrebbe non essere evidente per gli autori delle applicazioni, la maggior parte delle script-src liste consentite può essere aggirata da un malintenzionato con un bug XSS e offre poca protezione contro l'iniezione di script. Al contrario, gli approcci basati su nonce e hash non presentano questi problemi e semplificano l'adozione e la gestione di norme più sicure.
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 bypassato, un CSP deve consentire gli script individualmente utilizzando nonce o hash e utilizzare "strict- dynamic" anziché in una lista consentita.
Suggerimenti aggiuntivi 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 media gravità.
Configura i report CSP
La configurazione di una destinazione di generazione di report ti aiuterà a monitorare eventuali interruzioni. Puoi impostare la destinazione dei report utilizzando le direttive report-uri o report-to. report-to non è attualmente supportato da tutti i browser moderni, pertanto è consigliabile utilizzarli entrambi o solo report-uri.
Se i contenuti violano il CSP, il browser invia un report alla destinazione configurata. Assicurati di avere configurato un'applicazione in questa destinazione per gestire questi report.
Definire 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 possibile, devi definire un criterio CSP in un'intestazione della risposta HTTP. Un'iniezione prima del tag meta aggira 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 gli hash/nonce CSP, pertanto si consiglia di aggiungere unsafe-inline come 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 opzione di riserva per 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 criterio CSP rigoroso con un criterio nonce-basato.
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 è una stringa base64 generata lato server ogni volta che la pagina viene caricata. 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 rigorosa per i CSP.
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 interrompere le pagine esistenti, definisci il CSP in modalità solo report utilizzando Content-Security-Policy-Report-Only come nome dell'intestazione. In questo modo, le violazioni del CSP verranno inviate a tutte le destinazioni di generazione di report che hai configurato con report-to e report-uri, ma il CSP non verrà effettivamente applicato.