Zabezpečení ASP.NET Core Blazor WebAssembly

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í na straně klienta nebo 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 do aplikace nic tajného Blazor WebAssembly kódu, jako je soukromý kód .NET/C#, klíče zabezpečení, hesla nebo jakýkoli jiný typ citlivých informací.

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.

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í aplikací SPA, jako je například 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 na úkor ověřování založeného na souborech cookie z důvodů funkčnosti a zabezpečení:

• Použití protokolu založeného na tokenech nabízí menší prostor pro útok, protože tokeny se neodesílají ve všech požadavcích.
• Koncové body serveru nevyžadují ochranu proti padělání žádostí mezi weby (CSRF), protože tokeny se odesílají explicitně. 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, ve výchozím nastavení jednu hodinu, což omezuje časové 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í.

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 zprostředkovateli identity.

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:

• Blazor>Základní informace o směrování a navigaci
  • Stav historie navigace
  • Možnosti navigace
• Dokumentace k MDN: Rozhraní API historie

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.
• Omezuje se potenciální oblast útoku. 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 na zprostředkovatele identity 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:

• Uživatele, který se přihlašuje (InteractionType.SignIn) – s aktuálním identifikátorem URI pro návratovou adresu URL.
• Uživatele, který se odhlašuje (InteractionType.SignOut) – s návratovou adresou URL.

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]
  

  Povolit anonymní přístup ke komponentě Authentication , aby bylo možné přesměrování na zprostředkovatele 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í RequireAuthenticatedUsernení podporováno.

Použití jedné registrace aplikace zprostředkovatele identity 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í.

Při implementaci tohoto scénáře v příkladech dokumentace se použijí dvě registrace zprostředkovatele identity, 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:

• Tok autorizačního kódu OAuth 2.0 (kód) s ověřovacím klíčem pro výměnu kódu (PKCE)
• Obnovovací token s krátkým vypršením platnosti
• Otočený obnovovací token.
• Obnovovací token s vypršením platnosti, po kterém se k aktualizaci přihlašovacích údajů uživatele vyžaduje nový interaktivní tok autorizace.

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

• Obnovovací tokeny platformy Microsoft Identity Platform: Životnost obnovovacího tokenu
• OAuth 2.0 pro aplikace založené na prohlížeči (specifikace IETF)

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í:

• Další scénáře: Přizpůsobení uživatele
• ASP.NET Core Blazor WebAssembly se skupinami a rolemi ID Microsoft Entra

Podpora předrenderingu

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 cookieověřování systému Windows s přidáním toho, ž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ředúlohováním, jako je hostovaný Blazor WebAssembly (ASP.NET Core v .NET 7 nebo starší) nebo Blazor webová aplikace (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:

• Obecné pokyny pro zprostředkovatele OIDC a knihovnu ověřování WebAssembly
• Účty Microsoft
• Microsoft Entra ID (ME-ID)
• Azure Active Directory (AAD) B2C

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

• Další scénáře zabezpečení ASP.NET Core Blazor WebAssembly
• Použití Graph API s ASP.NET Core Blazor WebAssembly

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

Microsoft Identity Platformu Microsoft Authentication Library pro JavaScript (MSAL) v2.0 nebo novější poskytuje podporu toku autorizačního kódu s kódem 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:

• Podpora toku ověřování v MSAL: Implicitní udělení
• Microsoft Identity Platform a implicitní tok udělení: Preferujte tok ověřovacího kódu.
• Microsoft Identity Platform a tok autorizačního kódu OAuth 2.0

Další materiály

• Dokumentace k platformě Microsoft Identity Platform
  • Obecná dokumentace
  • Přístupové tokeny
• Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení
  • Použití middlewaru Forwarded Headers k zachování informací o schématu HTTPS napříč proxy servery a interními sítěmi
  • Další scénáře a případy použití, včetně ruční konfigurace schématu, změn cesty požadavku pro správné směrování požadavků a předávání schématu požadavků pro linuxové proxy servery a proxy servery a jiné než IIS.
• Předběžné nastavení s ověřováním
• WebAssembly: Zabezpečení
• Specifikace WebAssembly: Aspekty zabezpečení