Zabezpieczanie aplikacji zestawu ASP.NET Core Blazor WebAssembly

Aplikacje zestawu Blazor WebAssembly są zabezpieczane w taki sam sposób jak aplikacje jednostronicowe. Istnieje kilka metod uwierzytelniania użytkowników w aplikacjach jednostronicowych, ale najczęstszym i kompleksowym podejściem jest użycie implementacji opartej na protokole OAuth 2.0, takiej jak OpenID Connect (OIDC).

Dokumentacja Blazor WebAssembly zabezpieczeń koncentruje się głównie na sposobie wykonywania zadań uwierzytelniania i autoryzacji użytkownika. Ogólne pokrycie koncepcji protokołu OAuth 2.0/OIDC znajduje się w sekcji Dodatkowe zasoby w artykule Omówienie.

Zabezpieczenia po stronie klienta/SPA

Baza Blazor WebAssembly kodu platformy .NET/C# aplikacji jest obsługiwana dla klientów, a kod aplikacji nie może być chroniony przed inspekcją i manipulowaniem przez użytkowników. Nigdy nie umieszczaj niczego tajnego w Blazor WebAssembly aplikacji, na przykład prywatnego kodu .NET/C#, kluczy zabezpieczeń, haseł lub innych typów poufnych informacji.

Aby chronić kod .NET/C# i używać funkcji ASP.NET Core Data Protection do zabezpieczania danych, użyj internetowego interfejsu API ASP.NET Core po stronie serwera. Aplikacja po stronie Blazor WebAssembly klienta wywołuje internetowy interfejs API po stronie serwera w celu zapewnienia bezpiecznych funkcji aplikacji i przetwarzania danych. Aby uzyskać więcej informacji, zobacz Wywoływanie internetowego interfejsu API z aplikacji ASP.NET Core Blazor i artykuły w tym węźle.

Biblioteka uwierzytelniania

Blazor WebAssemblyobsługuje uwierzytelnianie i autoryzowanie aplikacji przy użyciu funkcji OIDC za pośrednictwem Microsoft.AspNetCore.Components.WebAssembly.Authentication biblioteki przy użyciu platformy MicrosoftIdentity. Biblioteka udostępnia zestaw elementów pierwotnych do bezproblemowego uwierzytelniania względem zapleczy platformy ASP.NET Core. Biblioteka może wykonywać uwierzytelnianie względem dowolnego zewnętrznego dostawcy obsługi tożsamości (Identity), który obsługuje protokół OIDC. Tacy dostawcy są nazywani dostawcami OpenID.

Obsługa uwierzytelniania w Blazor WebAssembly bibliotece (Authentication.js) jest oparta na bibliotece Microsoft Authentication Library (MSAL, msal.js) używanej do obsługi podstawowych szczegółów protokołu uwierzytelniania. Blazor WebAssembly Biblioteka obsługuje tylko przepływ kodu autoryzacji PKCE (Proof Key for Code Exchange). Niejawne udzielanie nie jest obsługiwane.

Istnieją inne opcje uwierzytelniania aplikacji jednostronicowych, takie jak użycie plików cookie SameSite. Jednak projekt Blazor WebAssembly inżynieryjny używa protokołu OAuth i OIDC jako najlepszej opcji uwierzytelniania w Blazor WebAssembly aplikacjach. Uwierzytelnianie oparte na tokenach bazujące na JStokenach internetowych ON (JWT) zostało wybrane zamiast uwierzytelniania opartego na plikach cookie ze względów funkcjonalnych i bezpieczeństwa:

• Użycie protokołu opartego na tokenach skutkuje mniejszym obszarem podatnym na ataki, ponieważ tokeny nie są wysyłane we wszystkich żądaniach.
• Punkty końcowe serwera nie wymagają ochrony przed fałszowaniem żądań międzywitrynowych (CSRF), ponieważ tokeny są wysyłane jawnie. Umożliwia to hostowanie aplikacji zestawu Blazor WebAssembly obok aplikacji MVC lub aplikacji stron Razor.
• Tokeny mają węższe uprawnienia niż pliki cookie. Na przykład tokeny nie mogą służyć do zarządzania kontem użytkownika ani zmieniania hasła użytkownika, chyba że takie funkcje zostaną jawnie zaimplementowane.
• Tokeny mają krótki okres istnienia, domyślnie jedną godzinę, co ogranicza okno ataku. Tokeny można też w dowolnym momencie odwołać.
• Niezależne tokeny JWT oferują gwarancje dla klienta i serwera dotyczące procesu uwierzytelniania. Na przykład klient ma środki do wykrywania i weryfikacji, czy odbierane tokeny są wiarygodne i zostały wyemitowane w ramach danego procesu uwierzytelniania. Jeśli inny podmiot podejmie próbę przełączenia tokenu w trakcie procesu uwierzytelniania, klient może wykryć przełączony token i uniknąć jego używania.
• Tokeny z uwierzytelnianiem OAuth i OIDC przy upewnianiu się, czy aplikacja jest bezpieczna, nie polegają na prawidłowym zachowaniu agenta użytkownika.
• Protokoły oparte na tokenach, takie jak OAuth i OIDC, umożliwiają uwierzytelnianie i autoryzowanie użytkowników w autonomicznych Blazor aplikacjach webassembly z tym samym zestawem cech zabezpieczeń.

Ważne

W przypadku wersji ASP.NET Core, które przyjmują serwer Duende Identity Server w Blazor szablonach projektów, duende Software może wymagać zapłaty opłaty licencyjnej za korzystanie z serwera Duende Identity Server w środowisku produkcyjnym. Aby uzyskać więcej informacji, zobacz Migracja z platformy ASP.NET Core w wersji 5.0 do wersji 6.0.

Proces uwierzytelniania za pomocą protokołu OIDC

Biblioteka Microsoft.AspNetCore.Components.WebAssembly.Authentication oferuje kilka elementów pierwotnych do zaimplementowania uwierzytelniania i autoryzacji przy użyciu protokołu OIDC. Mówiąc ogólnie, uwierzytelnianie działa w następujący sposób:

• Gdy użytkownik anonimowy wybierze przycisk logowania lub zażąda Razor składnika lub strony z [Authorize] zastosowanym atrybutem , użytkownik zostanie przekierowany do strony logowania aplikacji (/authentication/login).
• Na stronie logowania biblioteka uwierzytelniania przygotowuje się do przekierowania do punktu końcowego autoryzacji. Punkt końcowy autoryzacji znajduje się poza aplikacją zestawu Blazor WebAssembly i może być hostowany w osobnym miejscu pochodzenia. Punkt końcowy jest odpowiedzialny za określenie, czy użytkownik jest uwierzytelniony, i za wystawienie w odpowiedzi co najmniej jednego tokenu. Biblioteka uwierzytelniania udostępnia wywołanie zwrotne logowania w celu otrzymania odpowiedzi na uwierzytelnianie.
  • Jeśli użytkownik nie jest uwierzytelniony, jest przekierowywany do podstawowego systemu uwierzytelniania, którym jest zwykle ASP.NET Core Identity.
  • Jeśli użytkownik został już uwierzytelniony, punkt końcowy autoryzacji generuje odpowiednie tokeny i przekierowuje przeglądarkę z powrotem do punktu końcowego wywołania zwrotnego logowania (/authentication/login-callback).
• Gdy aplikacja zestawu Blazor WebAssembly ładuje punkt końcowy wywołania zwrotnego logowania (/authentication/login-callback), odpowiedź uwierzytelniania jest przetwarzana.
  • Jeśli proces uwierzytelniania zakończy się pomyślnie, użytkownik zostanie uwierzytelniony i opcjonalnie odesłany do oryginalnego chronionego adresu URL, którego zażądał użytkownik.
  • Jeśli proces uwierzytelniania zakończy się niepowodzeniem z jakiegokolwiek powodu, użytkownik zostanie wysłany do strony logowania nie powiodło się (/authentication/login-failed), gdzie zostanie wyświetlony błąd.

Authentication cm6long

Składnik Authentication (Authentication.razor) obsługuje operacje uwierzytelniania zdalnego i zezwala aplikacji na:

• Konfigurowanie tras aplikacji dla stanów uwierzytelniania.
• Ustawianie zawartości interfejsu użytkownika dla stanów uwierzytelniania.
• Zarządzanie kluczami uwierzytelniania.

Akcje uwierzytelniania, takie jak rejestrowanie lub logowanie użytkownika, są przekazywane do składnika RemoteAuthenticatorViewCore<TAuthenticationState> platformy Blazor, który utrwala i kontroluje stan między operacjami uwierzytelniania.

Aby uzyskać więcej informacji i zobaczyć przykłady, zobacz Dodatkowe scenariusze zabezpieczeń zestawu ASP.NET Core Blazor WebAssembly.

Autoryzacja

W aplikacjach zestawu Blazor WebAssembly kontrole uwierzytelniania można pominąć, ponieważ użytkownicy mają możliwość modyfikowania całego kodu po stronie klienta. To samo dotyczy wszystkich technologii aplikacji po stronie klienta, w tym struktur JavaScript SPA lub natywnych aplikacji dowolnego systemu operacyjnego.

Zawsze przeprowadzaj kontrole autoryzacji na serwerze w obrębie dowolnych punktów końcowych interfejsu API, do których uzyskuje dostęp aplikacja po stronie klienta.

Dostosowywanie uwierzytelniania

Zestaw Blazor WebAssembly udostępnia metody dodawania i pobierania dodatkowych parametrów dla bazowej biblioteki uwierzytelniania w celu przeprowadzania operacji uwierzytelniania zdalnego z zewnętrznymi dostawcami tożsamości.

Aby przekazać dodatkowe parametry, NavigationManager obsługuje przekazywanie i pobieranie stanu wpisu historii podczas przeprowadzania zmian lokalizacji zewnętrznej. Aby uzyskać więcej informacji, zobacz następujące zasoby:

• BlazorArtykuł Dotyczący routingu i nawigacji — podstawy>
  • Stan historii nawigacji
  • Opcje nawigacji
• Dokumentacja usługi MDN: interfejs API historii

Stan przechowywany przez interfejs History API zapewnia następujące korzyści dla uwierzytelniania zdalnego:

• Stan przekazany do zabezpieczonego punktu końcowego aplikacji jest powiązany z nawigacją wykonywaną w celu uwierzytelnienia użytkownika w punkcie końcowym authentication/login.
• Unika się dodatkowej pracy związanej z kodowaniem i dekodowaniem danych.
• Zmniejszany jest obszar podatny na ataki. W przeciwieństwie do używania ciągu zapytania do przechowywania stanu nawigacji, nawigacja najwyższego poziomu lub wpływ z innego źródła nie może ustawić stanu przechowywanego przez interfejs API historii.
• Wpis historii jest zastępowany po pomyślnym uwierzytelnieniu, więc stan dołączony do wpisu historii jest usuwany i nie wymaga czyszczenia.

Element InteractiveRequestOptions reprezentuje żądanie dostawcy tożsamości dotyczące zalogowania się lub aprowizacji tokenu dostępu.

Element NavigationManagerExtensions udostępnia metodę NavigateToLogin dla operacji logowania i metodę NavigateToLogout dla operacji wylogowania. Metody wywołają metodę NavigationManager.NavigateTo, ustawiając stan wpisu historii za pomocą przekazanego elementu InteractiveRequestOptions lub nowego wystąpienia elementu InteractiveRequestOptions utworzonego przez metodę dla:

• Użytkownika logującego się (InteractionType.SignIn) przy użyciu bieżącego identyfikatora URI dla zwracanego adresu URL.
• Użytkownika wylogowywującego się (InteractionType.SignOut) przy użyciu zwracanego adresu URL.

Następujące scenariusze uwierzytelniania zostały omówione w artykule Dodatkowe scenariusze zabezpieczeń zestawu ASP.NET Core Blazor WebAssembly :

• Dostosowywanie procesu logowania
• Wylogowywanie przy użyciu niestandardowego zwrotnego adresu URL
• Dostosowywanie opcji przed interakcyjnym uzyskaniem tokenu
• Dostosowywanie opcji podczas korzystania z elementu IAccessTokenProvider
• Uzyskiwanie ścieżki logowania z opcji uwierzytelniania

Wymaganie autoryzacji dla całej aplikacji

Zastosuj atrybut (dokumentację interfejsu [Authorize] API) do każdego Razor składnika aplikacji przy użyciu jednej z następujących metod:

• W pliku Imports aplikacji dodaj dyrektywę @using dla przestrzeni nazw Microsoft.AspNetCore.Authorization z dyrektywą @attribute dla atrybutu [Authorize].

  _Imports.razor:

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

  Zezwalaj na anonimowy dostęp do Authentication składnika w celu zezwolenia na przekierowywanie do dostawcy tożsamości. Dodaj następujący kod Razor do składnika Authentication w ramach jego dyrektywy @page.

  Authentication.razor:

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

• Dodaj atrybut do każdego Razor składnika zgodnie z dyrektywą @page :

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

Uwaga

Ustawienie elementu AuthorizationOptions.FallbackPolicy na zasady z parametremRequireAuthenticatedUsernie jest obsługiwane.

Używanie jednej rejestracji aplikacji dostawcy tożsamości na aplikację

Niektóre artykuły w tym przeglądzie dotyczą Blazor scenariuszy hostingu obejmujących co najmniej dwie aplikacje. Autonomiczna Blazor WebAssembly aplikacja używa internetowego interfejsu API z uwierzytelnionymi użytkownikami w celu uzyskiwania dostępu do zasobów serwera i danych udostępnianych przez aplikację serwera.

W przypadku implementacji tego scenariusza w przykładach dokumentacji są używane dwie rejestracje dostawcy tożsamości, jedna dla aplikacji klienckiej i jedna dla aplikacji serwera. Używanie oddzielnych rejestracji, na przykład w identyfikatorze Entra firmy Microsoft, nie jest ściśle wymagane. Jednak użycie dwóch rejestracji jest najlepszym rozwiązaniem w zakresie zabezpieczeń, ponieważ izoluje rejestracje według aplikacji. Korzystanie z oddzielnych rejestracji umożliwia również niezależną konfigurację rejestracji klienta i serwera.

Tokeny odświeżania

Chociaż tokeny odświeżania nie mogą być zabezpieczone w Blazor WebAssembly aplikacjach, można ich używać, jeśli implementujesz je przy użyciu odpowiednich strategii zabezpieczeń.

W przypadku aplikacji autonomicznych Blazor WebAssembly w programie ASP.NET Core na platformie .NET 6 lub nowszym zalecamy użycie:

• Przepływ kodu autoryzacji OAuth 2.0 (kod) z kluczem dowodowym dla wymiany kodu (PKCE) .
• Token odświeżania, który ma krótki czas wygaśnięcia.
• Obracany token odświeżania .
• Token odświeżania z wygaśnięciem, po którym jest wymagany nowy interaktywny przepływ autoryzacji w celu odświeżenia poświadczeń użytkownika.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Platforma tożsamości Microsoft tokeny odświeżania: okres istnienia tokenu odświeżania
• Protokół OAuth 2.0 dla aplikacji opartych na przeglądarce (specyfikacja IETF)

Ustanawianie oświadczeń dla użytkowników

Aplikacje często wymagają oświadczeń dla użytkowników na podstawie wywołania internetowego interfejsu API do serwera. Na przykład oświadczenia są często używane do ustanawiania autoryzacji w aplikacji. W tych scenariuszach aplikacja żąda tokenu dostępu w celu uzyskania dostępu do usługi i używa tokenu w celu uzyskania danych użytkownika do tworzenia oświadczeń.

Aby zapoznać się z przykładami, skorzystaj z następujących zasobów:

• Dodatkowe scenariusze: Dostosowywanie użytkownika
• ASP.NET Core Blazor WebAssembly z grupami i rolami identyfikatorów entra firmy Microsoft

Obsługa prerenderingu

Wstępne renderowanie nie jest obsługiwane w przypadku punktów końcowych uwierzytelniania (segment ścieżki /authentication/).

Aby uzyskać więcej informacji, zobacz Dodatkowe scenariusze zabezpieczeń zestawu ASP.NET Core Blazor WebAssembly.

Usługa Azure App Service dla systemu Linux z serwerem Identity

Podczas wdrażania w usłudze Azure App Service dla systemu Linux z serwerem Identity jawnie określ wystawcę.

Aby uzyskać więcej informacji, zobacz Zabezpieczanie Identity zaplecza internetowego interfejsu API dla spAs.

Uwierzytelnianie systemu Windows

Nie zalecamy używania uwierzytelniania systemu Windows z zestawem Blazor Webassembly ani z inną strukturą aplikacji jednostronicowej. Zalecamy używanie protokołów opartych na tokenach zamiast uwierzytelniania systemu Windows, takich jak protokół OIDC z usługą Active Directory Federation Services (ADFS).

Jeśli uwierzytelnianie systemu Windows jest używane z zestawem Blazor Webassembly lub z inną strukturą aplikacji jednostronicowych, wymagane są dodatkowe środki do ochrony aplikacji przed fałszowaniem tokenów żądań międzywitrynowych (CSRF). Te same obawy, które mają zastosowanie do cookieuwierzytelniania systemu Windows z dodatkiem, że uwierzytelnianie systemu Windows nie oferuje mechanizmu zapobiegania udostępnianiu kontekstu uwierzytelniania między źródłami. Aplikacje korzystające z uwierzytelniania systemu Windows bez dodatkowej ochrony przed csrF powinny być co najmniej ograniczone do intranetu organizacji i nie być używane w otwartym Internecie.

Aby uzyskać więcej informacji, zobacz Zapobieganie atakom z fałszowaniem żądań międzywitrynowych (XSRF/CSRF) na platformie ASP.NET Core.

Zabezpieczanie koncentratora SignalR

Aby zabezpieczyć SignalR centrum w projekcie interfejsu API serwera, zastosuj [Authorize] atrybut do klasy centrum lub metod klasy centrum.

W projekcie klienta z prerenderingiem, takim jak hostowane Blazor WebAssembly (ASP.NET Core na platformie .NET 7 lub starszej) lub Blazor aplikacji internetowej (ASP.NET Core na platformie .NET 8 lub nowszej), zapoznaj się ze wskazówkami w ASP.NET CoreBlazorSignalR.

W składniku projektu klienta bez prerenderingu, takiego jak autonomiczne Blazor WebAssemblylub inne niż aplikacje przeglądarki, podaj token dostępu do połączenia centrum, jak pokazano w poniższym przykładzie. Aby uzyskać więcej informacji, zobacz Uwierzytelnianie i autoryzacja na platformie 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();

  ...
}

Rejestrowanie

Ta sekcja dotyczy Blazor WebAssembly aplikacji w programie ASP.NET Core na platformie .NET 7 lub nowszym.

Aby włączyć rejestrowanie debugowania lub śledzenia, zobacz sekcję Rejestrowanie uwierzytelniania (Blazor WebAssembly) w wersji 7.0 lub nowszej artykułu rejestrowania ASP.NET CoreBlazor.

Piaskownica zestawu WebAssembly

Piaskownica zestawu WebAssembly ogranicza dostęp do środowiska systemu wykonującego kod zestawu WebAssembly, w tym dostępu do podsystemów we/wy, magazynu systemu i zasobów oraz systemu operacyjnego. Izolacja między kodem WebAssembly a systemem, który wykonuje kod, sprawia, że zestaw WebAssembly jest bezpieczną strukturą kodowania dla systemów. Jednak zestaw WebAssembly jest narażony na ataki kanału bocznego na poziomie sprzętu. Normalne środki ostrożności i należyta staranność w zakresie określania sprzętu i stosowania ograniczeń dotyczących uzyskiwania dostępu do sprzętu.

Zestaw WebAssembly nie jest własnością ani nie jest obsługiwany przez firmę Microsoft.

Aby uzyskać więcej informacji, zobacz następujące zasoby W3C:

• Zestaw WebAssembly: Zabezpieczenia
• Specyfikacja zestawu WebAssembly: Zagadnienia dotyczące zabezpieczeń
• W3C WebAssembly Community Group: Opinie i problemy: Link grupy społeczności WebAssembly W3C jest udostępniany tylko do celów referencyjnych, co pozwala jasno stwierdzić, że luki w zabezpieczeniach i błędy zestawu WebAssembly są stale poprawiane, często zgłaszane i rozwiązywane przez przeglądarkę. Nie wysyłaj opinii ani raportów o błędach Blazor do grupy społeczności zestawu WebAssembly W3C.Blazor Opinia powinna zostać zgłoszona do jednostki produktu Microsoft ASP.NET Core. Jeśli jednostka produktu firmy Microsoft ustali, że istnieje podstawowy problem z zestawem WebAssembly, podejmuje odpowiednie kroki, aby zgłosić problem do grupy społeczności zestawu WebAssembly W3C.

Wskazówki dotyczące implementacji

Artykuły w ramach tego przeglądu zawierają informacje na temat uwierzytelniania użytkowników w aplikacjach Blazor WebAssembly względem określonych dostawców.

Autonomiczne aplikacje zestawu Blazor WebAssembly:

• Ogólne wskazówki dotyczące dostawców OIDC i biblioteki uwierzytelniania zestawu WebAssembly
• Konta Microsoft
• Microsoft Entra ID (ME-ID)
• Usługa Azure Active Directory (AAD) B2C

Dalsze wskazówki dotyczące konfiguracji można znaleźć w następujących artykułach:

• Dodatkowe scenariusze zabezpieczeń dotyczące platformy ASP.NET Core Blazor WebAssembly
• Używanie interfejsu Graph API z platformą ASP.NET Core Blazor WebAssembly

Korzystanie z przepływu kodu autoryzacji za pomocą protokołu PKCE

Platforma tożsamości MicrosoftBiblioteka uwierzytelniania firmy Microsoft dla języka JavaScript (MSAL) w wersji 2.0 lub nowszej zapewnia obsługę przepływu kodu autoryzacji z kluczem dowodowym dla wymiany kodu (PKCE) i współużytkowania zasobów między źródłami (CORS) dla aplikacji jednostronicowych, w tym Blazor .

Firma Microsoft nie zaleca korzystania z niejawnego udzielania.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Obsługa przepływu uwierzytelniania w usłudze MSAL: niejawne udzielanie
• Platforma tożsamości Microsoft i niejawny przepływ udzielania: preferuj przepływ kodu uwierzytelniania
• Platforma tożsamości Microsoft a przepływ kodu autoryzacji OAuth 2.0

Dodatkowe zasoby

• dokumentacja Platforma tożsamości Microsoft
  • Dokumentacja ogólna
  • Tokeny dostępu
• Konfigurowanie platformy ASP.NET Core pod kątem pracy z serwerami proxy i modułami równoważenia obciążenia
  • Używanie oprogramowania pośredniczącego nagłówków przekazywanych w celu zachowania informacji o schemacie HTTPS między serwerami proxy i sieciami wewnętrznymi.
  • Dodatkowe scenariusze i przypadki użycia, w tym ręczna konfiguracja schematu, żądanie zmiany ścieżki żądania na potrzeby prawidłowego routingu żądań i przekazywanie schematu żądań dla zwrotnych serwerów proxy systemu Linux i innych niż IIS.
• Wstępne używanie uwierzytelniania
• Zestaw WebAssembly: Zabezpieczenia
• Specyfikacja zestawu WebAssembly: Zagadnienia dotyczące zabezpieczeń