Wie konfiguriert man eine Content Security Policy für FastReport .NET WEB-Berichte

Die Content Security Policy (CSP) ist ein wichtiges Werkzeug zum Schutz von Webanwendungen vor XSS-Angriffen, aber ihre Integration mit Berichtssystemen ist oft mit Schwierigkeiten verbunden. In den neuesten Versionen von FastReport .NET WEB wurde die clientseitige Architektur grundlegend überarbeitet, was die Einhaltung einer strengen CSP erleichtert, ohne die Funktionalität der Berichte einzuschränken. In diesem Artikel werden wir untersuchen, wie man CSP für FastReport-Berichte richtig konfiguriert und typische Risiken berücksichtigt.

Wie CSP funktioniert und warum es benötigt wird

Die Content Security Policy (CSP) ist ein Sicherheitsmechanismus oder sogar ein Standard für Webanwendungen, der es ermöglicht, die Ressourcen (Skripte, Stile, Schriftarten, Bilder, Verbindungen usw.) zu steuern, die auf einer Seite geladen und ausgeführt werden dürfen. CSP wird über den HTTP-Header Content-Security-Policy oder das HTML-Meta-Tag implementiert.
Das Hauptziel von CSP ist die Verhinderung von Cross-Site Scripting (XSS)-Angriffen und der Einführung von bösartigem Code. Die Richtlinie verbietet die Ausführung von nicht signierten oder nicht autorisierten Skripten, selbst wenn es einem Angreifer gelingt, ein <script>-Tag in die Seite einzufügen.

Darüber hinaus kann CSP:

• Die Übertragung von Daten an Drittanbieter-Domänen einschränken.
• Die Verwendung von eval() und ähnlichen Konstrukten steuern.
• Das Laden unerwünschter Stile, Schriftarten oder Plugins blockieren.

Wichtige CSP-Direktiven

Wichtige CSP-Werte

• 'self' —  nur die eigene Domäne (einschließlich Schema und Port).
• 'unsafe-inline' — Inline-Skripte und -Stile zulassen (mit Vorsicht verwenden).
• 'unsafe-eval' — eval() und ähnliche Konstrukte zulassen.
• 'nonce-{value}' — einmaliges kryptografisches Token.
• 'sha256-{hash}' — Hash des Inhalts eines Inline-Skripts/Stils.
• data: — data:-URLs zulassen (relevant für Bilder).
• https: — alle HTTPS-Quellen zulassen.

Beispiel für die Aktivierung von CSP in ASP .NET Core-Anwendungen:

app.Use(async (context, next) =>
{
	context.Response.Headers.ContentSecurityPolicy = "script-src 'self' 'unsafe-inline' 'unsafe-eval';style-src 'self' 'unsafe-inline'";
	await next();
});

Sie können dies auch in der HTML-Markup-Datei tun:

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

Änderungen in der clientseitigen Architektur von FastReport .NET WEB

In den neuesten Versionen von FastReport .NET WEB wurde die clientseitige Architektur grundlegend überarbeitet:

• JavaScript-Skripte wurden in statische Dateien verschoben – es ist nicht mehr notwendig, unsafe-inline für Skripte anzugeben.
• Stile für Steuerelemente wurden zu statischen CSS-Dateien – dies vereinfacht das Erscheinungsbild.

Wichtiger Hinweis zu Inline-Stilen in Berichten: für den Inhalt von Berichtseiten generierte Stile (Tabellen, Text, Rahmen) bleiben Inline-Stile. Für die korrekte Anzeige des Berichts ist es notwendig, unsafe-inline in der style-src-Direktive zuzulassen.

Die Verschiebung von JS und CSS in statische Dateien hat nicht nur die Kompatibilität mit CSP ermöglicht, sondern auch die Möglichkeit, WebReport-Stile zu überschreiben, ohne die Quelldateien zu ändern (z. B. über eine zusätzliche CSS-Datei mit höherer Priorität). Darüber hinaus wurde das Verhalten erweitert; jetzt können Sie Ihre eigenen Skripte verbinden, Methoden überschreiben und Handler hinzufügen. Und natürlich hat sich das Caching verbessert – der Browser lädt den statischen Inhalt nur einmal.

Szenarien für das Umgehen von CSP und Möglichkeiten, sich davor zu schützen

Trotz der Zuverlässigkeit von CSP gibt es Szenarien, in denen es umgangen werden kann. Die meisten davon hängen nicht mit den Schwächen des Standards zusammen, sondern mit Implementierungsfehlern.

1. Schwache Browser-Unterstützung

Internet Explorer unterstützt CSP nur teilweise – er kann wichtige Direktiven ignorieren. Moderne Browser (Chrome, Opera, Safari, Firefox) funktionieren korrekt.

Lösung: Verlassen Sie sich nicht ausschließlich auf CSP in veralteten Browsern – verwenden Sie zusätzliche Sicherheitsmechanismen.

2. JavaScript innerhalb eines automatischen iframes

Beim Öffnen eines Textdokuments oder Bildes kann der Browser automatisch einen iframe-Wrapper erstellen. Diese Seite hat keine konfigurierte CSP, was die Ausführung von bösartigem Code ermöglicht.

Lösung: Konfigurieren Sie CSP für alle generierten Seiten, einschließlich herunterladbarer Ressourcen.

3. Fehlende CSP auf Fehlerseiten (4xx, 5xx)

Entwickler schützen oft nur funktionierende Seiten und vergessen die Fehler 404, 403, 500. Ein Angreifer kann ein Skript in einen Frame mit einer solchen Seite einfügen.

Lösung: Wenden Sie CSP global an – über Middleware oder einen Webserver (Nginx, IIS, Apache).

4. Laden von Skripten von Dateifreigabediensten

Einige Websites verwenden Cloud-Speicher (Google Drive) als Quellen für Inhalte. Ein Angreifer kann dort eine bösartige Datei oder ein Skript platzieren.

Lösung: Verwenden Sie 'unsafe-inline' und https: nicht in script-src, wenn dies nicht unbedingt erforderlich ist. Geben Sie stattdessen bestimmte Domänen an: script-src 'self' https://trusted-cdn.com;

Fazit: Sicherheit, Flexibilität und Leistung in der neuen Version von FastReport .NET WEB

Die neue Version von FastReport .NET WEB ermöglicht es Ihnen, Berichte sicher in Anwendungen mit einer strengen CSP-Richtlinie zu verwenden und dabei Ausnahmen wie unsafe-inline zu minimieren. Gleichzeitig erhält der Entwickler:

• Sicherheit – Schutz vor XSS-Angriffen.
• Flexibilität – einfache Anpassung von Aussehen und Verhalten.
• Leistung – durch das Caching statischer Inhalte.

Implementieren Sie eine strenge CSP in Ihren Projekten, ohne die Funktionalität der Berichte zu beeinträchtigen.