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

Questo articolo illustra come usare una politica di sicurezza dei contenuti (CSP) con ASP.NET Core Blazor per proteggere da alcuni tipi di attacchi dannosi, ad esempio XSS (Cross-Site Scripting) e attacchi clickjacking. XSS è una vulnerabilità di sicurezza in cui un cyberattacker inserisce uno o più script lato client dannosi nel contenuto sottoposto a rendering di un'app. In un attacco di clickjacking, un utente viene ingannato a interagire con un sito Web ingannevole che ha la tua app incorporata al suo interno.

Una Content Security Policy (CSP) aiuta a proteggersi da questi tipi di attacchi informando il browser su quali contenuti siano validi.

• 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.
• Quando l'app può essere incorporata in un altro sito Web tramite <frame>, <iframe>, <object>o tag di <embed>.

È consigliabile leggere le seguenti risorse MDN durante l'implementazione di una politica di sicurezza dei contenuti:

• Content Security Policy (CSP)
• Linee guida di riferimento per i CSP
• Implementazione della Politica di Sicurezza dei Contenuti (CSP)

Per applicare un CSP a un'app, lo sviluppatore specifica diverse direttive di sicurezza dei contenuti CSP in una o più intestazioni o tag. Per indicazioni sull'applicazione di un provider di servizi di configurazione a un'app nel codice C# all'avvio, vedere ASP.NET Core Blazor startup e la sezione Direttiva frame-ancestors più avanti in questo articolo.

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 app.

Avviso

L'implementazione di una Politica di Sicurezza dei Contenuti riduce al minimo il rischio di determinati tipi di minacce alla sicurezza e non garantisce che un'app sia completamente sicura dagli attacchi XSS e di clickjacking. Gli agenti utente, in genere browser, possono consentire agli utenti di modificare o ignorare l'imposizione dei criteri tramite preferenze utente, segnalibri, estensioni del browser, aggiunte di terze parti all'agente utente e altri meccanismi di questo tipo. Inoltre, i CSP sono incentrati solo sulla correzione di un subset di attacchi, non su tutti gli attacchi che possono compromettere la sicurezza, ad esempio SQL injection, cross-site request forgery (CSRF), errori di configurazione della sicurezza e attacchi Denial of Service (DoS).

Direttive politiche

Le direttive e le origini seguenti vengono comunemente usate per le app Blazor. Aggiungere altre direttive e origini in base alle esigenze. Le seguenti direttive sono utilizzate nella sezione "Applicare la politica" di questo articolo, dove vengono forniti esempi di politiche di sicurezza per le app Blazor:

• base-uri: limita gli URL per il tag <base> di 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 una soluzione alternativa 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 origini valide per i tag <object>, <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'applicazione lato client Blazor
    • Specificare wasm-unsafe-eval per consentire al runtime Mono lato client Blazor di funzionare.
    • Specificare eventuali hash aggiuntivi per consentire il caricamento degli script non framework necessari. Ad esempio, specificare unsafe-hashes con un hash di sha256-qnHnQs7NjQNHHNYv/I9cW+I62HzDJjbnyS/OFzqlix0= per consentire il JavaScript inline per il toggle di navigazione nel componente NavMenu.
  • In un'applicazione lato server Blazor, specificare gli hash per consentire il caricamento degli script richiesti.
• style-src: indica le fonti 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.
• connect-src: limita gli URL che possono essere caricati tramite interfacce script. Vengono specificate le origini dello schema http:, ws: (protocollo WebSocket) e wss: (protocollo WebSocket Secure).
• 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 gli hash SHA per gli script inline aggiuntivi:

• Applica il CSP visualizzato nella sezione Applica la politica.
• 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 CSP o un tag meta.
• Copiare gli hash trasmessi dal browser alle script-src sorgenti. Usare virgolette singole per ogni hash.

Per una matrice di supporto del browser per Content Security Policy Livello 2, vedere Can I use: Content Security Policy Level 2.

Applicare la politica

È possibile applicare un CSP tramite:

• Un'intestazione di risposta rilasciata dall'host (ad esempio, IIS) o rilasciata dall'app (vedere intestazioni di controllo nel codice C# all'avvio).
• Un tag <meta>. Questo articolo illustra solo l'approccio ai tag <meta>.

Per usare un tag <meta> per applicare i criteri:

• 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 (;). Non è necessario un punto e virgola finale per l'ultima direttiva della stringa di criteri in base alla specifica Livello 3 della Sicurezza del Contenuto.
• Posizionare il tag <meta> nel contenuto <head> all'interno del tag <head> di apertura. I criteri vengono valutati e applicati quando viene analizzato il markup CSP, pertanto i criteri devono essere visualizzati nella parte superiore del markup <head> per assicurarsi che venga applicato a tutti i tag <script> e <link>.

Nelle sezioni seguenti vengono illustrati i criteri di esempio. Questi esempi sono versionati insieme a questo articolo per ogni rilascio di Blazor. Per utilizzare una versione appropriata per il tuo rilascio, selezionare la versione del documento con il selettore a discesa Versione su questa pagina.

La direttiva frame-ancestors

La direttiva frame-ancestors specifica quali sono gli elementi padre validi che possono incorporare una pagina con i tag <frame>, <iframe>, <object>o <embed>. Una direttiva frame-ancestors non può essere applicata tramite un CSP basato su tag <meta>. La direttiva deve essere implementata attraverso un'intestazione di risposta. Un'intestazione di risposta CSP può essere aggiunta da un host server, oppure il codice C# dell'app può aggiungere o aggiornare una CSP con una direttiva frame-ancestors.

Blazor Web App(.NET 8 o versione successiva) includono automaticamente un'intestazione di risposta che imposta il valore su 'self':

Content-Security-Policy: frame-ancestors 'self'

Per modificare il valore predefinito con il più restrittivo 'none' e impedire a tutti gli elementi padre di incorporare l'app, impostare l'opzione ContentSecurityFrameAncestorsPolicy nella chiamata a AddInteractiveServerRenderMode nel file Program. Quanto segue viene applicato solo quando è abilitata la compressione WebSocket (ConfigureWebSocketAcceptContext è impostato, che è il valore predefinito per le app Blazor).

.AddInteractiveServerRenderMode(o => o.ContentSecurityFrameAncestorsPolicy = "'none'")

Nelle app Blazor Server non viene aggiunta una direttiva frame-ancestors predefinita alla raccolta di intestazioni di risposta. È possibile aggiungere manualmente un'intestazione CSP con middleware nella pipeline di elaborazione delle richieste:

app.Use(async (context, next) =>
{
    context.Response.Headers.Add("Content-Security-Policy", "frame-ancestors 'none'");
    await next();
});

Avviso

Evitare di impostare il valore della direttiva frame-ancestors su 'null' quando la compressione WebSocket è abilitata (la compressione è l'impostazione predefinita) perché rende l'app vulnerabile agli attacchi di inserimento di script dannosi e clickjacking.

Per altre informazioni, vedere CSP: frame-ancestors (documentazione MDN).

App lato Blazor server

L'esempio seguente è un punto di partenza per un ulteriore sviluppo. Nella parte superiore del contenuto <head>, applica le direttive descritte nella sezione delle direttive di Policy , insieme a qualsiasi altra direttiva richiesta dalla specifica dell'app.

Per le app Blazor Web Appo Blazor Server:

<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' 'unsafe-hashes' 
        'sha256-qnHnQs7NjQNHHNYv/I9cW+I62HzDJjbnyS/OFzqlix0=';
    style-src https:;
    connect-src 'self' http: ws: wss:;
    upgrade-insecure-requests;" />

Blazor Web Appincludono un gestore eventi JavaScript inline onclick nel componente NavMenu che richiede una delle modifiche seguenti:

• Aggiungere un hash alla direttiva script-src con la parola chiave unsafe-hashes:

  'unsafe-hashes' 'sha256-qnHnQs7NjQNHHNYv/I9cW+I62HzDJjbnyS/OFzqlix0='
  

  Per ulteriori informazioni, vedere CSP: script-src: script inline non sicuro (documentazione MDN).

• Spostare il gestore eventi JavaScript inline in un file o un modulo JavaScript che sia consentito di essere caricato dalla policy.

Blazor Web Apphanno anche un componente ImportMap nel contenuto <head> che esegue il rendering di un tag di <script> mappa di importazione inline. Per modificare i criteri per consentire il caricamento della mappa di importazione, vedere la sezione Risoluzione delle violazioni CSP con l'integrità della sottorisorsa (SRI) o un nonce crittografico.

Aggiungere script-src e style-src hash aggiuntivi come richiesto dall'app. Durante lo sviluppo, usa uno strumento online o gli strumenti di sviluppo del browser per calcolare gli hash. Ad esempio, il seguente errore della console degli strumenti del browser riporta l'hash per uno script obbligatorio non coperto dalla politica:

Rifiutato di eseguire script inline perché viola la seguente direttiva della politica di sicurezza dei contenuti: " ... ". La parola chiave "unsafe-inline", un hash ('sha256-v8v3RKRPmN4odZ1CWM5gw80QKPCCWMcpNeOmimNL2AA=') o un nonce ('nonce-...') sono necessari per abilitare l'esecuzione in line.

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

Per indicazioni su come applicare una Content Security Policy a un'app nel codice C# all'avvio, vedere ASP.NET Core Blazor startup.

App client lato Blazor

L'esempio seguente è un punto di partenza per un ulteriore sviluppo. Nel <head> contenuto, applicare le direttive descritte nella sezione Direttive politiche:

<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';
    connect-src 'none';
    upgrade-insecure-requests">

Aggiungere script-src e style-src hash aggiuntivi come richiesto dall'app. Durante lo sviluppo, usa uno strumento online o gli strumenti di sviluppo del browser per calcolare gli hash. Ad esempio, l'errore nella console degli strumenti del browser seguente segnala l'hash di uno script obbligatorio non coperto dalla politica.

Rifiutato di eseguire script inline perché viola la seguente direttiva della politica di sicurezza dei contenuti: " ... ". La parola chiave "unsafe-inline", un hash ('sha256-v8v3RKRPmN4odZ1CWM5gw80QKPCCWMcpNeOmimNL2AA=') o un nonce ('nonce-...') sono necessari per abilitare l'esecuzione in line.

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

Risoluzione delle violazioni CSP utilizzando l'Integrità delle Sottorisorse (SRI) o un nonce crittografico

Due approcci per la risoluzione delle violazioni CSP, descritte nelle due sezioni successive, sono:

• Integrità delle risorse secondarie (SRI)consigliata
• nonce crittografico

Adotta l'integrità della sottorisorsa (SRI)

L'integrità della sottorisorsa consente ai browser di verificare che le risorse recuperate non vengano manomesse in transito. Un hash crittografico fornito sulla risorsa deve corrispondere all'hash calcolato dal browser per la risorsa recuperata e all'hash elencato nella Content Security Policy (CSP). La compatibilità del browser può essere valutata in Posso usare?Integrità della sottorisorsa.

Nell'esempio seguente per un'app Blazor Server, un'integrità viene calcolata usando uno strumento di terze parti e specificata per lo script Blazor (blazor.server.js) e CSP. Lo script Blazor non cambia in modo dinamico in questo scenario e ha un hash SHA stabile, quindi è possibile impostare come hardcoded il valore dell'attributo integrity.

Avviso

Impostare l'attributo crossorigin su una sottorisorsa caricata da un'origine diversa senza condivisione di risorse tra le origini (CORS). Se l'origine dell'app è diversa dalla posizione in cui viene caricata una sottorisorsa, è necessaria un'intestazione di Access-Control-Allow-Origin che consente la condivisione della risorsa con l'origine richiedente oppure l'attributo crossorigin deve essere applicato al tag della sottorisorsa nell'app. In caso contrario, il browser adotta il criterio "fail-open" per la sottorisorsa, il che significa che la sottorisorsa viene caricata senza controllarne l'integrità.

L'attributo crossorigin non viene aggiunto al tag Blazor<script> nell'esempio seguente perché lo script Blazor viene caricato dall'origine dell'app.

Per ulteriori informazioni, vedere Condivisione delle risorse tra origini e Integrità delle sottorisorse (documentazione MDN).

<!DOCTYPE html>
<html lang="en">
<head>
    <meta http-equiv="Content-Security-Policy" content="
        base-uri 'self';
        default-src 'self';
        img-src data: https:;
        object-src 'none';
        script-src 'sha256-FyuamsHhg0nWZUnu/f5qrt2DlL1XKt5AX+cgRhtxtfg=';
        style-src https:;
        connect-src 'self' http: ws: wss:;
        upgrade-insecure-requests;" />
    ...
</head>
<body>
    ...
    <script src="_framework/blazor.server.js" 
        integrity="sha256-FyuamsHhg0nWZUnu/f5qrt2DlL1XKt5AX+cgRhtxtfg="></script>
</body>
</html>

Nell'esempio seguente per un Blazor Web App (.NET 8 o versione successiva), viene calcolata un'integrità per il componente ImportMap (.NET 9 o versione successiva). Il valore di integrità ImportMap viene calcolato per ogni richiesta dell'app perché il componente ImportMap esegue il rendering di contenuto univoco ogni volta che viene generata la pagina per gli asset con impronta digitale.

La mappa di importazione sottoposta a rendering dal componente ImportMap viene generata dall'app all'origine, quindi l'attributo crossorigin non è incluso nel tag ImportMap. Per ulteriori informazioni, vedere Guida CSP di MDN: Hash e Integrità delle sottorisorse (documentazione MDN).

@using System.Security.Cryptography
<!DOCTYPE html>
<html lang="en">
<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' 'unsafe-hashes' '@integrity'
            'sha256-qnHnQs7NjQNHHNYv/I9cW+I62HzDJjbnyS/OFzqlix0=';
        style-src https:;
        connect-src 'self' http: ws: wss:;
        upgrade-insecure-requests;" />
    ...
    <ImportMap integrity="@integrity" />
    ...
</head>
...
</html>

@code {
    private string? integrity;

    [CascadingParameter]
    public HttpContext? HttpContext { get; set; }

    protected override void OnInitialized()
    {
        var metadata = HttpContext?.GetEndpoint()?.Metadata
            .GetOrderedMetadata<ImportMapDefinition>();
        var utf8 = new System.Text.UTF8Encoding();
        var metadataBytes = utf8.GetBytes(
            metadata?.FirstOrDefault<ImportMapDefinition>()?.ToString()
                .ReplaceLineEndings("\n") ?? string.Empty);
        integrity = 
            $"sha256-{Convert.ToBase64String(SHA256.HashData(metadataBytes))}";
    }
}

Prima di .NET 6, usare .Replace("\r\n", "\n") anziché chiamare ReplaceLineEndings nel codice precedente.

Nota

Se gli attributi aggiuntivi devono essere applicati sull'elemento reso <script> del componente ImportMap, è possibile passare un dizionario di tutti gli attributi al componente ImportMap nella sua proprietà AdditionalAttributes. La coppia nome-valore dell'attributo integrity viene passata nel dizionario con il resto degli attributi passati aggiuntivi.

Adottare un nonce crittografico

Un nonce crittografico (numero usato una volta) consente ai browser di verificare che le risorse recuperate non vengano manomesse durante il transito. Un nonce crittografico a uso singolo fornito dal provider dei servizi di crittografia deve corrispondere al nonce indicato nella risorsa. La compatibilità del browser può essere valutata in Posso usare? Nonce.

Nell'esempio seguente per un Blazor Web App (.NET 8 o versione successiva), viene creato un nonce per il componente ImportMap (.NET 9 o versione successiva) con un valore univoco ogni volta che l'app viene caricata.

Per altre informazioni, vedere Guida CSP di MDN: Nonces e CSP: script-src: Script inline non sicuro (documentazione MDN).

@using System.Security.Cryptography
<!DOCTYPE html>
<html lang="en">
<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' 'unsafe-hashes' 'nonce-@nonce' 
            'sha256-qnHnQs7NjQNHHNYv/I9cW+I62HzDJjbnyS/OFzqlix0=';
        style-src https:;
        connect-src 'self' http: ws: wss:;
        upgrade-insecure-requests;" />
    ...
    <ImportMap nonce="@nonce" />
    ...
</head>
...
</html>

@code {
    private string? nonce;

    protected override void OnInitialized()
    {
        using (var rng = RandomNumberGenerator.Create())
        {
            var nonceBytes = new byte[32];
            rng.GetBytes(nonceBytes);
            nonce = Convert.ToBase64String(nonceBytes);
        }
    }
}

Nota

Se occorre applicare attributi aggiuntivi all'elemento <script> del componente ImportMap, è possibile passare un dizionario contenente tutti gli attributi al componente ImportMap attraverso la proprietà AdditionalAttributes. La coppia nonce name-value viene passata nel dizionario con il resto degli attributi passati aggiuntivi.

Applicare un CSP in ambienti non Development

Quando una CSP è applicata al contenuto di un'appBlazor, interferisce con i test locali nell'ambiente<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 <meta> della CSP in ambienti non Development.

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 la CSP tramite il componente App, che applica la CSP a tutti i layout dell'app.
• Se è necessario applicare i CSP a diverse aree dell'app, ad esempio un CSP personalizzato solo per le pagine di amministrazione, applicate i CSP in base al layout usando il tag <HeadContent>. Per un'efficacia completa, ogni file di layout dell'app deve adottare l'approccio.
• Il servizio di hosting o il server può fornire una CSP tramite un'intestazione Content-Security-Policy aggiunta alle risposte in uscita dell'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

Nel contenuto del componente App, applica il CSP quando non si è nell'ambiente <head>.

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

In alternativa, applicare i CSP in base al layout nella Components/Layout cartella, come illustrato nell'esempio seguente. Assicurati che ogni layout specifichi una CSP (Content Security Policy).

@inject IHostEnvironment Env

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

Blazor WebAssembly approcci delle app

App Nel componente (App.razor) inserire IWebAssemblyHostEnvironment:

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

Nel contenuto del componente App, applica il CSP quando non si è nell'ambiente <head>.

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

In alternativa, usare il codice precedente, ma applicare i CSP in base al layout nella Layout cartella. Assicurati che ogni layout specifichi una CSP (Content Security Policy).

Limitazioni dei tag meta

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

• frame-ancestors
• report-to
• 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 una politica per un periodo di tempo senza applicare le direttive della politica, impostare l'attributo o il nome dell'intestazione di una politica basata su intestazione del tag <meta> su http-equiv. 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:

• report-to
• 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 nelle tue politiche quando report-to è completamente supportato. Per tenere traccia dell'adozione di report-to, vedere È possibile usare: report-to.

Testare e aggiornare la politica di un'app ad ogni rilascio.

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
• criteri di sicurezza del contenuto livello 3
• Valutatore Google CSP