Skydda ASP.NET Core Blazor WebAssembly

Blazor WebAssembly appar skyddas på samma sätt som ensidesprogram (SPA). Det finns flera metoder för att autentisera användare till SPA, men den vanligaste och mest omfattande metoden är att använda en implementering baserat på OAuth 2.0-protokoll, till exempel OpenID Connect (OIDC).

Den Blazor WebAssembly säkerhetsdokumentationen fokuserar främst på hur du utför användarautentiserings- och auktoriseringsuppgifter. Allmän koncepttäckning för OAuth 2.0/OIDC finns i resurserna i huvudöversiktsartikelns Avsnittet Ytterligare resurser.

Säkerhet på klientsidan/SPA för känsliga data och autentiseringsuppgifter

En Blazor WebAssembly-apps .NET/C#-kodbas levereras till klienterna, och appens kod kan inte skyddas från granskning och manipulering av användare. Placera aldrig känsliga data i en Blazor WebAssembly app, till exempel apphemligheter, anslutningssträngar, lösenord, säkerhetsnycklar och privat .NET/C#-kod.

Följande tekniker är användbara för att lagra känsliga data, som kan användas tillsammans i samma app för att dela upp ansvarsområden för lagring av data mellan utvecklings- och mellanlagrings-/produktionsmiljöer:

• Secret Manager-verktyget: Används endast i det lokala utvecklingssystemet.
• Azure Key Vault-: Kan användas för lokalt körande appar i utvecklingsmiljön och för distributioner i Staging och Produktion.

Exempel på föregående metoder finns i Kontobekräftelse och lösenordsåterställning i ASP.NET Core Blazor WebAssembly med ASP.NET Core Identity.

Webb-API-begäranden

Om du vill skydda .NET/C#-kod och data använder du ASP.NET Core Data Protection-funktioner med ett serverbaserat ASP.NET Core backend-webb-API. Klientsidans Blazor WebAssembly app anropar webb-API:et på serversidan för säkra appfunktioner och databearbetning. Mer information finns i Anropa ett webb-API från en ASP.NET Core Blazor-app samt artiklarna och exemplen i den här dokumentationsnoden.

Blazor WebAssembly appar hindras ofta från att göra direkta anrop över ursprung till webb-API:er på grund av CORS-säkerhet (Cross-Origin Request Sharing). Ett typiskt undantag ser ut så här:

Åtkomst till att hämta på {URL} från ursprungethttps://localhost:{PORT}' har blockerats av CORS-principen: Inget "Access-Control-Allow-Origin"-huvud finns på den begärda resursen. Om ett ogenomskinligt svar uppfyller dina behov, ställ in begärans läge på "no-cors" för att hämta resursen med CORS inaktiverat.

Även om du anropar SetBrowserRequestMode med ett BrowserRequestMode fält i NoCors (1) som försöker kringgå föregående undantag misslyckas begäran vanligtvis på grund av CORS-begränsningar för webb-API:ets ursprung, till exempel en begränsning som endast tillåter anrop från specifika ursprung eller en begränsning som förhindrar JavaScript-fetch begäranden från en webbläsare. Det enda sättet sådana anrop kan lyckas är om webb-API:et du anropar tillåter att ditt ursprung kan anropa dess ursprung med korrekt CORS-konfiguration. De flesta externa webb-API:er tillåter inte att du konfigurerar deras CORS-principer. Anta någon av följande strategier för att hantera den här begränsningen:

• Bibehåll ditt eget serverbaserade ASP.NET Core-backend-webb-API. Klientsidans Blazor WebAssembly app anropar webb-API:et på serversidan och webb-API:et skickar begäran från sin serverbaserade C#-kod (inte en webbläsare) till det externa webb-API:et med rätt CORS-huvuden, vilket returnerar resultatet till din Blazor WebAssembly app på klientsidan.

• Använd en proxytjänst för att skicka begäran från Blazor WebAssembly app på klientsidan till det externa webb-API:et. Proxytjänsten använder en app på serversidan för att göra begäran åt klienten och returnerar resultatet när anropet har slutförts. I följande exempel baserat på CloudFlares CORS PROXYär {REQUEST URI} platshållaren för begärans URI:

  @using System.Net
  @inject IHttpClientFactory ClientFactory
  
  ...
  
  @code {
      public async Task CallApi()
      {
          var client = ClientFactory.CreateClient();
  
          var urlEncodedRequestUri = WebUtility.UrlEncode("{REQUEST URI}");
  
          var request = new HttpRequestMessage(HttpMethod.Get, 
              $"https://corsproxy.io/?{urlEncodedRequestUri}");
  
          var response = await client.SendAsync(request);
  
          ...
      }
  }
  

Autentiseringsbibliotek

Blazor WebAssembly stöder autentisering och auktorisering av appar med hjälp av OIDC via Microsoft.AspNetCore.Components.WebAssembly.Authentication-biblioteket med hjälp av Microsofts identitetsplattform. Biblioteket innehåller en uppsättning primitiver för sömlös autentisering mot ASP.NET Core-serverdelar. Biblioteket kan autentisera mot alla tredje parts Identity Provider (IP) som stöder OIDC, som kallas OpenID Providers (OP).

Autentiseringsstödet i Blazor WebAssembly-biblioteket (Authentication.js) bygger på Microsoft Authentication Library (MSAL, msal.js), som används för att hantera information om underliggande autentiseringsprotokoll. Blazor WebAssembly-biblioteket stöder endast Auktoriseringskodflödet Proof Key for Code Exchange (PKCE). Implicit beviljande stöds inte.

Det finns andra alternativ för att autentisera SPA:er, till exempel användning av SameSite-cookies. Den tekniska utformningen av Blazor WebAssembly använder dock OAuth och OIDC som det bästa alternativet för autentisering i Blazor WebAssembly appar. tokenbaserad autentisering baserat på JSON-webbtoken (JWT) valdes över cookie-baserad autentisering av funktionella och säkerhetsproblem:

• Att använda ett tokenbaserat protokoll ger färre sårbarheter eftersom token inte skickas i alla begäranden.
• Token skickas uttryckligen till servern, så serverslutpunkter kräver inte skydd mot CSRF(Cross-Site Request Forgery). På så sätt kan du vara värd för Blazor WebAssembly appar tillsammans med MVC- eller Razor-sidappar.
• Token har smalare behörigheter än cookies. Token kan till exempel inte användas för att hantera användarkontot eller ändra en användares lösenord om inte sådana funktioner uttryckligen implementeras.
• Token har en kort livslängd, en timme, vilket begränsar attackfönstret. Token kan också återkallas när som helst.
• Fristående JWTs erbjuder garantier till klienten och servern om autentiseringsprocessen. En klient har till exempel möjlighet att identifiera och verifiera att de token som den tar emot är legitima och har genererats som en del av en viss autentiseringsprocess. Om en tredje part försöker växla en token mitt i autentiseringsprocessen kan klienten identifiera den växlade token och undvika att använda den.
• Token med OAuth och OIDC förlitar sig inte på att användaragenten beter sig korrekt för att säkerställa att appen är säker.
• Tokenbaserade protokoll, till exempel OAuth och OIDC, gör det möjligt att autentisera och auktorisera användare i fristående Blazor Webassembly-appar med samma uppsättning säkerhetsegenskaper.

Viktig

För versioner av ASP.NET Core som använder Duende Identity Server i Blazor projektmallar kan Duende Software kräva att du betalar en licensavgift för produktionsanvändning av Duende Identity Server. Mer information finns i Migrera från ASP.NET Core 5.0 till 6.0.

Autentiseringsprocess med OIDC

Biblioteket Microsoft.AspNetCore.Components.WebAssembly.Authentication erbjuder flera primitiver för att implementera autentisering och auktorisering med hjälp av OIDC. I stora drag fungerar autentiseringen på följande sätt:

• När en anonym användare väljer inloggningsknappen eller begär en Razor komponent eller sida med attributet [Authorize] tillämpas omdirigeras användaren till appens inloggningssida (/authentication/login).
• På inloggningssidan förbereder autentiseringsbiblioteket för en omdirigering till auktoriseringsslutpunkten. Auktoriseringsslutpunkten ligger utanför Blazor WebAssembly-appen och kan ligga på ett separat ursprung. Slutpunkten ansvarar för att avgöra om användaren är autentiserad och för att utfärda en eller flera token som svar. Autentiseringsbiblioteket tillhandahåller ett återanrop för inloggning för att ta emot autentiseringssvaret.
  • Om användaren inte autentiseras omdirigeras användaren till det underliggande autentiseringssystemet, som vanligtvis ASP.NET Core Identity.
  • Om användaren redan har autentiserats genererar auktoriseringsslutpunkten lämpliga token och omdirigerar webbläsaren tillbaka till slutpunkten för återanrop för inloggning (/authentication/login-callback).
• När appen Blazor WebAssembly läser in inloggningsåteranropsslutpunkten (/authentication/login-callback) bearbetas autentiseringssvaret.
  • Om autentiseringsprocessen har slutförts autentiseras användaren och kan också skickas tillbaka till den ursprungliga skyddade URL:en som användaren begärde.
  • Om autentiseringsprocessen misslyckas av någon anledning skickas användaren till inloggningssidan (/authentication/login-failed), där ett fel visas.

Authentication-komponent

Komponenten Authentication (Authentication.razor) hanterar fjärrautentiseringsåtgärder och tillåter appen att:

• Konfigurera appvägar för autentiseringstillstånd.
• Ange användargränssnittsinnehåll för autentiseringstillstånd.
• Hantera autentiseringstillstånd.

Autentiseringsåtgärder, till exempel registrering eller inloggning av en användare, skickas till Blazor ramverkets RemoteAuthenticatorViewCore<TAuthenticationState> komponent, som bevarar och styr tillståndet för autentiseringsåtgärder.

Mer information och exempel finns i ASP.NET Core Blazor WebAssembly ytterligare säkerhetsscenarier.

Tillstånd

I Blazor WebAssembly appar kan auktoriseringskontroller kringgås eftersom all kod på klientsidan kan ändras av användarna. Detsamma gäller för alla apptekniker på klientsidan, inklusive JavaScript SPA-ramverk eller interna appar för alla operativsystem.

Utför alltid auktoriseringskontroller på servern inom alla API-slutpunkter som används av din app på klientsidan.

Anpassa autentisering

Blazor WebAssembly tillhandahåller metoder för att lägga till och hämta ytterligare parametrar för det underliggande autentiseringsbiblioteket för att utföra fjärrautentiseringsåtgärder med externa identitetsprovidrar.

Om du vill skicka ytterligare parametrar har NavigationManager stöd för att skicka och hämta historikens inmatningstillstånd när du utför ändringar på den externa platsen. Mer information finns i följande resurser:

• Blazor Fundamentals>Routning och navigering artikeln
  • tillstånd för navigationshistorik
  • Navigeringsalternativ
• MDN-dokumentation: History API

Tillståndet som lagras av historik-API:et ger följande fördelar för fjärrautentisering:

• Tillståndet som skickas till slutpunkten för den skyddade appen är kopplat till navigeringen som utförs för att autentisera användaren vid authentication/login slutpunkten.
• Extra arbetskodning och avkodningsdata undviks.
• Sårbarheter minskas. Till skillnad från att använda frågesträngen för att lagra navigeringstillstånd kan en navigering på den översta nivån eller påverkan från ett annat ursprung inte ange tillståndet som lagras av API:et för historik.
• Historikposten ersätts vid lyckad autentisering, så tillståndet som är kopplat till historikposten tas bort och kräver inte rensning.

InteractiveRequestOptions representerar begäran till identitetsprovidern för att logga in eller etablera en åtkomsttoken.

NavigationManagerExtensions tillhandahåller NavigateToLogin-metoden för en inloggningsåtgärd och NavigateToLogout för en utloggningsåtgärd. Metoderna anropar NavigationManager.NavigateTooch anger historikens posttillstånd med en överförd InteractiveRequestOptions eller en ny InteractiveRequestOptions instans som skapats av metoden.

• En användare som loggar in (InteractionType.SignIn) med aktuell URI för retur-URL:en.
• En användare loggar ut (InteractionType.SignOut) med retur-URL:en.

Följande autentiseringsscenarier beskrivs i artikeln ASP.NET Core Blazor WebAssembly ytterligare säkerhetsscenarier:

• Anpassa inloggningsprocessen
• Logga ut med en anpassad retur-URL
• Anpassa alternativ innan du hämtar en token interaktivt
• Anpassa alternativ när du använder en IAccessTokenProvider
• Hämta inloggningssökvägen från autentiseringsalternativen

Kräv auktorisering för hela appen

Använd [Authorize]-attributet (API-dokumentation) på varje Razor komponent i appen med hjälp av en av följande metoder:

• I appens importfil lägger du till ett @using-direktiv för Microsoft.AspNetCore.Authorization-namnområdet med ett @attribute-direktiv för attributet [Authorize].

  _Imports.razor:

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

  Tillåt anonym åtkomst till komponenten Authentication för att tillåta omdirigering till identitetsprovidern. Lägg till följande Razor kod i komponenten Authentication enligt dess @page-direktiv.

  Authentication.razor:

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

• Lägg till attributet för varje Razor komponent i @page-direktivet:

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

Not

Att konfigurera en AuthorizationOptions.FallbackPolicy till en policy med RequireAuthenticatedUser stöds inte .

Använd en appregistrering för identitetsleverantör per app

Några av artiklarna i den här Översikt gäller Blazor värdscenarier som omfattar två eller flera appar. En fristående Blazor WebAssembly app använder webb-API med autentiserade användare för att komma åt serverresurser och data som tillhandahålls av en serverapp.

När det här scenariot implementeras i dokumentationsexempel används två registreringar av identitetsprovider, en för klientappen och en för serverappen. Det är inte absolut nödvändigt att använda separata registreringar, till exempel i Microsoft Entra-ID. Att använda två registreringar är dock en säkerhetsmetod eftersom den isolerar registreringarna per app. Genom att använda separata registreringar kan du också konfigurera klient- och serverregistreringar oberoende.

Uppdatera token

Även om uppdateringstoken inte kan skyddas i Blazor WebAssembly appar kan de användas om du implementerar dem med lämpliga säkerhetsstrategier.

För fristående Blazor WebAssembly appar i ASP.NET Core i .NET 6 eller senare rekommenderar vi att du använder:

• OAuth 2.0 Authorization Code flow (Code) med Proof Key for Code Exchange (PKCE).
• En uppdateringstoken som har en kort förfallotid.
• En roterad uppfräschnings-token.
• En uppdateringstoken med ett förfallodatum varefter ett nytt interaktivt auktoriseringsflöde krävs för att uppdatera användarens autentiseringsuppgifter.

Mer information finns i följande resurser:

• Uppdateringstoken för Microsofts identitetsplattform: Uppdateringstokens livslängd
• OAuth 2.0 för Browser-Based Apps (IETF-specifikation)

Upprätta anspråk för användare

Appar kräver ofta anspråk för användare baserat på ett webb-API-anrop till en server. Anspråk används till exempel ofta för att upprätta auktorisering i en app. I dessa scenarier begär appen en åtkomsttoken för att få åtkomst till tjänsten och använder token för att hämta användardata för att skapa anspråk.

Exempel finns i följande resurser:

• Ytterligare scenarier: Anpassa användarens
• ASP.NET Core Blazor WebAssembly med Microsoft Entra ID-grupper och roller

Stöd för förinläsning

Prerendering stöds inte för autentiseringsslutpunkter (/authentication/ sökvägssegment).

Mer information finns i ASP.NET Core Blazor WebAssembly ytterligare säkerhetsscenarier.

Azure App Service på Linux med Identity Server

Ange utfärdaren explicit när du distribuerar till Azure App Service på Linux med Identity Server.

Mer information finns i Använda Identity för att skydda en webb-API-serverdel för SPA:er.

Windows-autentisering

Vi rekommenderar inte att du använder Windows-autentisering med Blazor Webassembly eller med något annat SPA-ramverk. Vi rekommenderar att du använder tokenbaserade protokoll i stället för Windows-autentisering, till exempel OIDC med Active Directory Federation Services (ADFS).

Om Windows-autentisering används med Blazor Webassembly eller med något annat SPA-ramverk krävs ytterligare åtgärder för att skydda appen från CSRF-token (cross-site request forgery). Samma problem som gäller för cookies gäller för Windows-autentisering med tillägget att Windows-autentisering inte erbjuder någon mekanism för att förhindra delning av autentiseringskontexten mellan ursprung. Appar som använder Windows-autentisering utan ytterligare skydd mot CSRF bör åtminstone begränsas till en organisations intranät och inte användas på det öppna Internet.

Mer information finns i Förhindra XSRF-/CSRF-attacker (Cross-Site Request Forgery) i ASP.NET Core.

Skydda ett SignalR nav

Om du vill skydda en SignalR hubb i server-API-projektet använder du attributet [Authorize] på hubbklassen eller på hubbklassens metoder.

I ett klientprojekt med prerendering, till exempel värdbaserade Blazor WebAssembly (ASP.NET Core i .NET 7 eller tidigare) eller en Blazor Web App (ASP.NET Core i .NET 8 eller senare), se vägledningen i ASP.NET Core BlazorSignalR vägledning.

I en klientprojektkomponent utan prerendering, till exempel fristående Blazor WebAssemblyeller appar som inte är webbläsarappar, anger du en åtkomsttoken till hubbanslutningen, vilket visas i följande exempel. Mer information finns i -autentisering och auktorisering i 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();

  ...
}

Skogsavverkning

Det här avsnittet gäller för Blazor WebAssembly appar i ASP.NET Core i .NET 7 eller senare.

Information om hur du aktiverar felsökning eller spårningsloggning finns i autentiseringsloggning (Blazor WebAssembly) i en 7.0- eller senare version av ASP.NET Core Blazor-loggning artikeln.

WebAssembly-sandboxen

WebAssembly-sandbox- begränsar åtkomsten till miljön i systemet som kör WebAssembly-kod, inklusive åtkomst till I/O-undersystem, systemlagring och resurser samt operativsystemet. Isoleringen mellan WebAssembly-koden och systemet som kör koden gör WebAssembly till ett säkert kodningsramverk för system. WebAssembly är dock sårbart för sidokanalattacker på maskinvarunivå. Normala försiktighetsåtgärder och due diligence vid inköp av maskinvara och begränsningar för åtkomst till maskinvara gäller.

WebAssembly ägs eller underhålls inte av Microsoft.

Mer information finns i följande W3C-resurser:

• WebAssembly: Säkerhet
• WebAssembly Specification: Säkerhetsöverväganden
• W3C WebAssembly Community Group: Feedback och problem: Länken W3C WebAssembly Community Group tillhandahålls endast som referens, vilket gör det tydligt att WebAssembly säkerhetsrisker och buggar korrigeras kontinuerligt, ofta rapporteras och åtgärdas av webbläsaren. Skicka inte feedback eller buggrapporter på Blazor till W3C WebAssembly Community Group.Blazor feedback ska rapporteras till produktenheten Microsoft ASP.NET Core. Om Microsofts produktenhet fastställer att det finns ett underliggande problem med WebAssembly vidtar de lämpliga åtgärder för att rapportera problemet till W3C WebAssembly Community Group.

Implementeringsvägledning

Artiklar i den här Översikt ge information om hur du autentiserar användare i Blazor WebAssembly appar mot specifika leverantörer.

Fristående Blazor WebAssembly appar:

• Allmän vägledning för OIDC-leverantörer och WebAssembly Authentication Library
• Microsoft-konton
• Microsoft Entra-ID (ME-ID)
• Azure Active Directory (AAD) B2C

Ytterligare konfigurationsvägledning finns i följande artiklar:

• ASP.NET Core Blazor WebAssembly ytterligare säkerhetsscenarier
• Använda Graph API med ASP.NET Core Blazor WebAssembly

Använda auktoriseringskodflödet med PKCE

Microsofts identitetsplattform Microsoft Authentication Library for JavaScript (MSAL) v2.0 eller senare stöder autentiseringskodflödet med Proof Key for Code Exchange (PKCE) och Cross-Origin Resource Sharing (CORS) för enkeltsidesapplikationer, inklusive: Blazor.

Microsoft rekommenderar inte att du använder implicit beviljande.

Mer information finns i följande resurser:

• autentiseringsflödesstöd i MSAL: Implicit beviljande
• Microsofts identitetsplattform och implicita beviljandeflöde: Föredrar autentiseringskodflödet
• Microsofts identitetsplattform och OAuth 2.0-auktoriseringskodflöde

Ytterligare resurser

• Dokumentation om Microsoft identity Platform
  • Allmän dokumentation
  • Åtkomsttoken
• Konfigurera ASP.NET Core att fungera med proxyservrar och lastbalanserare
  • Använda vidarebefordrade huvudmellanprogram för att bevara HTTPS-schemainformation över proxyservrar och interna nätverk.
  • Ytterligare scenarier och användningsfall, inklusive manuell schemakonfiguration, begärandesökvägsändringar för korrekt routning av begäranden och vidarebefordran av begärandeschemat för Linux och icke-IIS omvända proxyservrar.
• Förberäkning med autentisering
• WebAssembly: Säkerhet
• WebAssembly Specification: Säkerhetsaspekter