CONTENTSECURITYPOLICY - Detailbeschreibung

Open

Überblick

Parameter:CONTENTSECURITYPOLICY
Kategorie: Custom (Benutzerdefiniert)
Standardwert: "default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob: *.mapbox.com *.etask.de alcdn.msftauth.net login.microsoftonline.com wss://*.etask.de;"
Produkt: eTASK.Sonstige (Custom)

Was macht dieser Parameter?

Dieser Parameter implementiert die Sicherheitsmaßnahme "Content Security Policy" (CSP). CSP ist ein HTTP-Header, der dem Browser mitteilt, welche Ressourcen (JavaScript, CSS, Bilder, Schriften, etc.) von welchen Quellen geladen werden dürfen. Dies schützt vor Cross-Site-Scripting (XSS)-Angriffen, Code-Injection und anderen webbasierten Angriffen, indem unerwünschte Skripte blockiert werden.

Wofür wird dieser Parameter verwendet?

• Schutz vor Cross-Site-Scripting (XSS)-Angriffen

• Kontrolle über erlaubte Ressourcenquellen (Scripts, Styles, Bilder)

• Verhinderung von Code-Injection-Angriffen

• Einschränkung der Ausführung von Inline-Scripts und eval()

• Whitelist-basierte Sicherheitsarchitektur für externe Ressourcen

• Schutz vor unbeabsichtigtem Laden schädlicher Inhalte

Technische Details (für Administratoren)

Format: CSP-Direktive (String)
Standardwert:

Erklärung des Standardwerts:

• default-src = Fallback-Regel für alle Ressourcentypen

• 'self' = Ressourcen von der gleichen Domain erlaubt

• 'unsafe-inline' = Inline-JavaScript und Inline-CSS erlaubt (erforderlich für Ext.NET)

• 'unsafe-eval' = Verwendung von eval() erlaubt (erforderlich für Ext.NET)

• data: = Data-URIs erlaubt (Base64-kodierte Bilder, etc.)

• blob: = Blob-URLs erlaubt (für dynamisch generierte Inhalte)

• *.mapbox.com = Mapbox-Karten (Geodaten-Visualisierung)

• *.etask.de = eTASK-eigene Ressourcen und APIs

• alcdn.msftauth.net = Microsoft-Authentifizierung (Azure AD)

• login.microsoftonline.com = Microsoft Login

• wss://*.etask.de = WebSocket-Verbindungen zu eTASK-Servern

Spezielle Outlook-Add-in-Regel:

Für Pfade unter /neon/app.Etask/pub/OAI/ wird eine erweiterte CSP verwendet, die zusätzliche Microsoft-Domains erlaubt:

Wichtige Hinweise:

• Die CSP wird als HTTP-Header content-security-policy gesendet

• Aktivierung erfolgt über den Parameter CONTENTSECURITYPOLICYAKTIV

• Zeilenumbrüche werden automatisch durch Leerzeichen ersetzt

• ACHTUNG: Änderungen ohne Fachkenntnis können das Portal funktionsunfähig machen

• Test-Modus verfügbar (siehe CONTENTSECURITYPOLICYAKTIV)

Zusammenspiel mit anderen Parametern:

• CONTENTSECURITYPOLICYAKTIV: Steuert die Aktivierung (0=aus, 1=aktiv, 2=Report-only)

• XFRAMEOPTIONS: Ergänzende Sicherheitsmaßnahme gegen Clickjacking

• CONTENTTYPEOPTIONSNOSNIFFACTIVE: Verhindert MIME-Type-Sniffing

• XPERMITTEDCROSSDOMAINPOLICIES: Schutz vor Cross-Domain-Embedding

Wann sollten Sie diesen Wert ändern?

Wert auf Standard belassen, wenn:

• Sie keine speziellen externen Ressourcen einbinden

• Sie keine Expertise in CSP-Konfiguration haben

• Ihr Portal normal funktioniert

Wert anpassen, wenn:

• Spezielle JavaScript-Bibliotheken von CDNs geladen werden

• Custom-Entwicklungen externe Ressourcen benötigen

• Sicherheitsrichtlinien strengere CSP-Regeln vorschreiben

Achtung - Niemals ändern ohne:

• Umfassende Kenntnis der CSP-Syntax und -Direktiven

• Test in einer Entwicklungsumgebung

• Verwendung des Report-Only-Modus (CONTENTSECURITYPOLICYAKTIV = 2) zum Testen

• Backup der Ursprungskonfiguration

• Unterstützung durch erfahrene Web-Sicherheitsexperten

Wichtige Hinweise

1. Funktionstest nach Änderung zwingend erforderlich
   Jede Änderung der CSP kann dazu führen, dass Scripts, Styles oder externe Ressourcen blockiert werden und das Portal nicht mehr funktioniert. Testen Sie alle Funktionen gründlich!

2. Report-Only-Modus nutzen
   Bevor Sie eine neue CSP aktivieren, setzen Sie CONTENTSECURITYPOLICYAKTIV auf 2. So werden Verstöße nur protokolliert, aber nicht blockiert. Prüfen Sie die Logs und passen Sie die CSP an.

3. 'unsafe-inline' und 'unsafe-eval' erforderlich
   Das eTASK-Portal basiert auf Ext.NET, das inline-Scripts und eval() verwendet. Entfernen Sie diese Direktiven NICHT, da sonst das Portal komplett funktionsunfähig wird.

4. Browser-Konsole überwachen
   CSP-Verstöße werden in der Browser-Entwicklerkonsole (F12) angezeigt. Überwachen Sie diese nach Änderungen, um blockierte Ressourcen zu identifizieren.

5. Wildcards sparsam einsetzen
   Vermeiden Sie zu breite Wildcards (z.B. *), da diese die Sicherheit erheblich schwächen. Seien Sie so spezifisch wie möglich.

6. Dokumentation erforderlich
   Dokumentieren Sie jede Änderung der CSP, inklusive Begründung und Datum. Dies hilft bei späteren Problemen und Updates.

Sicherheit

Hat eine Änderung dieses Parameters Auswirkungen auf die Sicherheit?

Ja, dieser Parameter ist ein zentraler Sicherheitsmechanismus mit erheblichen Auswirkungen.

Positive Sicherheitsaspekte (bei korrekter Konfiguration):

• XSS-Schutz: Verhindert Ausführung eingeschleuster Scripts

• Code-Injection-Schutz: Blockiert unerwünschte externe Scripts

• Daten-Exfiltration-Schutz: Kontrolliert, wohin Daten gesendet werden können

• Whitelist-Prinzip: Nur explizit erlaubte Quellen werden akzeptiert

• Defense-in-Depth: Zusätzliche Sicherheitsebene neben anderen Maßnahmen

Sicherheitsrisiken bei falscher Konfiguration:

• Zu permissiv: Wildcards wie * oder https: machen CSP wirkungslos

• Fehlende Domains: Blockiert legitime Funktionen

• Zu restriktiv: Portal funktioniert nicht mehr

Empfohlene Sicherheits-Best-Practices:

1. Test-Modus verwenden: Neue CSP zunächst mit CONTENTSECURITYPOLICYAKTIV=2 testen

2. Minimalprinzip: Nur tatsächlich benötigte Domains erlauben

3. Regelmäßige Überprüfung: CSP bei jedem Portal-Update prüfen

4. Monitoring: CSP-Verstöße im Applikations-Log überwachen

5. Keine Kompromisse: Externe Dienste kritisch prüfen, bevor sie zur CSP hinzugefügt werden

Empfehlung: Die Standard-CSP ist für die meisten Installationen optimal. Ändern Sie sie nur, wenn absolut notwendig, und testen Sie ausgiebig. Unsichere Konfigurationen können das Portal zwar funktionsfähig halten, bieten aber keinen Schutz mehr gegen XSS-Angriffe.

Praktisches Beispiel

Ausgangssituation: Ihre Organisation möchte Google Analytics in das eTASK-Portal integrieren, um Nutzungsstatistiken zu erfassen. Nach der Integration zeigt die Browser-Konsole CSP-Verstöße: Google Analytics Scripts werden blockiert.

Problem: Die aktuelle CSP erlaubt keine Ressourcen von *.google-analytics.com oder *.googletagmanager.com. Die Analytics-Integration funktioniert nicht.

Lösung - Schritt für Schritt:

Schritt 1: Identifikation der benötigten Domains

Prüfen Sie die Browser-Konsole (F12) und identifizieren Sie alle blockierten Ressourcen: - https://www.google-analytics.com/analytics.js - https://www.googletagmanager.com/gtag/js

Schritt 2: CSP erweitern

Erweitern Sie die CONTENTSECURITYPOLICY:

Alte Konfiguration:

Neue Konfiguration:

Schritt 3: Test im Report-Only-Modus

1. Setzen Sie CONTENTSECURITYPOLICYAKTIV = 2 (Report-only)

2. Tragen Sie die neue CSP ein

3. Testen Sie das Portal über mehrere Tage

4. Prüfen Sie das Applikations-Log auf CSP-Verstöße

5. Stellen Sie sicher, dass alle Funktionen arbeiten

Schritt 4: Aktivierung

Wenn keine Probleme auftreten: 1. Setzen Sie CONTENTSECURITYPOLICYAKTIV = 1 (Aktiviert) 2. Überwachen Sie weiterhin Browser-Konsole und Logs 3. Dokumentieren Sie die Änderung

Nach der Änderung:

• Google Analytics Scripts werden geladen

• Nutzungsstatistiken werden erfasst

• Browser-Konsole zeigt keine CSP-Verstöße mehr

• Alle Portal-Funktionen arbeiten normal

• Sicherheitsniveau bleibt hoch (nur spezifische Domains hinzugefügt)

Ergebnis: Die Integration ist funktionsfähig, und die CSP schützt weiterhin vor unerwünschten Scripts. Nur die explizit benötigten Domains wurden hinzugefügt, nicht ein breiter Wildcard.

Empfohlene Einstellung

Für Standard-Installationen:Standardwert beibehalten

Begründung:

• Deckt alle Standard-eTASK-Funktionen ab

• Ermöglicht Mapbox-Karten, Azure-AD-Login, WebSockets

• Balanciert Sicherheit und Funktionalität

• Wurde umfassend getestet

• Regelmäßig durch eTASK aktualisiert

Ausnahmen (Anpassung erforderlich):

• Custom-Entwicklungen: Eigene externe Ressourcen oder APIs

• Drittanbieter-Integrationen: Analytics, Monitoring

• Spezielle CDNs: JavaScript-Bibliotheken von anderen CDNs

• Strengere Sicherheitsrichtlinien: Compliance-Anforderungen erfordern restriktivere CSP

Bei Änderungen beachten:

1. Dokumentieren: Jede Änderung mit Begründung dokumentieren

2. Testen: Ausgiebig in Report-Only-Modus testen

3. Spezifisch sein: Keine Wildcards wie https: oder * verwenden

4. Backup: Alte Konfiguration sichern

5. Monitoring: Logs nach Aktivierung überwachen

CSP-Direktiven verstehen:

Bevor Sie die CSP ändern, machen Sie sich mit den wichtigsten Direktiven vertraut:

• default-src: Standard für alle Ressourcentypen

• script-src: Nur für JavaScript (überschreibt default-src)

• style-src: Nur für CSS (überschreibt default-src)

• img-src: Nur für Bilder

• connect-src: Für AJAX, WebSocket, EventSource

• font-src: Für Schriftarten

• frame-src: Für Frames und iFrames

Wichtig: Ändern Sie CONTENTSECURITYPOLICY nur, wenn Sie die CSP-Spezifikation verstehen und die Konsequenzen abschätzen können. Im Zweifelsfall konsultieren Sie einen Web-Sicherheitsexperten oder den eTASK-Support.

IC2874