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 cross-site scripting (XSS) perché possono bloccare gli script non sicuri inseriti dagli utenti malintenzionati. Tuttavia, il CSP può essere facilmente ignorato se non è abbastanza rigoroso. Per saperne di più, consulta Mitigare il 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 da CSP Valutatore, se possono essere aggirati.
Pratiche obbligatorie per un CSP non ignorabile
Implementa le seguenti pratiche per assicurarti che il tuo CSP non possa essere ignorato. Se il CSP può essere ignorato, Lighthouse emette un avviso di gravità elevata.
CSP sceglie come target XSS
Per scegliere come target XSS, un CSP deve includere le istruzioni 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 non sicuri e plug-in non sicuri. In alternativa, è possibile usare 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 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 ovvio per gli autori delle applicazioni, la maggior parte delle script-src liste consentite può essere aggirata da un utente malintenzionato con un bug XSS e fornisce poca protezione contro l'inserimento 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 gravità media.
Configura i report CSP
La configurazione di una destinazione di reporting consente di monitorare eventuali malfunzionamenti. 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 ti consigliamo di utilizzare entrambi o solo report-uri.
Se un contenuto viola le norme CSP, il browser invierà un report alla destinazione configurata. Assicurati di avere configurato un'applicazione in questa destinazione per la gestione di questi report.
Definisci il 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 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 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 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 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 corrisponderebbe a una 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 saperne di più sull'adozione di un CSP rigoroso, consulta la guida rigorosa per CSP.
Puoi verificare la presenza di potenziali bypass a un CSP utilizzando Lighthouse e CSP Valutatore. Se vuoi testare un nuovo CSP senza il rischio di danneggiare 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 dei CSP verranno inviate a qualsiasi destinazione di segnalazione che hai configurato con report-to e report-uri, ma non applicherà effettivamente i CSP.