Schützen der Blazor WebAssembly von ASP.NET Core

Blazor WebAssembly-Apps werden auf die gleiche Weise geschützt wie Single-Page-Anwendungen (SPAs). Es gibt mehrere Ansätze für die Authentifizierung von Benutzern bei SPAs, der gängigste und umfassendste Ansatz besteht jedoch darin, eine auf dem OAuth 2.0-Protokoll basierende Implementierung wie Open ID Connect (OIDC) zu verwenden.

Die Sicherheitsdokumentation für Blazor WebAssembly konzentriert sich in erster Linie darauf, wie Benutzerauthentifizierungs- und Autorisierungsaufgaben ausgeführt werden. Informationen zur Abdeckung allgemeiner OAuth 2.0/OIDC-Konzepte finden Sie in den Ressourcen im Abschnitt Zusätzliche Ressourcen des Hauptübersichtsartikels.

Clientseitige/SPA-Sicherheit vertraulicher Daten und Anmeldeinformationen

Die .NET-/C#-Codebasis einer Blazor WebAssembly-App wird für Clients bereitgestellt, und der Code der App kann nicht vor der Begutachtung und Manipulation durch Benutzer*innen geschützt werden. Platzieren Sie niemals Anmeldeinformationen oder geheime Schlüssel in einer Blazor WebAssembly App, z. B. Geheime App-Schlüssel, Verbindungszeichenfolge s, Kennwörter, privaten .NET/C#-Code oder andere vertrauliche Daten.

Um .NET-/C#-Code zu schützen und Features zum Schutz von Daten in ASP.NET Core zum Schützen von Daten zu verwenden, nutzen Sie eine serverseitige ASP.NET Core-Web-API. Lassen Sie die clientseitige Blazor WebAssembly-App die serverseitige Web-API aufrufen, um sichere App-Features und Datenverarbeitung zu ermöglichen. Weitere Informationen finden Sie unter Aufrufen einer Web-API über eine ASP.NET Core Blazor-App und in den Artikeln in diesem Knoten.

Für lokale Entwicklungstests wird das Tool "Geheimer Manager" zum Sichern vertraulicher Daten empfohlen.

Authentifizierungsbibliothek

Blazor WebAssemblyunterstützt die Authentifizierung und Autorisierung von Apps mithilfe von OIDC über die Microsoft.AspNetCore.Components.WebAssembly.Authentication Bibliothek mithilfe der Microsoft-Plattformidentity. Die Bibliothek stellt mehrere Primitive für die nahtlose Authentifizierung für ASP.NET Core-Back-Ends bereit. Die Bibliothek kann bei einem Drittanbieter-Identitätsanbieter authentifiziert werden, der OIDC unterstützt (die OpenID-Anbieter).

Die Authentifizierungsunterstützung in der Blazor WebAssembly-Bibliothek (Authentication.js) basiert auf der Microsoft-Authentifizierungsbibliothek (MSAL, msal.js), die für die Verarbeitung der zugrunde liegenden Informationen im Authentifizierungsprotokoll verwendet wird. Die Blazor WebAssembly-Bibliothek unterstützt nur den Prüfschlüssel für den Flow für den PKCE-Autorisierungscode (Proof Key for Code Exchange, Prüfschlüssel für Codeaustausch). Die implizite Gewährung wird nicht unterstützt.

Eine weitere Option zum Authentifizieren von SPAs ist die Verwendung von SameSite-Cookies. Das Entwurfsdesign von Blazor WebAssembly verwendet jedoch OAuth und OIDC als beste Option für die Authentifizierung bei Blazor WebAssembly-Apps. Die auf JSON Web Token gestützte tokenbasierte Authentifizierung wurde aus Funktions- und Sicherheitsgründen der cookiebasierten Authentifizierung vorgezogen.

Authentifizierungsprozess mit OIDC

Die Microsoft.AspNetCore.Components.WebAssembly.Authentication-Bibliothek bietet mehrere Primitive zum Implementieren der Authentifizierung und Autorisierung mithilfe von OIDC. Im Allgemeinen funktioniert die Authentifizierung wie folgt:

• Wenn ein anonymer Benutzer die Anmeldeschaltfläche auswählt oder eine Razor-Komponente oder -Seite mit angewendetem [Authorize]-Attribut anfordert, wird der Benutzer zur Anmeldeseite (/authentication/login) der App weitergeleitet.
• Auf der Anmeldeseite bereitet die Authentifizierungsbibliothek eine Umleitung zum Autorisierungsendpunkt vor. Der Autorisierungsendpunkt befindet sich außerhalb der Blazor WebAssembly-App und kann als separater Ursprung gehostet werden. Der Endpunkt ist dafür verantwortlich, zu bestimmen, ob der Benutzer authentifiziert ist, und dass ein oder mehrere Token als Antwort ausgegeben werden. Die Authentifizierungsbibliothek stellt einen Anmelderückruf zum Empfangen der Authentifizierungsantwort bereit.
  • Wenn der Benutzer nicht authentifiziert ist, wird er an das zugrunde liegende Authentifizierungssystem umgeleitet (normalerweise ASP.NET Core Identity).
  • Wenn der Benutzer bereits authentifiziert wurde, generiert der Authentifizierungsendpunkt die entsprechenden Token und leitet den Browser zurück an den Anmelderückrufendpunkt (/authentication/login-callback).
• Wenn die Blazor WebAssembly-App den Anmelderückrufendpunkt (/authentication/login-callback) lädt, wird die Authentifizierungsantwort verarbeitet.
  • Sobald der Authentifizierungsprozess erfolgreich abgeschlossen wird, wird der Benutzer authentifiziert und optional an die ursprüngliche geschützte URL weitergeleitet, die vom Benutzer angefordert wurde.
  • Sollte der Authentifizierungsprozess aus irgendeinem Grund nicht funktionieren, wird der Benutzer auf eine Seite weitergeleitet, auf der ein Fehler angezeigt wird (/authentication/login-failed).

Authentication-Komponente

Die Authentication-Komponente (Authentication.razor) behandelt Remote-Authentifizierungsvorgänge und ermöglicht der App Folgendes:

• Konfigurieren von App-Routen für Authentifizierungsstatus.
• Festlegen von Inhalten der Benutzeroberfläche für Authentifizierungsstatus.
• Verwalten des Authentifizierungsstatus.

Authentifizierungsaktionen, wie etwa das Registrieren oder Anmelden eines Benutzers, werden der RemoteAuthenticatorViewCore<TAuthenticationState>-Komponente des Blazor-Frameworks übergeben, die für die übergreifende Dauerhaftigkeit und die Steuerung des Status über Authentifizierungsvorgänge hinweg zuständig ist.

Weitere Informationen und Beispiele finden Sie unter Zusätzliche Sicherheitsszenarien für Blazor WebAssembly in ASP.NET Core.

Autorisierung

In Blazor WebAssembly-Apps können Autorisierungsprüfungen umgangen werden, da der gesamte clientseitige Code von Benutzern geändert werden kann. Dasselbe gilt für alle clientseitigen App-Technologien, einschließlich JavaScript SPA-Frameworks oder native Apps für jedes Betriebssystem.

Führen Sie Autorisierungsprüfungen auf dem Server immer innerhalb aller API-Endpunkte durch, auf die Ihre clientseitige App zugreift.

Autorisierung für die gesamte App erforderlich

Wenden Sie das [Authorize]-Attribut (API-Dokumentation) mit einem der folgenden Ansätze auf jede Razor-Komponente der App an:

• Fügen Sie in der Imports-Datei der App eine @using-Direktive für den Microsoft.AspNetCore.Authorization-Namespace mit einer @attribute-Direktive für das [Authorize]-Attribut hinzu.

  _Imports.razor:

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

  Lassen Sie anonymen Zugriff auf die Authentication-Komponente zu, um die Umleitung an den identity-Anbieter zu ermöglichen. Fügen Sie der Authentication-Komponente unter ihrer @page-Anweisung den folgenden Razor-Code hinzu.

  Authentication.razor:

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

• Fügen Sie das Attribut zu jeder Razor Komponente unter der @page Anweisung hinzu:

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

Verwenden einer identity-Anbieter-App-Registrierung pro App

Aktualisierungstoken

Aktualisierungstoken können in Blazor WebAssembly-Apps zwar nicht gesichert, aber verwendet werden, wenn Sie sie mit entsprechenden Sicherheitsstrategien implementieren.

Für eigenständige Blazor WebAssembly-Apps in ASP.NET Core in .NET 6 oder höher empfehlen wir Folgendes:

• Den OAuth 2.0-Autorisierungscodeflow (Code) mit Proof Key for Code Exchange (PKCE).
• Ein Aktualisierungstoken mit kurzem Ablaufzeitraum.
• Ein rotiertes Aktualisierungstoken.
• Ein Aktualisierungstoken mit Ablauf, nach dem ein neuer interaktiver Autorisierungsflow erforderlich ist, um die Anmeldeinformationen des Benutzers zu aktualisieren.

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Microsoft identity Platform-Aktualisierungstoken: Lebensdauer von Aktualisierungstoken
• OAuth 2.0 für browserbasierte Apps (IETF-Spezifikation)

Erstellen von Ansprüchen für Benutzer

Apps fordern häufig Ansprüche für Benutzer basierend auf einem Web-API-Aufruf an einen Server an. Beispielsweise werden Ansprüche häufig bei der Autorisierung in Apps verwendet. In diesen Szenarien fordert die App ein Zugriffstoken für den Zugriff auf den Dienst an und verwendet dieses Token zum Abrufen der Benutzerdaten für die Erstellung von Ansprüchen.

Beispiele finden Sie in den folgenden Ressourcen:

• Zusätzliche Szenarios: Anpassen des Benutzers
• ASP.NET Core Blazor WebAssembly mit Microsoft Entra-ID-Gruppen und -Rollen

Unterstützung für das Vorabrendering

Weitere Informationen finden Sie unter Zusätzliche Sicherheitsszenarien für Blazor WebAssembly in ASP.NET Core.

Azure App Service für Linux mit Identity Server

Geben Sie den Zertifikataussteller explizit an, wenn Sie eine Bereitstellung auf Azure App Service für Linux mit Identity Server durchführen.

Weitere Informationen finden Sie unter Verwenden von Identity zum Sichern eines Web-API-Back-Ends für SPAs.

Windows-Authentifizierung

Es wird nicht empfohlen, die Windows-Authentifizierung mit Blazor WebAssembly oder mit einem anderen SPA-Framework zu verwenden. Wir empfehlen die Verwendung von tokenbasierten Protokollen anstelle der Windows-Authentifizierung, z. B. OIDC mit Active Directory-Verbunddiensten (ADFS).

Wenn die Windows-Authentifizierung mit Blazor WebAssembly oder mit einem anderen SPA-Framework verwendet wird, sind weitere Maßnahmen nötig, um die App vor Token für siteübergreifende Anforderungsfälschung (CSRF) zu schützen. Die gleichen Probleme, die auf Cookies zutreffen, gelten auch für die Windows-Authentifizierung mit dem Zusatz, dass die Windows-Authentifizierung keine Mechanismen bietet, um eine ursprungsübergreifende Freigabe des Authentifizierungskontexts zu verhindern. Apps, die die Windows-Authentifizierung ohne zusätzlichen Schutz vor siteübergreifender Anforderungsfälschung verwenden, sollten zumindest auf das Intranet einer Organisation beschränkt sein und nicht im offenen Internet verwendet werden.

Weitere Informationen finden Sie unter Prevent Cross-Site Request Forgery (XSRF/CSRF) Attacks in ASP.NET Core (Verhindern von websiteübergreifenden Anforderungsfälschungen (XSRF/CSRF) in ASP.NET Core).

Schützen eines SignalR-Hubs

Um einen SignalR-Hub im Server-API-Projekt zu sichern, wenden Sie das [Authorize]-Attribut auf die Hubklasse oder auf Methoden der Hubklasse an.

Weitere Informationen zu einem Clientprojekt mit Voarabrendering, wie z. B. gehostetes Blazor WebAssembly (ASP.NET Core in .NET 7 oder früher) oder ein Blazor Web App (ASP.NET Core in .NET 8 oder höher), finden Sie in der Anleitung im ASP.NET Core BlazorSignalR-Leitfaden.

In einer Client-Projektkomponente ohne Prerendering, wie z. B. Standalone- Blazor WebAssembly oder Nicht-Browser-Anwendungen, geben Sie ein Zugriffstoken an die Hub-Verbindung weiter, wie das folgende Beispiel zeigt. Weitere Informationen hierzu finden Sie unter Authentifizierung und Autorisierung in 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();

  ...
}

Logging

Dieser Abschnitt gilt für Blazor WebAssembly-Apps in ASP.NET Core in .NET 7 oder höher.

Informationen zum Aktivieren der Debug- oder Ablaufverfolgungsprotokollierung finden Sie im Abschnitt Authentifizierungsprotokollierung (Blazor WebAssembly) im Artikel zur ASP.NET Core-Blazor-Protokollierung für Version 7.0 oder höher.

Die WebAssembly-Sandbox

Die WebAssembly-Sandbox beschränkt den Zugriff auf die Umgebung des Systems, das WebAssembly-Code ausführt, einschließlich des Zugriffs auf E/A-Subsysteme, Systemspeicher und -ressourcen sowie das Betriebssystem. Die Isolierung zwischen WebAssembly-Code und dem System, das den Code ausführt, macht WebAssembly zu einem sicheren Codierungsframework für Systeme. WebAssembly ist jedoch anfällig für Seitenkanalangriffe auf Hardwareebene. Lassen Sie bei der Beschaffung von Hardware sowie dem Einrichten von Einschränkungen für den Zugriff auf Hardware normale Vorsichtsmaßnahmen und angemessene Sorgfalt walten.

WebAssembly befindet sich nicht im Besitz von Microsoft und wird nicht von Microsoft verwaltet.

Weitere Informationen finden Sie in den folgenden W3C-Ressourcen:

• WebAssembly: Security (Sicherheit)
• WebAssembly Specification: Security Considerations (WebAssembly-Spezifikation: Sicherheitsüberlegungen)
• W3C WebAssembly Community Group: Feedback and issues (W3C-WebAssembly-Communitygruppe: Feedback und Probleme): Der Link zur W3C-WebAssembly-Communitygruppe wird nur zu Referenzzwecken bereitgestellt und dient zur Klarstellung, dass WebAssembly-Sicherheitslücken und -Bugs regelmäßig gepatcht, häufig gemeldet und browserbasiert behoben werden. Senden Sie kein Feedback und keine Bugberichte zu Blazor an die W3C-WebAssembly-Communitygruppe.Blazor-Feedback sollte nur an die Microsoft ASP.NET Core-Produkteinheit gesendet werden. Wenn die Microsoft-Produkteinheit feststellt, dass ein zugrunde liegendes Problem mit WebAssembly vorliegt, führt sie die entsprechenden Schritte aus, um das Problem der W3C-WebAssembly-Communitygruppe zu melden.

Implementierungsleitfaden

Artikel unter dieser Übersicht bieten Informationen zum Authentifizieren von Benutzern in Blazor WebAssembly-Apps für bestimmte Anbieter.

Eigenständige Blazor WebAssembly-Apps:

• Allgemeiner Leitfaden für OIDC-Anbieter und die WebAssembly-Authentifizierungsbibliothek
• Microsoft-Konten
• Microsoft Entra-ID (ME-ID)
• Azure Active Directory (AAD) B2C

Weitere Konfigurationsanleitungen finden Sie in den folgenden Artikeln:

• Zusätzliche Sicherheitsszenarios für Blazor WebAssembly in ASP.NET Core
• Verwenden der Graph-API mit in ASP.NET CoreBlazor WebAssembly

Verwenden des Autorisierungscodeflows mit PKCE

Die Microsoft-Identitätsplattform Microsoft Authentication Library für JavaScript (MSAL) v2.0 oder höher bietet Unterstützung für den Autorisierungscodeflow mit Prüfschlüssel für den Codeaustausch (Proof Key for Code Exchange, PKCE) und der Ressourcenfreigabe zwischen verschiedenen Ursprüngen (Cross-Origin Resource Sharing, CORS) für Single-Page-Anwendungen, einschließlich Blazor.

Microsoft empfiehlt die Verwendung der impliziten Gewährung nicht.

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Unterstützung des Authentifizierungsablaufs in MSAL: Implizite Gewährung
• Microsoft identity-Plattform und impliziter Genehmigungsablauf: Bevorzugen des Authentifizierungscodeflows
• Microsoft identity-Plattform und der OAuth 2.0-Autorisierungscodeflow

Zusätzliche Ressourcen

• Dokumentation zur Microsoft identity-Plattform
  • Allgemeine Dokumentation
  • Zugriffstoken
• Konfigurieren von ASP.NET Core zur Verwendung mit Proxyservern und Lastenausgleich
  • der Verwendung der Middleware für weitergeleitete Header, um HTTPS-Schemainformationen für Proxyserver und interne Netzwerke zu schützen
  • zusätzlichen Szenarios und Anwendungsfällen, einschließlich der manuellen Schemakonfiguration, Änderungen von Anforderungspfaden für fehlerfreies Routing von Anforderungen und der Weiterleitung des Anforderungsschemas für Linux- und Nicht-IIS-Reverseproxys.
• Vorabrendering mit Authentifizierung
• WebAssembly: Security (Sicherheit)
• WebAssembly Specification: Security Considerations (WebAssembly-Spezifikation: Sicherheitsüberlegungen)