Applicare criteri di sicurezza del contenuto per ASP.NET Core Blazor

Questo articolo illustra come usare un CSP (Content Security Policy) con ASP.NET app Core Blazor per proteggere da attacchi XSS (Cross-Site Scripting).

Scripting tra siti (XSS) è una vulnerabilità di sicurezza in cui un cyberattacker inserisce uno o più script sul lato client dannosi nel contenuto sottoposto a rendering di un'app. Un provider di servizi di configurazione consente di proteggersi da attacchi XSS informando il browser di validità:

• Origini per il contenuto caricato, inclusi script, fogli di stile, immagini e plug-in.
• Azioni eseguite da una pagina, specificando le destinazioni URL consentite dei moduli.

Per applicare un provider di servizi di configurazione a un'app, lo sviluppatore specifica diverse direttive di sicurezza del contenuto CSP in una o più Content-Security-Policy intestazioni o <meta> tag. Per indicazioni sull'applicazione di un provider di servizi di configurazione a un'app nel codice C# all'avvio, vedere ASP.NET avvio di CoreBlazor.

I criteri vengono valutati dal browser durante il caricamento di una pagina. Il browser esamina le origini della pagina e determina se soddisfano i requisiti delle direttive di sicurezza del contenuto. Quando le direttive dei criteri non vengono soddisfatte per una risorsa, il browser non carica la risorsa. Si consideri, ad esempio, un criterio che non consente script di terze parti. Quando una pagina contiene un <script> tag con un'origine di terze parti nell'attributo src , il browser impedisce il caricamento dello script.

CSP è supportato nei browser desktop e per dispositivi mobili più moderni, tra cui Chrome, Edge, Firefox, Opera e Safari. CSP è consigliato per Blazor le app.

Direttive per i criteri

Specificare minimamente le direttive e le origini seguenti per Blazor le app. Aggiungere altre direttive e origini in base alle esigenze. Le direttive seguenti vengono usate nella sezione Applica i criteri di questo articolo, in cui vengono forniti i criteri di sicurezza di esempio per Blazor le app:

• base-uri: limita gli URL per il tag di <base> una pagina. Specificare self per indicare che l'origine dell'app, incluso lo schema e il numero di porta, è un'origine valida.
• default-src: indica un fallback per le direttive di origine che non sono specificate in modo esplicito dai criteri. Specificare self per indicare che l'origine dell'app, incluso lo schema e il numero di porta, è un'origine valida.
• img-src: indica le origini valide per le immagini.
  • Specificare data: per consentire il caricamento di immagini da data: URL.
  • Specificare https: per consentire il caricamento di immagini dagli endpoint HTTPS.
• object-src: indica le origini valide per i <object>tag , <embed>e <applet> . Specificare none per impedire tutte le origini URL.
• script-src: indica origini valide per gli script.
  • Specificare self per indicare che l'origine dell'app, incluso lo schema e il numero di porta, è un'origine valida.
  • In un'app lato Blazor client:
    • Specificare wasm-unsafe-eval per consentire il funzionamento del runtime Mono sul lato Blazor client.
    • Specificare eventuali hash aggiuntivi per consentire il caricamento degli script non framework necessari.
  • In un'app lato Blazor server specificare gli hash per consentire il caricamento degli script necessari.
• style-src: indica le origini valide per i fogli di stile.
  • Specificare self per indicare che l'origine dell'app, incluso lo schema e il numero di porta, è un'origine valida.
  • Se l'app usa stili inline, specificare unsafe-inline per consentire l'uso degli stili inline.
• upgrade-insecure-requests: indica che gli URL del contenuto provenienti da origini HTTP non sicure devono essere acquisiti in modo sicuro tramite HTTPS.

Le direttive precedenti sono supportate da tutti i browser ad eccezione di Microsoft Internet Explorer.

Per ottenere hash SHA per script inline aggiuntivi:

• Applicare il provider di servizi di configurazione visualizzato nella sezione Applica il criterio .
• Accedere alla console degli strumenti di sviluppo del browser durante l'esecuzione dell'app in locale. Il browser calcola e visualizza gli hash per gli script bloccati quando è presente un'intestazione o meta un tag CSP.
• Copiare gli hash forniti dal browser nelle script-src origini. Usare virgolette singole per ogni hash.

Per una matrice di supporto del browser content Security Policy Level 2, vedere Can I use: Content Security Policy Level 2(I Can I use: Content Security Policy Level 2).

Applicare i criteri

Usare un <meta> tag per applicare il criterio:

• Impostare il valore dell'attributo http-equiv su Content-Security-Policy.
• Inserire le direttive nel valore dell'attributo content . Separare le direttive con un punto e virgola (;).
• Posizionare sempre il meta tag nel <head> contenuto.

Nelle sezioni seguenti vengono illustrati i criteri di esempio. Questi esempi vengono forniti con il controllo delle versioni di questo articolo per ogni versione di Blazor. Per usare una versione appropriata per la versione, selezionare la versione del documento con il selettore a discesa Versione in questa pagina Web.

App lato Blazor server

Nel contenuto applicare le direttive descritte nella sezione Direttive dei criteri:<head>

<meta http-equiv="Content-Security-Policy" 
      content="base-uri 'self';
               default-src 'self';
               img-src data: https:;
               object-src 'none';
               script-src 'self';
               style-src 'self';
               upgrade-insecure-requests;">

Aggiungere altri script-src hash e style-src come richiesto dall'app. Durante lo sviluppo, usare uno strumento online o strumenti di sviluppo del browser per fare in modo che gli hash siano calcolati. Ad esempio, l'errore della console degli strumenti del browser seguente segnala l'hash per uno script obbligatorio non coperto dai criteri:

Rifiutato di eseguire script inline perché viola la seguente direttiva dei criteri di sicurezza del contenuto: " ... ". La parola chiave "unsafe-inline", un hash ('sha256-v8v3RKRPmN4odZ1CWM5gw80QKPCCWMcpNeOmimNL2AA=') o un nonce ('nonce-...') è necessario per abilitare l'esecuzione inline.

Lo script specifico associato all'errore viene visualizzato nella console accanto all'errore.

App lato Blazor client

Nel contenuto applicare le direttive descritte nella sezione Direttive dei criteri:<head>

<meta http-equiv="Content-Security-Policy" 
      content="base-uri 'self';
               default-src 'self';
               img-src data: https:;
               object-src 'none';
               script-src 'self'
                          'wasm-unsafe-eval';
               style-src 'self';
               upgrade-insecure-requests;">

Aggiungere altri script-src hash e style-src come richiesto dall'app. Durante lo sviluppo, usare uno strumento online o strumenti di sviluppo del browser per fare in modo che gli hash siano calcolati. Ad esempio, l'errore della console degli strumenti del browser seguente segnala l'hash per uno script obbligatorio non coperto dai criteri:

Rifiutato di eseguire script inline perché viola la seguente direttiva dei criteri di sicurezza del contenuto: " ... ". La parola chiave "unsafe-inline", un hash ('sha256-v8v3RKRPmN4odZ1CWM5gw80QKPCCWMcpNeOmimNL2AA=') o un nonce ('nonce-...') è necessario per abilitare l'esecuzione inline.

Lo script specifico associato all'errore viene visualizzato nella console accanto all'errore.

Applicare un provider di servizi di configurazione in ambienti nonDevelopment

Quando un provider di servizi di configurazione viene applicato al contenuto di un'appBlazor, interferisce con i test locali nell'ambienteDevelopment.<head> Ad esempio, il collegamento al browser e lo script di aggiornamento del browser non vengono caricati. Gli esempi seguenti illustrano come applicare il tag del provider di <meta> servizi di configurazione in ambienti nonDevelopment .

Nota

Gli esempi in questa sezione non mostrano il tag completo <meta> per i CSP. I tag completi <meta> sono disponibili nelle sottosezioni della sezione Applica i criteri in precedenza in questo articolo.

Sono disponibili tre approcci generali:

• Applicare il provider di servizi di configurazione tramite il App componente , che applica il provider di servizi di configurazione a tutti i layout dell'app.
• Se è necessario applicare provider di servizi di configurazione a aree diverse dell'app, ad esempio un provider di servizi di configurazione personalizzato solo per le pagine di amministrazione, applicare i CSP in base al layout usando il <HeadContent> tag . Per un'efficacia completa, ogni file di layout dell'app deve adottare l'approccio.
• Il servizio di hosting o il server può fornire un provider di servizi di configurazione tramite un'intestazione Content-Security-Policy aggiunta delle risposte in uscita di un'app. Poiché questo approccio varia in base al servizio di hosting o al server, non viene risolto negli esempi seguenti. Per adottare questo approccio, consultare la documentazione relativa al provider di servizi di hosting o al server.

Blazor Web App Approcci

App Nel componente (Components/App.razor) inserire IHostEnvironment:

@inject IHostEnvironment Env

App Nel contenuto del <head> componente applicare il provider di servizi di configurazione quando non si trova nell'ambienteDevelopment:

@if (!Env.IsDevelopment())
{
    <meta ...>
}

In alternativa, applicare i CSP in base al layout nella Components/Layout cartella, come illustrato nell'esempio seguente. Assicurarsi che ogni layout specifichi un provider di servizi di configurazione.

@inject IHostEnvironment Env

@if (!Env.IsDevelopment())
{
    <HeadContent>
        <meta ...>
    </HeadContent>
}

Blazor WebAssembly approcci alle app

App Nel componente (App.razor) inserire IWebAssemblyHostEnvironment:

@using Microsoft.AspNetCore.Components.WebAssembly.Hosting
@inject IWebAssemblyHostEnvironment Env

App Nel contenuto del <head> componente applicare il provider di servizi di configurazione quando non si trova nell'ambienteDevelopment:

@if (!Env.IsDevelopment())
{
    <HeadContent>
        <meta ...>
    </HeadContent>
}

In alternativa, usare il codice precedente, ma applicare i CSP in base al layout nella Layout cartella. Assicurarsi che ogni layout specifichi un provider di servizi di configurazione.

Limitazioni dei tag meta

I <meta> criteri di tag non supportano le direttive seguenti:

• frame-ancestors
• da report a
• report-uri
• sandbox

Per supportare le direttive precedenti, usare un'intestazione denominata Content-Security-Policy. La stringa di direttiva è il valore dell'intestazione.

Testare un criterio e ricevere segnalazioni di violazioni

Il test consente di verificare che gli script di terze parti non vengano bloccati inavvertitamente durante la compilazione di un criterio iniziale.

Per testare un criterio in un periodo di tempo senza applicare le direttive dei criteri, impostare l'attributo o il <meta> nome dell'intestazione del http-equiv tag di un criterio basato su intestazione su Content-Security-Policy-Report-Only. I report sugli errori vengono inviati come documenti JSON a un URL specificato. Per altre informazioni, vedere La documentazione Web MDN: Content-Security-Policy-Report-Only.

Per segnalare violazioni mentre un criterio è attivo, vedere gli articoli seguenti:

• da report a
• report-uri

Sebbene report-uri non sia più consigliato per l'uso, entrambe le direttive devono essere usate fino a quando report-to non sono supportate da tutti i principali browser. Non usare report-uri esclusivamente perché il supporto per report-uri è soggetto a essere eliminato in qualsiasi momento dai browser. Rimuovere il supporto per report-uri nei criteri quando report-to è completamente supportato. Per tenere traccia dell'adozione di report-to, vedere È possibile usare: report-to.

Testare e aggiornare i criteri di un'app ogni versione.

Risoluzione dei problemi

• Gli errori vengono visualizzati nella console degli strumenti di sviluppo del browser. I browser forniscono informazioni su:
  • Elementi che non sono conformi ai criteri.
  • Come modificare i criteri per consentire un elemento bloccato.
• Un criterio è completamente efficace solo quando il browser del client supporta tutte le direttive incluse. Per una matrice di supporto del browser corrente, vedere È possibile usare: Content-Security-Policy.

Risorse aggiuntive

• Applicare un CSP nel codice C# all'avvio
• Documentazione Web MDN: Criteri di sicurezza del contenuto (CSP)
• Documentazione Web MDN: intestazione della risposta Content-Security-Policy
• Livello 2 dei criteri di sicurezza del contenuto
• Analizzatore google CSP