Sdílet prostřednictvím

Zabezpečení ASP.NET Core Blazor WebAssembly

  • Článek

Poznámka:

Toto není nejnovější verze tohoto článku. Aktuální verzi najdete v tomto článku ve verzi .NET 9.

Upozorňující

Tato verze ASP.NET Core se už nepodporuje. Další informace najdete v zásadách podpory .NET a .NET Core. Aktuální verzi najdete v tomto článku ve verzi .NET 9.

Důležité

Tyto informace se týkají předběžného vydání produktu, který může být podstatně změněn před komerčním vydáním. Microsoft neposkytuje žádné záruky, výslovné ani předpokládané, týkající se zde uváděných informací.

Aktuální verzi najdete v tomto článku ve verzi .NET 9.

Aplikace Blazor WebAssembly jsou zabezpečené stejným způsobem jako jednostránkové aplikace (SPA). Existuje několik přístupů k ověřování uživatelů pro aplikace SPA, ale nejběžnějším a komplexním přístupem je použití implementace založené na protokolu OAuth 2.0, jako je OpenID Connect (OIDC).

Blazor WebAssembly Dokumentace k zabezpečení se primárně zaměřuje na to, jak provádět úlohy ověřování a autorizace uživatelů. Obecné pokrytí konceptů OAuth 2.0/OIDC najdete v části Další zdroje informací v hlavním článku s přehledem.

Zabezpečení citlivých dat a přihlašovacích údajů na straně klienta/SPA

Blazor WebAssembly Základ kódu .NET/C# aplikace se obsluhuje klientům a kód aplikace nemůže být chráněn před kontrolou a manipulací uživatelů. Nikdy neumisťujte přihlašovací údaje ani tajné kódy do Blazor WebAssembly aplikace, jako jsou tajné kódy aplikací, připojovací řetězec, hesla, privátní kód .NET/C# nebo jiná citlivá data.

K ochraně kódu .NET/C# a použití funkcí ASP.NET Core Data Protection k zabezpečení dat použijte webové rozhraní API na straně serveru ASP.NET Core. Požádejte aplikaci na straně Blazor WebAssembly klienta, aby volala webové rozhraní API na straně serveru pro zabezpečené funkce aplikací a zpracování dat. Další informace najdete v tématu Volání webového rozhraní API z aplikace ASP.NET Core Blazor a článků v tomto uzlu.

Pro místní testování vývoje se pro zabezpečení citlivých dat doporučuje nástroj Secret Manager.

Knihovna ověřování

Blazor WebAssemblypodporuje ověřování a autorizaci aplikací pomocí OIDC prostřednictvím Microsoft.AspNetCore.Components.WebAssembly.Authentication knihovny pomocí platformy Microsoftidentity. Knihovna poskytuje sadu primitiv pro bezproblémové ověřování proti back-endům ASP.NET Core. Knihovna může provádět ověření vůči libovolnému zprostředkovateli Identity třetí strany, který podporuje OIDC. Takoví zprostředkovatelé se nazývají zprostředkovatelé OpenID (OP).

Podpora ověřování v knihovně Blazor WebAssembly (Authentication.js) je založená na knihovně Microsoft Authentication Library (MSAL, msal.js), která slouží ke zpracování podrobností základního ověřovacího protokolu. Blazor WebAssembly Knihovna podporuje pouze tok autorizačního kódu PKCE (Proof Key for Code Exchange). Implicitní udělení se nepodporuje.

Existují i další možnosti ověřování přístupových služeb, jako je použití souborů cookie SameSite. Technický návrh Blazor WebAssembly používá OAuth a OIDC jako nejlepší možnost ověřování v Blazor WebAssembly aplikacích. Ověřování založené na tokenech založené na webových tokenech JSON (JWT) bylo zvoleno nad cookieověřováním na základě funkčnosti a zabezpečení z důvodů funkčnosti a zabezpečení:

  • Použití protokolu založeného na tokenu nabízí méně chyb zabezpečení, protože tokeny se neodesílají ve všech požadavcích.
  • Tokeny se explicitně odesílají na server, takže koncové body serveru nevyžadují ochranu proti padělání požadavků mezi weby (CSRF). To vám umožňuje hostovat aplikace Blazor WebAssembly společně s aplikacemi MVC nebo Razor Pages.
  • Tokeny mají užší oprávnění než soubory cookie. Tokeny se například nedají použít ke správě uživatelského účtu nebo ke změně hesla uživatele, pokud není tato funkce explicitně implementována.
  • Tokeny mají krátkou životnost, jednu hodinu, což omezuje okno útoku. Tokeny můžete také kdykoli odvolat.
  • Samostatné tokeny JWT nabízejí klientovi a serveru záruky týkající se procesu ověřování. Klient má například prostředky k detekci a ověření, že tokeny, které přijímá, jsou legitimní a byly generovány v rámci daného procesu ověřování. Pokud se třetí strana pokusí vyměnit token uprostřed procesu ověřování, klient může rozpoznat vyměněný token a vyhnout se jeho použití.
  • Tokeny s protokolem OAuth a OIDC nespoléhají na správné chování uživatelského agenta, aby se zajistilo, že je aplikace zabezpečená.
  • Protokoly založené na tokenech, jako jsou OAuth a OIDC, umožňují ověřování a autorizaci uživatelů v samostatných Blazor aplikacích Webassembly se stejnou sadou charakteristik zabezpečení.
  • Použití protokolu založeného na tokenu nabízí méně chyb zabezpečení, protože tokeny se neodesílají ve všech požadavcích.
  • Tokeny se explicitně odesílají na server, takže koncové body serveru nevyžadují ochranu proti padělání požadavků mezi weby (CSRF). To vám umožňuje hostovat aplikace Blazor WebAssembly společně s aplikacemi MVC nebo Razor Pages.
  • Tokeny mají užší oprávnění než soubory cookie. Tokeny se například nedají použít ke správě uživatelského účtu nebo ke změně hesla uživatele, pokud není tato funkce explicitně implementována.
  • Tokeny mají krátkou životnost, jednu hodinu, což omezuje okno útoku. Tokeny můžete také kdykoli odvolat.
  • Samostatné tokeny JWT nabízejí klientovi a serveru záruky týkající se procesu ověřování. Klient má například prostředky k detekci a ověření, že tokeny, které přijímá, jsou legitimní a byly generovány v rámci daného procesu ověřování. Pokud se třetí strana pokusí vyměnit token uprostřed procesu ověřování, klient může rozpoznat vyměněný token a vyhnout se jeho použití.
  • Tokeny s protokolem OAuth a OIDC nespoléhají na správné chování uživatelského agenta, aby se zajistilo, že je aplikace zabezpečená.
  • Protokoly založené na tokenech, jako jsou OAuth a OIDC, umožňují ověřování a autorizaci uživatelů hostovaných Blazor WebAssembly klientů řešení a samostatných Blazor aplikací Webassembly se stejnou sadou charakteristik zabezpečení.

Důležité

Pro verze ASP.NET Core, které přijímají Duende Identity Server v Blazor šablonách projektů, může Duende Software vyžadovat, abyste zaplatili licenční poplatek za produkční použití Duende Identity Serveru. Další informace najdete v tématu Migrace z ASP.NET Core 5.0 na verzi 6.0.

Proces ověřování pomocí OIDC

Knihovna Microsoft.AspNetCore.Components.WebAssembly.Authentication nabízí několik primitiv pro implementaci ověřování a autorizace pomocí OIDC. Obecně platí, že ověřování funguje takto:

  • Když anonymní uživatel vybere přihlašovací tlačítko nebo požádá Razor o součást nebo stránku s [Authorize] použitým atributem , uživatel se přesměruje na přihlašovací stránku aplikace (/authentication/login).
  • Na přihlašovací stránce se knihovna ověřování připraví na přesměrování na koncový bod autorizace. Koncový bod autorizace je mimo aplikaci Blazor WebAssembly a může být hostovaný v samostatném zdroji. Koncový bod zodpovídá za určení, jestli je uživatel ověřený, a za vydání jednoho nebo více tokenů v odpovědi. Knihovna ověřování poskytuje zpětné volání přihlášení pro příjem odpovědi ověřování.
    • Pokud uživatel není ověřený, uživatel se přesměruje do základního ověřovacího systému, což je obvykle ASP.NET Core Identity.
    • Pokud už byl uživatel ověřený, koncový bod autorizace vygeneruje příslušné tokeny a přesměruje prohlížeč zpět na koncový bod zpětného volání přihlášení (/authentication/login-callback).
  • Když aplikace Blazor WebAssembly načte koncový bod zpětného volání přihlášení (/authentication/login-callback), zpracuje se odpověď ověřování.
    • Pokud se proces ověřování úspěšně dokončí, uživatel je ověřený a volitelně se odešle zpět na původní chráněnou adresu URL, kterou požadoval.
    • Pokud proces ověřování z nějakého důvodu selže, uživatel se odešle na neúspěšnou stránku přihlášení (/authentication/login-failed), kde se zobrazí chyba.

Authentication komponenta

Komponenta Authentication (Authentication.razor) zpracovává operace vzdáleného ověřování a umožňuje aplikaci:

  • Konfigurovat trasy aplikací pro stavy ověřování.
  • Nastavit obsah uživatelského rozhraní pro stavy ověřování.
  • Spravovat ověřovací klíče.

Akce ověřování, jako je registrace nebo přihlášení uživatele, se předávají komponentě RemoteAuthenticatorViewCore<TAuthenticationState> architektury Blazor, která uchovává a řídí stav mezi operacemi ověřování.

Další informace a příklady najdete v tématu Další scénáře zabezpečení ASP.NET Core Blazor WebAssembly.

Autorizace

V aplikacích Blazor WebAssembly je možné obejít kontroly autorizace, protože uživatelé můžou upravovat veškerý kód na straně klienta. Totéž platí pro všechny technologie aplikací na straně klienta, včetně architektur JavaScript SPA nebo nativních aplikací pro jakýkoli operační systém.

Vždy proveďte kontroly autorizace na serveru v rámci všech koncových bodů rozhraní API, ke které přistupuje vaše aplikace na straně klienta.

Přizpůsobení ověřování

Blazor WebAssembly poskytuje metody pro přidání a načtení dalších parametrů pro podkladovou knihovnu ověřování pro provádění vzdálených operací ověřování s externími identity zprostředkovateli.

Pokud chcete předat další parametry, NavigationManager podporuje předávání a načítání stavu položky historie při provádění změn externího umístění. Další informace naleznete v následujících zdrojích:

Stav uložený rozhraním API pro historii poskytuje pro vzdálené ověřování následující výhody:

  • Stav předaný zabezpečenému koncovému bodu aplikace je svázaný s navigací provedenou za účelem ověření uživatele v koncovém bodu authentication/login.
  • Dá se vyhnout nadbytečné práci s kódováním a dekódováním dat.
  • Zmenší se ohrožení zabezpečení. Na rozdíl od použití řetězce dotazu k uložení navigačního stavu nemůže navigace na nejvyšší úrovni nebo vliv z jiného původu nastavit stav uložený rozhraním API historie.
  • Položka historie se po úspěšném ověření nahradí, takže stav připojený k položce historie se odebere a nevyžaduje vyčištění.

InteractiveRequestOptions představuje požadavek identity na zprostředkovatele pro přihlášení nebo zřízení přístupového tokenu.

NavigationManagerExtensions poskytuje metodu NavigateToLogin pro operaci přihlášení a NavigateToLogout pro operaci odhlášení. Metody volají NavigationManager.NavigateTo a nastavují stav položky historie s předanou instancí InteractiveRequestOptions nebo novou instancí InteractiveRequestOptions vytvořenou metodou pro:

Následující scénáře ověřování jsou popsané v článku o dalších scénářích zabezpečení pomocí ASP.NET Core Blazor WebAssembly:

  • Přizpůsobení procesu přihlášení
  • Odhlášení s vlastní návratovou adresou URL
  • Přizpůsobení možností před interaktivním získáním tokenu
  • Přizpůsobení možností při použití IAccessTokenProvider
  • Získání přihlašovací cesty z možností ověřování

Vyžadování autorizace pro celou aplikaci

[Authorize] Použijte atribut (dokumentaci k rozhraní API) pro každou Razor komponentu aplikace pomocí jednoho z následujících přístupů:

  • V souboru aplikace Imports přidejte direktivu @using pro obor názvů Microsoft.AspNetCore.Authorization s direktivou @attribute pro atribut [Authorize].

    _Imports.razor:

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

    Povolte anonymní přístup ke komponentě Authentication a povolte přesměrování na poskytovatele identity . Do komponenty Authentication pod direktivu @page přidejte následující kód Razor.

    Authentication.razor:

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

  • Přidejte atribut do každé Razor komponenty podle direktivy @page :

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

Poznámka:

Nastavení AuthorizationOptions.FallbackPolicy zásady pomocí RequireAuthenticatedUser není podporováno.

Použití registrace jedné identity aplikace poskytovatele na aplikaci

Některé články v tomto přehledu se týkají Blazor scénářů hostování, které zahrnují dvě nebo více aplikací. Samostatná Blazor WebAssembly aplikace používá webové rozhraní API s ověřenými uživateli pro přístup k prostředkům serveru a datům poskytovaným serverovou aplikací.

Pokud je tento scénář implementovaný v příkladech dokumentace, použijí se dvěidentity registrace zprostředkovatele, jedna pro klientskou aplikaci a jedna pro serverovou aplikaci. Použití samostatných registrací, například v MICROSOFT Entra ID, není nezbytně nutné. Použití dvou registrací je ale osvědčeným postupem zabezpečení, protože izoluje registrace podle aplikace. Použití samostatných registrací také umožňuje nezávislou konfiguraci registrace klienta a serveru.

Některé články v tomto přehledu se týkají některého z následujících Blazor scénářů hostování, které zahrnují dvě nebo více aplikací:

  • Hostované Blazor WebAssembly řešení, které se skládá ze dvou aplikací: aplikace na straně Blazor WebAssembly klienta a serverová hostitelská aplikace ASP.NET Core. Ověření uživatelé v klientské aplikaci přistupují k prostředkům serveru a datům poskytovaným serverovými aplikacemi.
  • Samostatná Blazor WebAssembly aplikace, která používá webové rozhraní API s ověřenými uživateli pro přístup k prostředkům serveru a datům poskytovaným serverovou aplikací. Tento scénář se podobá použití hostovaného Blazor WebAssembly řešení, ale v tomto případě klientská aplikace není hostovaná serverovou aplikací.

Když jsou tyto scénáře implementované v příkladech dokumentace, použijí se dvěidentity registrace zprostředkovatele, jedna pro klientskou aplikaci a jedna pro serverovou aplikaci. Použití samostatných registrací, například v MICROSOFT Entra ID, není nezbytně nutné. Použití dvou registrací je ale osvědčeným postupem zabezpečení, protože izoluje registrace podle aplikace. Použití samostatných registrací také umožňuje nezávislou konfiguraci registrace klienta a serveru.

Obnovovací tokeny

I když se obnovovací tokeny nedají zabezpečit v Blazor WebAssembly aplikacích, dají se použít, pokud je implementujete s vhodnými strategiemi zabezpečení.

Pro samostatné Blazor WebAssembly aplikace v ASP.NET Core v .NET 6 nebo novější doporučujeme použít:

V případě hostovaných Blazor WebAssembly řešení je možné udržovat a používat obnovovací tokeny aplikace na straně serveru pro přístup k rozhraním API třetích stran. Další informace najdete v tématu Další scénáře zabezpečení ASP.NET Core Blazor WebAssembly.

Další informace naleznete v následujících zdrojích:

Vytvoření deklarací identity pro uživatele

Aplikace často vyžadují deklarace identity pro uživatele na základě volání webového rozhraní API na serveru. Deklarace identity se například často používají k vytvoření autorizace v aplikaci. V těchto scénářích aplikace požádá o přístup ke službě přístupový token a pomocí tokenu získá uživatelská data pro vytváření deklarací identity.

Příklady najdete v následujících zdrojích informací:

Podpora předrenderingu

Vykreslení předem se nepodporuje pro koncové body ověřování (segment cesty /authentication/).

Vykreslení předem se nepodporuje pro koncové body ověřování (segment cesty /authentication/).

Další informace najdete v tématu Další scénáře zabezpečení ASP.NET Core Blazor WebAssembly.

Azure App Service v Linuxu s Identity Serverem

Při nasazování do služby Azure App Service v Linuxu s Identity Serverem zadejte vystavitele explicitně.

Další informace najdete v tématu Použití Identity k zabezpečení back-endu webového rozhraní API pro služby SPA.

Ověřování systému Windows

Nedoporučujeme používat ověřování systému Windows s Blazor Webassembly ani s žádnou jinou architekturou SPA. Místo ověřování systému Windows doporučujeme používat protokoly založené na tokenech, jako je OIDC s ADFS (Active Directory Federation Services).

Pokud se ověřování systému Windows používá s Blazor Webassembly nebo s jakoukoli jinou architekturou SPA, jsou k ochraně aplikace před tokeny CSRF potřeba další opatření. Stejné obavy, které platí pro soubory cookie, platí pro ověřování systému Windows s tím, že ověřování systému Windows nenabízí mechanismus, který brání sdílení kontextu ověřování napříč zdroji. Aplikace využívající ověřování systému Windows bez další ochrany z CSRF by měly být aspoň omezené na intranet organizace a neměly by se používat na otevřeném internetu.

Další informace najdete v tématu Prevence útoků založených na padělání žádosti posílané mezi weby (XSRF/CSRF) v ASP.NET Core.

Zabezpečení centra SignalR

Pokud chcete zabezpečit SignalR centrum v projektu rozhraní API serveru, použijte [Authorize] atribut pro třídu centra nebo metody třídy centra.

V klientském projektu s předsekčním prostředím, jako je hostované Blazor WebAssembly (ASP.NET Core v .NET 7 nebo starší) nebo Blazor Web App (ASP.NET Core v .NET 8 nebo novější), najdete pokyny v pokynech k ASP.NET CoreBlazorSignalR.

V komponentě klientského projektu bez předdefinování, jako jsou samostatné Blazor WebAssemblyaplikace nebo aplikace bez prohlížeče, zadejte přístupový token pro připojení rozbočovače, jak ukazuje následující příklad. Další informace najdete v tématu Ověřování a autorizace v ASP.NET CoreSignalR.

@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();

  ...
}

Protokolování

Tato část se týká Blazor WebAssembly aplikací v ASP.NET Core v .NET 7 nebo novějším.

Pokud chcete povolit protokolování ladění nebo trasování, přečtěte si část Protokolování ověřování (Blazor WebAssembly) ve verzi 7.0 nebo novější článku protokolování ASP.NET CoreBlazor.

Sandbox WebAssembly

Sandbox WebAssembly omezuje přístup k prostředí systému, který spouští kód WebAssembly, včetně přístupu k subsystémům vstupně-výstupních operací, systémovému úložišti a prostředkům a operačnímu systému. Izolace mezi kódem WebAssembly a systémem, který spouští kód, činí WebAssembly bezpečným kódovacím rozhraním pro systémy. WebAssembly je však zranitelný vůči útokům na straně kanálu na úrovni hardwaru. Běžná opatření a důkladná kontrola při získávání hardwaru a umístění omezení pro přístup k hardwaru.

WebAssembly nepatří ani neudržuje Microsoft.

Další informace najdete v následujících prostředcích W3C:

  • WebAssembly: Zabezpečení
  • Specifikace WebAssembly: Aspekty zabezpečení
  • W3C WebAssembly Community Group: Zpětná vazba a problémy: Odkaz na skupinu komunity W3C webAssembly je poskytován pouze pro referenci, což znamená, že ohrožení zabezpečení WebAssembly a chyby jsou průběžně opravené, často hlášené a vyřešené prohlížečem. Neodesílejte do skupiny komunity W3C WebAssembly zpětnou vazbu ani zprávy o Blazor chybách.Blazor Zpětná vazba by se měla nahlásit produktové jednotce Microsoft ASP.NET Core. Pokud produktová jednotka Microsoftu zjistí, že existuje základní problém s WebAssembly, provede příslušné kroky k nahlášení problému skupině komunity W3C WebAssembly.

Průvodce implementací

Články v tomto přehledu poskytují informace o ověřování uživatelů v aplikacích Blazor WebAssembly vůči konkrétním zprostředkovatelům.

Samostatné aplikace Blazor WebAssembly:

Další pokyny ke konfiguraci najdete v následujících článcích:

Použití toku autorizačního kódu s PKCE

Microsoft identity Platform's Microsoft Authentication Library for JavaScript (MSAL) v2.0 nebo novější poskytuje podporu pro tok autorizačního kódu s proof key for Code Exchange (PKCE) a sdílení prostředků mezi zdroji (CORS) pro jednostránkové aplikace, včetně Blazor.

Microsoft nedoporučuje používat implicitní udělení.

Další informace naleznete v následujících zdrojích:

Další materiály