Proteggere ASP.NET Core Blazor WebAssembly

Le app Blazor WebAssembly vengono protette allo stesso modo delle applicazioni a pagina singola. Esistono diversi approcci per autenticare gli utenti per le applicazioni a pagina singola, ma l'approccio più comune e completo consiste nell'usare un'implementazione basata sul protocollo OAuth 2.0, come OpenID Connect (OIDC).

La Blazor WebAssembly documentazione sulla sicurezza è incentrata principalmente su come eseguire attività di autenticazione e autorizzazione dell'utente. Per la copertura generale dei concetti generali di OAuth 2.0/OIDC, vedere le risorse nella sezione Risorse aggiuntive dell'articolo di panoramica principale.

Sicurezza lato client/spa

La codebase .NET/C# di un'app Blazor WebAssembly viene servita ai client e il codice dell'app non può essere protetto dall'ispezione e dalla manomissione da parte degli utenti. Non inserire mai nulla di natura segreta in un'app Blazor WebAssembly , ad esempio codice .NET/C# privato, chiavi di sicurezza, password o qualsiasi altro tipo di informazioni riservate.

Per proteggere il codice .NET/C# e usare ASP.NET funzionalità di protezione dei dati di base per proteggere i dati, usare un'API Web ASP.NET Core sul lato server. Chiedere all'app sul lato client di chiamare l'API Web lato Blazor WebAssembly server per proteggere le funzionalità e l'elaborazione dei dati delle app. Per altre informazioni, vedere Chiamare un'API Web da un'app ASP.NET Core Blazor e gli articoli in questo nodo.

Libreria di autenticazione

Blazor WebAssemblysupporta l'autenticazione e l'autorizzazione delle app tramite OIDC tramite la libreria tramite la Microsoft.AspNetCore.Components.WebAssembly.Authenticationpiattaforma MicrosoftIdentity. La libreria fornisce un set di primitive per facilitare l'autenticazione con back-end ASP.NET Core. La libreria può eseguire l'autenticazione con qualsiasi provider Identity di terze parti che supporta OIDC, denominati provider OpenID (OP).

Il supporto dell'autenticazione nella Blazor WebAssembly libreria (Authentication.js) è basato su Microsoft Authentication Library (MSAL, msal.js), che viene usato per gestire i dettagli del protocollo di autenticazione sottostante. La Blazor WebAssembly libreria supporta solo il flusso del codice di autorizzazione PKCE (Proof Key for Code Exchange). La concessione implicita non è supportata.

Sono disponibili altre opzioni per l'autenticazione delle applicazioni a pagina singola, ad esempio l'uso di cookie SameSite. Tuttavia, la progettazione di progettazione di Blazor WebAssembly usa OAuth e OIDC come opzione migliore per l'autenticazione nelle Blazor WebAssembly app. L'autenticazione basata su token basata su Token Web JSON (JWT) è stata preferita all'autenticazione basata su cookie per motivi funzionali e di sicurezza:

• L'uso di un protocollo basato su token offre una superficie di attacco più piccola, perché i token non vengono inviati in tutte le richieste.
• Gli endpoint server non richiedono la protezione da richieste intersito false perché i token vengono inviati in modo esplicito. In questo modo è possibile ospitare app Blazor WebAssembly insieme ad app MVC o Razor Pages.
• I token hanno autorizzazioni più restrittive rispetto ai cookie. Ad esempio, i token non possono essere usati per gestire l'account utente o modificare la password di un utente, a meno che tale funzionalità non venga implementata in modo esplicito.
• I token hanno una durata breve, un'ora per impostazione predefinita, che limita la finestra di attacco. I token possono anche essere revocati in qualsiasi momento.
• I token JWT autonomi offrono garanzie al client e al server per il processo di autenticazione. Ad esempio, un client ha i mezzi per rilevare e convalidare che i token ricevuti siano legittimi e siano stati generati come parte di un determinato processo di autenticazione. Se una terza parte tenta di cambiare un token durante il processo di autenticazione, il client può rilevare il token sostituito ed evitare di usarlo.
• I token con OAuth e OIDC non si basano sul comportamento corretto dell'agente utente per garantire che l'app sia sicura.
• I protocolli basati su token, ad esempio OAuth e OIDC, consentono di autenticare e autorizzare gli utenti in app Webassembly autonome Blazor con lo stesso set di caratteristiche di sicurezza.

Importante

Per le versioni di ASP.NET Core che adottano Duende Identity Server nei Blazor modelli di progetto, Duende Software potrebbe richiedere il pagamento di una tariffa di licenza per l'uso in produzione di Duende Identity Server. Per altre informazioni, vedere Eseguire la migrazione da ASP.NET Core 5.0 a 6.0.

Processo di autenticazione con OIDC

La libreria Microsoft.AspNetCore.Components.WebAssembly.Authentication offre diverse primitive per implementare l'autenticazione e l'autorizzazione usando OIDC. In termini generali, l'autenticazione funziona come segue:

• Quando un utente anonimo seleziona il pulsante di accesso o richiede un componente o una Razor pagina con l'attributo[Authorize] applicato, l'utente viene reindirizzato alla pagina di accesso dell'app ()./authentication/login
• Nella pagina di accesso la libreria di autenticazione prepara un reindirizzamento all'endpoint di autorizzazione. L'endpoint di autorizzazione è esterno all'app Blazor WebAssembly e può essere ospitato in un'origine separata. L'endpoint è responsabile di determinare se l'utente è autenticato e di emettere uno o più token in risposta. La libreria di autenticazione fornisce un callback di accesso per ricevere la risposta di autenticazione.
  • Se l'utente non è autenticato, l'utente viene reindirizzato al sistema di autenticazione sottostante, in genere ASP.NET Core Identity.
  • Se l'utente è già stato autenticato, l'endpoint di autorizzazione genera i token appropriati e reindirizza il browser all'endpoint di callback di accesso (/authentication/login-callback).
• Quando l'app Blazor WebAssembly carica l'endpoint di callback di accesso (/authentication/login-callback), viene elaborata la risposta di autenticazione.
  • Se il processo di autenticazione viene completato correttamente, l'utente viene autenticato e, facoltativamente, viene indirizzato all'URL protetto originale richiesto dall'utente.
  • Se il processo di autenticazione non riesce per qualsiasi motivo, l'utente viene inviato alla pagina di accesso non riuscita (/authentication/login-failed), dove viene visualizzato un errore.

Componente Authentication

Il componente Authentication (Authentication.razor) gestisce le operazioni di autenticazione remota e consente all'app di:

• Configurare le route dell'app per gli stati di autenticazione.
• Impostare il contenuto dell'interfaccia utente per gli stati di autenticazione.
• Gestire lo stato di autenticazione.

Le azioni di autenticazione, ad esempio la registrazione o l'accesso di un utente, vengono passate al componente Blazor del framework RemoteAuthenticatorViewCore<TAuthenticationState>, che mantiene e controlla lo stato tra le operazioni di autenticazione.

Per altre informazioni ed esempi, vedere Scenari di sicurezza aggiuntivi per ASP.NET Core Blazor WebAssembly.

Autorizzazione

Nelle app Blazor WebAssembly i controlli di autorizzazione possono essere ignorati perché tutto il codice sul lato client può essere modificato dagli utenti. Lo stesso vale per tutte le tecnologie per app sul lato client, tra cui i framework JavaScript SPA o le app native per qualsiasi sistema operativo.

Eseguire sempre i controlli di autorizzazione nel server all'interno degli eventuali endpoint dell'API a cui accede l'app sul lato client.

Personalizzare l'autenticazione

Blazor WebAssembly fornisce metodi per aggiungere e recuperare parametri aggiuntivi per la libreria di autenticazione sottostante per eseguire operazioni di autenticazione remota con provider di identità esterni.

Per passare parametri aggiuntivi, NavigationManager supporta il passaggio e il recupero dello stato di immissione della cronologia durante l'esecuzione di modifiche alla posizione esterna. Per ulteriori informazioni, vedi le seguenti risorse:

• BlazorArticolo concetti fondamentali sul>routing e sulla navigazione
  • Stato della cronologia degli spostamenti
  • Opzioni di spostamento
• Documentazione di MDN: API cronologia

Lo stato archiviato dall'API History offre i vantaggi seguenti per l'autenticazione remota:

• Lo stato passato all'endpoint dell'app protetta è associato agli spostamenti eseguiti per autenticare l'utente nell'endpoint authentication/login.
• Viene evitato lavoro aggiuntivo per la codifica e la decodifica dei dati.
• La superficie di attacco è ridotta. A differenza dell'uso della stringa di query per archiviare lo stato di spostamento, uno spostamento di primo livello o un'influenza da un'origine diversa non può impostare lo stato archiviato dall'API Cronologia.
• La voce di cronologia viene sostituita al completamento dell'autenticazione, quindi lo stato associato alla voce di cronologia viene rimosso e non richiede la pulizia.

InteractiveRequestOptions rappresenta la richiesta al provider di identità per l'accesso o il provisioning di un token di accesso.

NavigationManagerExtensions fornisce il metodo NavigateToLogin per un'operazione di accesso e NavigateToLogout per un'operazione di disconnessione. I metodi chiamano NavigationManager.NavigateTo, impostando lo stato della voce della cronologia con un'istanza di InteractiveRequestOptions passata o una nuova istanza di InteractiveRequestOptions creata dal metodo per:

• Un utente che esegue l'accesso (InteractionType.SignIn) con l'URI corrente per l'URL restituito.
• Un utente che si disconnette (InteractionType.SignOut) con l'URL restituito.

Gli scenari di autenticazione seguenti sono illustrati nell'articolo Scenari di sicurezza aggiuntivi per ASP.NET Core Blazor WebAssembly:

• Personalizzare il processo di accesso
• Disconnettersi con un URL restituito personalizzato
• Personalizzare le opzioni prima di ottenere un token in modo interattivo
• Personalizzare le opzioni quando si usa un IAccessTokenProvider
• Ottenere il percorso di accesso dalle opzioni di autenticazione

Richiedere l'autorizzazione per l'intera app

Applicare l'attributo (documentazione api) a ogni Razor componente dell'app usando uno degli approcci seguenti:[Authorize]

• Nel file Imports dell'app aggiungere una direttiva @using per lo spazio dei nomi Microsoft.AspNetCore.Authorization con una direttiva @attribute per l'attributo[Authorize].

  _Imports.razor:

  @using Microsoft.AspNetCore.Authorization
  @attribute [Authorize]
  

  Consentire l'accesso anonimo al Authentication componente per consentire il reindirizzamento al provider di identità. Aggiungere il codice seguente Razor al componente Authentication nella relativa direttiva @page.

  Authentication.razor:

  @using Microsoft.AspNetCore.Components.WebAssembly.Authentication
  @attribute [AllowAnonymous]
  

• Aggiungere l'attributo a ogni Razor componente nella @page direttiva :

  @using Microsoft.AspNetCore.Authorization
  @attribute [Authorize]
  

Nota

L'impostazione di un AuthorizationOptions.FallbackPolicy su un criterio con RequireAuthenticatedUsernon è supportata.

Usare una registrazione dell'app del provider di identità per ogni app

Alcuni degli articoli in questa panoramica riguardano Blazor gli scenari di hosting che coinvolgono due o più app. Un'app autonoma Blazor WebAssembly usa l'API Web con utenti autenticati per accedere alle risorse e ai dati del server forniti da un'app server.

Quando questo scenario viene implementato negli esempi di documentazione, vengono usate due registrazioni del provider di identità, una per l'app client e una per l'app server. L'uso di registrazioni separate, ad esempio in MICROSOFT Entra ID, non è strettamente obbligatorio. Tuttavia, l'uso di due registrazioni è una procedura consigliata per la sicurezza perché isola le registrazioni in base all'app. L'uso di registrazioni separate consente anche la configurazione indipendente delle registrazioni client e server.

Token di aggiornamento

Anche se i token di aggiornamento non possono essere protetti nelle Blazor WebAssembly app, possono essere usati se vengono implementati con strategie di sicurezza appropriate.

Per le app autonome Blazor WebAssembly in ASP.NET Core in .NET 6 o versione successiva, è consigliabile usare:

• Flusso del codice di autorizzazione OAuth 2.0 (codice) con chiave di prova per Lo scambio di codice (PKCE).
• Token di aggiornamento con scadenza breve.
• Token di aggiornamento ruotato .
• Token di aggiornamento con scadenza dopo la quale è necessario un nuovo flusso di autorizzazione interattivo per aggiornare le credenziali dell'utente.

Per ulteriori informazioni, vedi le seguenti risorse:

• Token di aggiornamento di Microsoft Identity Platform: durata del token di aggiornamento
• OAuth 2.0 per le app basate su browser (specifica IETF)

Stabilire attestazioni per gli utenti

Le app spesso richiedono attestazioni per gli utenti in base a una chiamata dell'API Web a un server. Ad esempio, le attestazioni vengono usate di frequente per stabilire l'autorizzazione in un'app. In questi scenari, l'app richiede un token di accesso per accedere al servizio e usa il token per ottenere i dati utente per la creazione di attestazioni.

Per esempi, vedere le risorse seguenti:

• Scenari aggiuntivi: personalizzare l'utente
• ASP.NET Core Blazor WebAssembly con gruppi e ruoli di Microsoft Entra ID

Supporto di pre-ordinamento

Il rendering preliminare non è supportato per gli endpoint di autenticazione (segmento di percorso /authentication/).

Per altre informazioni, vedere Scenari di sicurezza aggiuntivi per ASP.NET Core Blazor WebAssembly.

Servizio app di Azure in Linux con Identity Server

Specificare l'autorità emittente in modo esplicito durante la distribuzione in Servizio app di Azure in Linux con Identity Server.

Per altre informazioni, vedere Usare Identity per proteggere un back-end dell'API Web per le applicazioni a pagina singola.

Autenticazione di Windows

Non è consigliabile usare l'autenticazione di Windows con Blazor Webassembly o con qualsiasi altro framework per applicazioni a pagina singola. È consigliabile usare protocolli basati su token anziché l'autenticazione di Windows, ad esempio OIDC con Active Directory Federation Services (ADFS).

Se l'autenticazione di Windows viene usata con Blazor Webassembly o con qualsiasi altro framework per applicazioni a pagina singola, sono necessarie misure aggiuntive per proteggere l'app da token di richieste intersito false. Gli stessi problemi che si applicano a cookies si applicano all'autenticazione di Windows con l'aggiunta che l'autenticazione di Windows non offre un meccanismo per impedire la condivisione del contesto di autenticazione tra le origini. Le app che usano l'autenticazione di Windows senza protezione aggiuntiva da CSRF devono essere limitate almeno alla intranet di un'organizzazione e non devono essere usate su Internet aperto.

Per altre informazioni, vedere Prevenire attacchi tramite richieste intersito false (XSRF/CSRF) in ASP.NET Core.

Proteggere un hub SignalR

Per proteggere un SignalR hub nel progetto API server, applicare l'attributo[Authorize] alla classe hub o ai metodi della classe hub.

In un progetto client con prerendering, ad esempio ospitato Blazor WebAssembly (ASP.NET Core in .NET 7 o versioni precedenti) o un'app Blazor Web (ASP.NET Core in .NET 8 o versione successiva), vedere le linee guida in ASP.NET Core guidance (Indicazioni su ASP.NET CoreBlazorSignalR).

In un componente del progetto client senza eseguire la pre-gestione, ad esempio app autonome Blazor WebAssemblyo non basate su browser, fornire un token di accesso alla connessione hub, come illustrato nell'esempio seguente. Per altre informazioni, vedere Autenticazione e autorizzazione in ASP.NET Core SignalR.

@using Microsoft.AspNetCore.Components.WebAssembly.Authentication
@inject IAccessTokenProvider TokenProvider
@inject NavigationManager Navigation

...

var tokenResult = await TokenProvider.RequestAccessToken();

if (tokenResult.TryGetToken(out var token))
{
    hubConnection = new HubConnectionBuilder()
        .WithUrl(Navigation.ToAbsoluteUri("/chathub"), 
            options => { options.AccessTokenProvider = () => Task.FromResult(token?.Value); })
        .Build();

  ...
}

Registrazione

Questa sezione si applica alle Blazor WebAssembly app in ASP.NET Core in .NET 7 o versione successiva.

Per abilitare la registrazione di debug o traccia, vedere la sezione Registrazione dell'autenticazione (Blazor WebAssembly) in una versione 7.0 o successiva dell'articolo registrazione di ASP.NET CoreBlazor.

Sandbox WebAssembly

La sandbox WebAssembly limita l'accesso all'ambiente del sistema che esegue codice WebAssembly, incluso l'accesso ai sottosistemi I/O, all'archiviazione e alle risorse di sistema e al sistema operativo. L'isolamento tra il codice WebAssembly e il sistema che esegue il codice rende WebAssembly un framework di codifica sicuro per i sistemi. Tuttavia, WebAssembly è vulnerabile agli attacchi sul canale laterale a livello di hardware. Si applicano precauzioni normali e due diligence nell'hardware di origine e l'applicazione di limitazioni all'accesso all'hardware.

WebAssembly non è di proprietà o gestito da Microsoft.

Per altre informazioni, vedere le risorse W3C seguenti:

• WebAssembly: Sicurezza
• Specifica WebAssembly: Considerazioni sulla sicurezza
• W3C WebAssembly Community Group: Commenti e problemi: il collegamento W3C WebAssembly Community Group viene fornito solo per riferimento, rendendo chiaro che le vulnerabilità e i bug di sicurezza di WebAssembly vengono corretti regolarmente, spesso segnalati e risolti dal browser. Non inviare commenti e suggerimenti o segnalazioni Blazor di bug al gruppo della community W3C WebAssembly.Blazor Il feedback deve essere segnalato all'unità prodotto Microsoft ASP.NET Core. Se l'unità prodotto Microsoft determina che esiste un problema sottostante con WebAssembly, esegue i passaggi appropriati per segnalare il problema al gruppo della community W3C WebAssembly.

Linee guida per l'implementazione

Gli articoli in questa panoramica forniscono informazioni sull'autenticazione degli utenti nelle app Blazor WebAssembly con provider specifici.

App Blazor WebAssembly autonome:

• Indicazioni generali per i provider OIDC e la libreria di autenticazione WebAssembly
• Account Microsoft
• ID Microsoft Entra (ME-ID)
• Azure Active Directory (AAD) B2C

Altre indicazioni sulla configurazione sono disponibili negli articoli seguenti:

• Scenari di sicurezza aggiuntivi per ASP.NET Core Blazor WebAssembly
• Usare l'API Graph con ASP.NET Core Blazor WebAssembly

Usare il flusso del codice di autorizzazione con PKCE

Microsoft Identity Platform Microsoft Authentication Library per JavaScript (MSAL) v2.0 o versione successiva fornisce il supporto per il flusso del codice di autorizzazione con la chiave di prova per Lo scambio di codice (PKCE) e la condivisione di risorse tra le origini (CORS) per applicazioni a pagina singola, tra cui Blazor.

Microsoft non consiglia di usare la concessione implicita.

Per ulteriori informazioni, vedi le seguenti risorse:

• Supporto del flusso di autenticazione in MSAL: Concessione implicita
• Flusso di concessione implicita e Microsoft Identity Platform: preferisce il flusso del codice di autenticazione
• Flusso del codice di autorizzazione OAuth 2.0 e Microsoft Identity Platform

Risorse aggiuntive

• Documentazione di Microsoft Identity Platform
  • Documentazione generale
  • Token di accesso
• Configurare ASP.NET Core per l'utilizzo di server proxy e servizi di bilanciamento del carico
  • Uso del middleware delle intestazioni inoltrate per mantenere le informazioni sullo schema HTTPS tra server proxy e reti interne.
  • Altri scenari e casi d'uso, tra cui la configurazione manuale dello schema, le modifiche del percorso della richiesta per il routing corretto delle richieste e l'inoltro dello schema delle richieste per i proxy inversi Linux e non IIS.
• Prerendering con l'autenticazione
• WebAssembly: Sicurezza
• Specifica WebAssembly: Considerazioni sulla sicurezza