Zabezpieczanie ASP.NET Core Blazor WebAssembly

Blazor WebAssembly aplikacje są zabezpieczane w taki sam sposób jak aplikacje jednostronicowe (SPA). 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 omówienie zagadnień dotyczących protokołu OAuth 2.0/OIDC znajdziesz w zasobach w sekcji Powiązana zawartość artykułu głównego omówienia.

Bezpieczeństwo danych poufnych i poświadczeń po stronie klienta i w aplikacjach SPA

Baza kodu .NET/C# aplikacji Blazor WebAssembly jest dostarczana klientom, a kod aplikacji nie może być chroniony przed analizą i modyfikacją przez użytkowników. Nigdy nie umieszczaj poufnych danych w aplikacji Blazor WebAssembly, takiej jak wpisy tajne aplikacji, parametry połączenia, hasła, klucze zabezpieczeń i prywatny kod .NET/C#.

Następujące technologie są przydatne do przechowywania danych poufnych i mogą być stosowane razem w tej samej aplikacji, aby podzielić obowiązki związane z przechowywaniem danych pomiędzy środowiskami Development, Staging i Production.

• narzędzie Secret Manager: jest używane tylko w lokalnym systemie deweloperskim.
• Azure Key Vault: można używać do uruchamiania aplikacji lokalnie w środowisku Development oraz do wdrożeń Staging/Production.

Aby zapoznać się z przykładami przedstawionych podejść, zobacz Potwierdzenie konta i odzyskiwanie hasła w ASP.NET Core Blazor WebAssemblyIdentity.

Żądania Web API

Aby chronić kod i dane platformy .NET/C#, użyj funkcji ASP.NET Core Data Protection z internetowym interfejsem API zaplecza ASP.NET Core po stronie serwera. Aplikacja Blazor WebAssembly po stronie klienta wywołuje internetowy interfejs API po stronie serwera na potrzeby bezpiecznych funkcji aplikacji i przetwarzania danych. Aby uzyskać więcej informacji, zobacz Blazor aplikacji ASP.NET Core oraz artykuły i przykłady w tej części dokumentacji.

Blazor WebAssembly aplikacje często nie mogą kierować wywołań między źródłami do internetowych interfejsów API z powodu zabezpieczeń współużytkowania żądań między źródłami (CORS). Typowy wyjątek wygląda następująco:

Dostęp do pobierania pod adresem "{URL}" ze źródła "https://localhost:{PORT}' został zablokowany przez zasady CORS: dla żądanego zasobu nie ma nagłówka "Access-Control-Allow-Origin". Jeśli potrzebujesz nieprzezroczystej odpowiedzi, ustaw tryb żądania na "no-cors", aby pobrać zasób bez włączonego mechanizmu CORS.

Nawet jeśli wywołasz SetBrowserRequestMode z polem BrowserRequestModeNoCors (1) w celu obejścia powyższego wyjątku, żądanie zwykle kończy się niepowodzeniem z powodu ograniczeń CORS dotyczących źródła internetowego interfejsu API. Przykładem może być ograniczenie, które zezwala tylko na wywołania z określonych źródeł lub ograniczenie uniemożliwiające przesyłanie żądań JavaScript fetch z przeglądarki. Jedynym sposobem, aby takie wywołania się powiodły, jest umożliwienie wywoływanemu web API akceptowania pochodzenia Twojego wywołania poprzez poprawną konfigurację CORS. Większość zewnętrznych internetowych interfejsów API nie zezwala na konfigurowanie ich zasad CORS. Aby radzić sobie z tym ograniczeniem, należy przyjąć jedną z następujących strategii:

• Utrzymuj własne serwerowe API sieciowe ASP.NET Core. Aplikacja Blazor WebAssembly po stronie klienta wywołuje internetowy interfejs API po stronie serwera, a internetowy interfejs API wysyła żądanie z kodu C# opartego na serwerze (a nie przeglądarki) do zewnętrznego internetowego interfejsu API z poprawnymi nagłówkami CORS, zwracając wynik do aplikacji Blazor WebAssembly po stronie klienta.

• Użyj usługi proxy, aby przekazać żądanie z aplikacji Blazor WebAssembly po stronie klienta do zewnętrznego interfejsu API. Usługa proxy używa aplikacji po stronie serwera do wykonania żądania w imieniu klienta i zwraca wynik po pomyślnym wywołaniu. W poniższym przykładzie opartym na serwerze proxy CORS platformy CloudFlare, symbol zastępczy {REQUEST URI} jest URI żądania.

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

Biblioteka uwierzytelniania

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

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). Grant niejawny nie jest obsługiwany.

Istnieją inne sposoby uwierzytelniania aplikacji SPA, na przykład z użyciem plików cookie SameSite. Jednak projekt techniczny rozwiązania Blazor WebAssembly wykorzystuje OAuth i OIDC jako najlepszą opcję uwierzytelniania w aplikacjach Blazor WebAssembly. Uwierzytelnianie oparte na tokenach bazujące na tokenach JSON Web Token (JWT) wybrano zamiast uwierzytelniania opartego na cookie ze względów funkcjonalnych i bezpieczeństwa:

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ą Blazor WebAssembly i może być hostowany pod oddzielnym adresem 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 Blazor WebAssembly wczytuje punkt końcowy wywołania zwrotnego logowania (/authentication/login-callback), przetwarzana jest odpowiedź uwierzytelniająca.
  • 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 komponent

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

• Skonfiguruj trasy aplikacji dla stanów uwierzytelnienia.
• Ustawianie zawartości interfejsu użytkownika dla stanów uwierzytelniania.
• Zarządzaj stanem uwierzytelniania.

Akcje uwierzytelniania, takie jak rejestrowanie lub logowanie użytkownika, są przekazywane do składnika Blazor platformy RemoteAuthenticatorViewCore<TAuthenticationState>, 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.

Blazor WebAssembly wzorce autoryzacji

W przypadku wzorców mających zastosowanie do aplikacji po stronie serwera (aplikacji Blazor Web App, aplikacji Blazor Server, aplikacji Blazor), zobacz Blazor.

W przeciwieństwie do aplikacji Blazor po stronie serwera aplikacje Blazor WebAssembly nie obsługują ustawiania dla AuthorizationOptions.FallbackPolicy zasad za pomocą RequireAuthenticatedUser. Zasada rezerwowa po stronie serwera jest wymuszana przez middleware autoryzacji i nie stanowi mechanizmu autoryzacji po stronie klienta. W związku z tym jedynym obsługiwanym schematem w aplikacjach Blazor WebAssembly jest zastosowanie [Authorize] (dokumentacja interfejsu API) do komponentów Razor, stosując jedno z poniższych podejść:

• W pliku importów aplikacji dodaj dyrektywę @using dla Microsoft.AspNetCore.Authorization przestrzeni nazw oraz dyrektywę @attribute dla atrybutu [Authorize].

  _Imports.razor:

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

  Należy zezwolić na anonimowy dostęp do składnika Authentication, aby umożliwić przekierowanie do dostawcy usług 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]
  

Korzystaj z jednej rejestracji aplikacji dostawcy tożsamości na aplikację

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żający z okresem ważności, po upływie którego wymagany jest nowy interaktywny proces autoryzacji w celu odświeżenia poświadczeń użytkownika.

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

• tokeny odświeżania platformy tożsamości firmy Microsoft: odświeżanie okresu istnienia tokenu
• 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ń dotyczących 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 w Microsoft Entra ID

Obsługa prerenderingu

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 określ jawnie wystawcę.

Aby uzyskać więcej informacji, zobacz Użyj Identity, aby zabezpieczyć zaplecze internetowego interfejsu API dla aplikacji SPA.

Uwierzytelnianie systemu Windows

Nie zalecamy używania uwierzytelniania systemu Windows w przypadku Blazor WebAssembly ani żadnego innego frameworka SPA. 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 technologią Blazor WebAssembly lub z dowolnym innym frameworkiem SPA, wymagane są dodatkowe środki ochrony aplikacji przed atakami polegającymi na fałszowaniu żądań między witrynami (CSRF). Te same obawy, które mają zastosowanie do plików cookie, dotyczą uwierzytelniania 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 polegającym na fałszowaniu żądań międzywitrynowych (XSRF/CSRF) w środowisku ASP.NET Core.

Zabezpiecz koncentrator 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 hostowany Blazor WebAssembly (ASP.NET Core w .NET 7 lub starszym) lub Blazor Web App (ASP.NET Core w .NET 8 lub nowszym), zobacz wskazówki w dokumencie ASP.NET Core BlazorSignalR — wskazówki.

W komponencie projektu klienckiego bez prerenderingu, takim jak samodzielne Blazor WebAssembly lub aplikacje inne niż przeglądarkowe, podaj token dostępu dla połączenia z koncentratorem, jak pokazano w poniższym przykładzie. Aby uzyskać więcej informacji, zobacz SignalR uwierzytelnianie i autoryzacja.

@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 .NET 7 lub nowszej w artykule dotyczącym rejestrowania ASP.NET CoreBlazor.

Piaskownica WebAssembly

Piaskownica WebAssembly ogranicza dostęp do środowiska systemu, w którym wykonywany jest kod WebAssembly, w tym do podsystemów we/wy, pamięci masowej i zasobów systemu 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. Standardowe środki ostrożności oraz należyta staranność przy pozyskiwaniu sprzętu i ograniczaniu dostępu do niego mają zastosowanie.

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:

• WebAssembly: Bezpieczeństwo
• 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 zgłoszeń błędów dotyczących Blazor do grupy W3C WebAssembly Community Group.Blazor Opinie należy zgłaszać do zespołu 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 tym Omówieniu zawierają informacje o uwierzytelnianiu użytkowników w aplikacjach Blazor WebAssembly przy użyciu określonych dostawców.

Samodzielne Blazor WebAssembly aplikacje:

• Ogólne wskazówki dotyczące dostawców OIDC oraz biblioteki uwierzytelniania WebAssembly
• Konta Microsoft
• Microsoft Entra ID (ME-ID)
• 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 interfejs Graph API z platformą ASP.NET Core Blazor WebAssembly

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

Platforma tożsamości firmy Microsoft Microsoft Authentication Library for JavaScript (MSAL) w wersji 2.0 lub nowszej zapewnia obsługę przepływu kodu autoryzacji z kluczem weryfikacji dla programu Code Exchange (PKCE) i współużytkowania zasobów między źródłami (CORS) dla aplikacji jednostronicowych, w tym .

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 firmy Microsoft i niejawny przepływ udzielania: preferuj przepływ kodu uwierzytelniania
• platforma tożsamości Microsoft i przepływ kodu autoryzacyjnego OAuth 2.0

Treści powiązane

• Dokumentacja platformy tożsamości firmy 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, zmiany ścieżki żądania w celu zapewnienia prawidłowego kierowania żądań oraz przekazywanie schematu żądania dla odwrotnych serwerów proxy w systemie Linux i innych niż IIS.
• Renderowanie wstępne z uwierzytelnianiem
• WebAssembly: Bezpieczeństwo
• Specyfikacja zestawu WebAssembly: Zagadnienia dotyczące zabezpieczeń