Erzwingen einer Content Security Policy für ASP.NET Core Blazor

In diesem Artikel wird erläutert, wie Sie eine Content Security Policy (CSP) auf ASP.NET Core Blazor-Apps anwenden, um sich gegen XSS-Angriffe (Cross-Site-Scripting) zu schützen.

Cross-Site Scripting (XSS) ist eine Sicherheitslücke, bei der ein Cyberangreifer ein oder mehrere bösartige clientseitige Skripts in den gerenderten Inhalt einer Anwendung einfügt. Eine CSP hilft beim Schutz gegen XSS-Angriffe, indem sie den Browser über Folgendes informiert:

• Quellen für geladenen Inhalt, einschließlich Skripts, Stylesheets, Bildern und Plug-Ins
• gültige von einer Webseite durchgeführte Aktionen, wobei die URL-Ziele von Formularen angegeben werden

Zum Anwenden einer CSP auf eine App gibt der Entwickler mehrere CSP-Anweisungen zur Inhaltssicherheit in mindestens einem Content-Security-Policy-Header oder <meta>-Tag an. Anleitungen zum Anwenden einer CSP auf eine App in C#-Code beim Start finden Sie unter Starten von ASP.NET Core Blazor.

Die Richtlinien werden vom Browser ausgewertet, während eine Seite geladen wird. Der Browser untersucht die Quellen der Seite und bestimmt, ob diese die Anforderungen der Anweisungen zur Inhaltssicherheit erfüllen. Wenn Richtlinienanweisungen für eine Ressource nicht erfüllt werden, lädt der Browser die Ressource nicht. Denken Sie sich beispielsweise eine Richtlinie, die keine Skripts von Drittanbietern zulässt. Wenn eine Seite ein <script>-Tag mit Drittanbieterursprung im src-Attribut enthält, verhindert der Browser das Laden des Skripts.

CSP wird von den meisten modernen Desktopbrowsern und mobilen Browsern unterstützt, darunter Chrome, Microsoft Edge, Firefox, Opera und Safari. CSP wird für Blazor-Apps empfohlen.

Richtlinienanweisungen

Geben Sie mindestens die folgenden Anweisungen und Quellen für Blazor-Apps an. Fügen Sie nach Bedarf weitere Anweisungen und Quellen hinzu. Die folgenden Anweisungen werden im Abschnitt Anwenden der Richtlinie dieses Artikels verwendet, in dem Beispiele für Sicherheitsrichtlinien für Blazor-Apps bereitgestellt werden:

• base-uri: Diese Anweisung schränkt die URLs für das <base>-Tag einer Seite ein. Geben Sie self an, um anzugeben, dass der Ursprung der App, einschließlich des Schemas und der Portnummer, eine gültige Quelle ist.
• default-src: Diese Anweisung gibt ein Fallback für Quellanweisungen an, die nicht explizit von der Richtlinie angegeben werden. Geben Sie self an, um anzugeben, dass der Ursprung der App, einschließlich des Schemas und der Portnummer, eine gültige Quelle ist.
• img-src: Diese Anweisung gibt gültige Quellen für Bilder an.
  • Geben Sie data: an, um das Laden von Bildern aus data:-URLs zuzulassen.
  • Geben Sie https: an, um das Laden von Bildern aus HTTPS-Endpunkten zuzulassen.
• object-src: Diese Anweisung gibt gültige Quellen für die Tags <object>, <embed> und <applet> an. Geben Sie none an, um alle URL-Quellen zu verhindern.
• script-src: Diese Anweisung gibt gültige Quellen für Skripts an.
  • Geben Sie self an, um anzugeben, dass der Ursprung der App, einschließlich des Schemas und der Portnummer, eine gültige Quelle ist.
  • In einer clientseitigen Blazor-App:
    • Geben Sie wasm-unsafe-eval an, um die serverseitige Blazor-Mono-Laufzeit zuzulassen.
    • Geben Sie zusätzliche Hashes an, damit die erforderlichen Skripts ohne Framework geladen werden können.
  • Geben Sie in einer serverseitigen Blazor-App Hashes an, um das Laden erforderlicher Skripts zuzulassen.
• style-src: Diese Anweisung gibt gültige Quellen für Stylesheets an.
  • Geben Sie self an, um anzugeben, dass der Ursprung der App, einschließlich des Schemas und der Portnummer, eine gültige Quelle ist.
  • Wenn die App Inlineformatvorlagen verwendet, geben Sie unsafe-inline an, um die Verwendung Ihrer Inlineformatvorlagen zu ermöglichen.
• upgrade-insecure-requests: Diese Anweisung gibt an, dass Inhalts-URLs aus unsicheren (HTTP-) Quellen sicher über HTTPS aufgerufen werden sollen.

Die vorangehenden Anweisungen werden mit Ausnahme von Microsoft Internet Explorer von allen Browsern unterstützt.

So rufen Sie SHA-Hashes für zusätzliche Inlineskripts ab:

• Wenden Sie die im Abschnitt Anwenden der Richtlinie dargestellte CSP an.
• Greifen Sie auf die Konsole mit den Entwicklertools des Browsers zu, während Sie die App lokal ausführen. Der Browser berechnet Hashes für blockierte Skripts und zeigt diese an, wenn ein CSP-Header oder meta-Tag vorhanden ist.
• Kopieren Sie die Hashes, die vom Browser bereitgestellt werden, in die script-src-Quellen. Setzen Sie jeden Hash in einfache Anführungszeichen.

Eine Browserunterstützungsmatrix für eine Content Security Policy Level 2 finden Sie unter Can I use: Content Security Policy Level 2 (Kann ich Content Security Policy Level 2 verwenden?).

Anwenden der Richtlinie

Verwenden Sie ein <meta>-Tag, um die Richtlinie anzuwenden:

• Legen Sie den Wert des http-equiv-Attributs auf Content-Security-Policy fest.
• Platzieren Sie die Anweisungen im Wert des content-Attributs. Trennen Sie Anweisungen durch ein Semikolon (;).
• Platzieren Sie das meta-Tag immer im <head>-Inhalt.

In den folgenden Abschnitten werden Beispielrichtlinien gezeigt. Diese Beispiele werden für jedes Release von Blazor mit diesem Artikel versioniert. Um eine für Ihr Release geeignete Version zu verwenden, wählen Sie auf dieser Webseite mithilfe der Dropdownauswahl Version die Dokumentversion aus.

Serverseitige Blazor-Apps

Wenden Sie im <head>-Inhalt die im Abschnitt Richtlinienanweisungen beschriebenen Anweisungen an:

<meta http-equiv="Content-Security-Policy" 
      content="base-uri 'self';
               default-src 'self';
               img-src data: https:;
               object-src 'none';
               script-src 'self';
               style-src 'self';
               upgrade-insecure-requests;">

Fügen Sie zusätzliche script-src- und style-src-Hashes hinzu, die von der App benötigt werden. Verwenden Sie während der Entwicklung ein Onlinetool oder Browserentwicklertools, damit die Hashes für Sie berechnet werden. Beispielsweise meldet der folgende Fehler einer Browsertoolkonsole den Hash für ein erforderliches Skript, das nicht durch die Richtlinie abgedeckt ist:

Die Ausführung des Inlineskripts wurde verweigert, da es die folgende Anweisung der Inhaltssicherheitsrichtlinie verletzt: „...“. Zum Aktivieren der Inlineausführung ist entweder das Schlüsselwort „unsafe-inline“, ein Hash („sha256-v8v3RKRPmN4odZ1CWM5gw80QKPCCWMcpNeOmimNL2AA=“) oder eine Nonce („nonce-...“) erforderlich.

Das Skript, das diesem Fehler zugeordnet ist, wird neben dem Fehler in der Konsole angezeigt.

Clientseitige Blazor-Apps

Wenden Sie im <head>-Inhalt die im Abschnitt Richtlinienanweisungen beschriebenen Anweisungen an:

<meta http-equiv="Content-Security-Policy" 
      content="base-uri 'self';
               default-src 'self';
               img-src data: https:;
               object-src 'none';
               script-src 'self'
                          'wasm-unsafe-eval';
               style-src 'self';
               upgrade-insecure-requests;">

Fügen Sie zusätzliche script-src- und style-src-Hashes hinzu, die von der App benötigt werden. Verwenden Sie während der Entwicklung ein Onlinetool oder Browserentwicklertools, damit die Hashes für Sie berechnet werden. Beispielsweise meldet der folgende Fehler einer Browsertoolkonsole den Hash für ein erforderliches Skript, das nicht durch die Richtlinie abgedeckt ist:

Die Ausführung des Inlineskripts wurde verweigert, da es die folgende Anweisung der Inhaltssicherheitsrichtlinie verletzt: „...“. Zum Aktivieren der Inlineausführung ist entweder das Schlüsselwort „unsafe-inline“, ein Hash („sha256-v8v3RKRPmN4odZ1CWM5gw80QKPCCWMcpNeOmimNL2AA=“) oder eine Nonce („nonce-...“) erforderlich.

Das Skript, das diesem Fehler zugeordnet ist, wird neben dem Fehler in der Konsole angezeigt.

Anwenden eines CSP in Nicht-Development-Umgebungen

Wenn ein CSP auf den <head>-Inhalt einer Blazor App angewendet wird, beeinträchtigt dies lokale Tests in der Development-Umgebung. Beispielsweise können der Browserlink und das Browseraktualisierungsskript nicht geladen werden. Die folgenden Beispiele veranschaulichen, wie das CSP-Tag <meta> in Nicht-Development-Umgebungen angewendet wird.

Hinweis

In den Beispielen in diesem Abschnitt wird das vollständige <meta> -Tag für die CSPs nicht angezeigt. Die vollständigen <meta> -Tags finden Sie in den Unterabschnitten des Abschnitts Richtlinie anwenden weiter oben in diesem Artikel.

Es stehen drei allgemeine Ansätze zur Verfügung:

• Wenden Sie den CSP über die App -Komponente an, die den CSP auf alle Layouts der App anwendet.
• Wenn Sie CSPs auf verschiedene Bereiche der App anwenden müssen, z. B. einen benutzerdefinierten CSP nur für die Administratorseiten, wenden Sie die CSPs pro Layout mithilfe des <HeadContent> Tags an. Zur vollständigen Effektivität muss jede App-Layoutdatei den Ansatz übernehmen.
• Der Hostingdienst oder -server kann einen CSP über einen Content-Security-Policy Header bereitstellen, der die ausgehenden Antworten einer App hinzugefügt hat. Da dieser Ansatz je nach Hostingdienst oder Server variiert, wird er in den folgenden Beispielen nicht behandelt. Wenn Sie diesen Ansatz übernehmen möchten, lesen Sie die Dokumentation ihres Hostingdienstanbieters oder Servers.

Blazor Web App Ansätze

IHostEnvironment in die App Komponente (Components/App.razor) einfügen:

@inject IHostEnvironment Env

Wenden Sie im <head>-Inhalt der App Komponente den CSP an, wenn Sie nicht die Development-Umgebung verwenden:

@if (!Env.IsDevelopment())
{
    <meta ...>
}

Alternativ können Sie CSPs pro Layout im Components/Layout -Ordner anwenden, wie im folgenden Beispiel veranschaulicht. Stellen Sie sicher, dass jedes Layout einen CSP angibt.

@inject IHostEnvironment Env

@if (!Env.IsDevelopment())
{
    <HeadContent>
        <meta ...>
    </HeadContent>
}

Blazor WebAssembly App-Ansätze

IWebAssemblyHostEnvironment in die App Komponente (App.razor) einfügen:

@using Microsoft.AspNetCore.Components.WebAssembly.Hosting
@inject IWebAssemblyHostEnvironment Env

Wenden Sie im <head>-Inhalt der App Komponente den CSP an, wenn Sie nicht die Development-Umgebung verwenden:

@if (!Env.IsDevelopment())
{
    <HeadContent>
        <meta ...>
    </HeadContent>
}

Verwenden Sie alternativ den vorherigen Code, wenden Sie jedoch CSPs pro Layout im Layout -Ordner an. Stellen Sie sicher, dass jedes Layout einen CSP angibt.

Einschränkungen für META-Tags

Die folgenden Direktiven werden von einer <meta>-Tagrichtlinie nicht unterstützt:

• frame-ancestors
• report-to
• report-uri
• sandbox

Zum Unterstützen der vorangehenden Anweisung verwenden Sie einen Header mit dem Namen Content-Security-Policy. Die Zeichenfolge der Anweisung ist der Wert des Headers.

Testen einer Richtlinie und Empfangen von Berichten zu Verstößen

Durch das Testen kann besser sichergestellt werden, dass Drittanbieterskripts beim Erstellen einer anfänglichen Richtlinie nicht versehentlich blockiert werden.

Legen Sie das <meta>-Attribut des http-equiv-Tags oder den Headernamen einer headerbasierten Richtlinie auf Content-Security-Policy-Report-Only fest, um eine Richtlinie eine Zeit lang zu testen, ohne die Richtlinienanweisungen zu erzwingen. Fehlerberichte werden als JSON-Dokumente an eine angegebene URL gesendet. Weitere Informationen finden Sie unter MDN Web Docs: Content-Security-Policy-Report-Only.

Informationen zur Berichterstattung zu Verstößen während einer aktiven Richtlinie finden Sie in folgenden Artikeln:

• report-to
• report-uri

Obwohl die Verwendung von report-uri nicht mehr empfohlen wird, sollten beide Anweisungen verwendet werden, bis report-to von allen wichtigen Browsern unterstützt wird. Verwenden Sie nicht ausschließlich report-uri, da die Unterstützung für report-uri von Browsern jederzeit beendet werden könnte. Entfernen Sie die Unterstützung für report-uri in Ihren Richtlinien, sobald report-to vollständig unterstützt wird. Die Einführung von report-to können Sie unter Can I use: report-to (Kann ich „report-to“ verwenden?) nachverfolgen.

Testen und aktualisieren Sie die Richtlinie einer App bei jedem Release.

Problembehandlung

• Fehler werden in der Konsole mit den Entwicklertools des Browsers angezeigt. Browser stellen Informationen über Folgendes bereit:
  • Elemente, die die Richtlinie nicht einhalten
  • Vorgehensweise zur Anpassung der Richtlinie, sodass ein blockiertes Element zugelassen wird
• Eine Richtlinie ist nur dann vollständig wirksam, wenn der Clientbrowser alle enthaltenen Anweisung unterstützt. Eine aktuelle Browserunterstützungsmatrix finden Sie unter Can I use: Content-Security-Policy (Kann ich Content-Security-Policy verwenden?).

Zusätzliche Ressourcen

• Anwenden eines CSP in C#-Code beim Start
• MDN-Webdokumente: Inhaltssicherheitsrichtlinie (Content Security Policy, CSP)
• MDN-Webdokumente: Inhaltssicherheitsrichtlinie-Antwortheader
• Content Security Policy Level 2
• Google CSP Evaluator