Content Security Policy und Neos CMS 

CSP als Herausforderung

Was ist die Content-Security-Policy?

Die Content Security Policy (CSP) ist eine Sicherheitsrichtlinie. Mit HTTP Response Headers wird den Browsers von Endnutzern mitgeteilt, welchen Elementen einer Webseite, Webapplikation, Webshop vertrauten werden soll.

Das vorwiegende Ziel von CSP  ist es, XSS-Angriffe (Cross-Site Scripting) zu verhindern oder zumindest deutlich zu erschweren. Aus diesem Grund wird CSP unter anderem von mächtigen Internetgrößen wie Google aktiv vorangetrieben und ist mittlerweile in unterschiedlichen Ausprägungen in allen gängigen Browsern implementiert. Als Endnutzer ist die Anwendung von CSP im Browser üblicherweise nicht bemerkbar, da es die Kommunikation zwischen Browser und Server betrifft.

Funktionsweise:
Im HTTP-Response wird eine Liste erlaubter Quellen für Bilder, Schriften, Skripte, Stylesheets usw. definiert. Alle Inhalte, die nicht in dieser Liste aufgeführt sind, werden vom Browser blockiert und nicht geladen.

Durch die Verwendung von CSP muss im Grunde für jede Ressource – sei es ein iframe, ein Bild, JavaScript, CSS oder anderes – explizit angegeben werden, von welchen Quellen sie geladen werden darf, damit die Website wie geplant funktioniert.
Wenn sich beispielsweise ein externes Skript ändert, etwa weil ein eingebettetes Skript plötzlich zusätzliche Ressourcen nachlädt, weil das Cookie-Zustimmungstool auf einen anderen Server umgezogen ist oder der Tag-Manager neue Inhalte einbindet, werden diese Zugriffe blockiert – sofern sie nicht in der Liste der erlaubten Quellen definiert wurden.

Dies führt dazu, dass die Pflege der CSP-Regeln bei dynamisch erzeugten oder häufig wechselnden Ressourcen aufwendig und komplex werden kann.

CSP kann man sich auch als eine Art Firewall vorstellen, die direkt im Browser verankert ist. Die Regeln für diese Firewall werden vom Server übermittelt und können theoretisch bei jeder Anfrage angepasst werden. Wie bei jeder Firewall stellt sich die Frage, wie streng man sie konfigurieren möchte: Je restriktiver die Einstellungen, desto höher die Sicherheit – allerdings kann dies auch die Nutzbarkeit der Website einschränken.

Der Hauptgrund für die Einführung dieser Technik sind zahlreiche Angriffe in der Vergangenheit, insbesondere auf dynamische Websites.

CSP  - Wichtig zu wissen

Aktiv Themenbehandlung von Zielkonflikten, Herausforderungen und Spannungsverhältnissen

Zielkonflikt: Performance vs. Security

Bei der Entwicklung moderner Websites gibt es einen grundlegenden Zielkonflikt zwischen optimaler Performance und höchstmöglicher Sicherheit. CSP wird in der Regel über HTTP Response Headers integriert. Je höher die Anzahl dieser CSP-Einträge ist, desto mehr muss zwischen Browser und Server abgearbeitet werden, was Zeit kostet. 
Ein Maximum an Performance kann beispielsweise unter anderem dadurch erreicht, dass Inline-Styles und Inline-Skripte direkt im HTML-Response ausgeliefert werden. Der Vorteil: JavaScript- und CSS-Code sind sofort verfügbar, wodurch zusätzliche HTTP-Requests vermieden werden – was sich positiv auf das Google PageSpeed Insight Ranking auswirken kann.

Allerdings verbietet eine konsequente Anwendung der Content Security Policy (CSP) den Einsatz von Inline-Code. Stattdessen müssen alle Skripte und Styles über externe .js- bzw. .css-Dateien eingebunden werden. Dies kann die Ladezeiten erhöhen und somit die Performance – und möglicherweise auch den PageRank – negativ beeinflussen.
(Quelle)

Um ein hohes Sicherheitsniveau zu erreichen, bei dem XSS-Angriffe nahezu ausgeschlossen sind, muss die CSP sehr restriktiv konfiguriert werden. Das bedeutet: Für jede einzelne Seite wird ein spezifischer CSP-Header gesetzt, der dem Browser ausschließlich das Laden von Inhalten erlaubt, die vom Entwickler explizit freigegeben wurden.

Herausforderung: CSP vs. Google Tag Manager

Beim Einführen einer Content Security Policy auf einer Website sollte unbedingt ein Audit der aktuell eingesetzten Tools durchgeführt werden – insbesondere, wenn diese auch nach der Umstellung weiterhin genutzt werden sollen.

Achtung: Wird die CSP ohne Freigabe der entsprechenden Domains gesetzt, können beispielsweise Tracking-Dienste wie Google Analytics oder Facebook Pixel vollständig blockiert werden – und damit auch das damit verbundene Remarketing.

Auch der Einsatz des Google Tag Managers (GTM) muss explizit durch die CSP erlaubt werden. Es reicht allerdings nicht aus, lediglich die Domain www.googletagmanager.com freizuschalten. Ohne zusätzliche Freigaben für benutzerdefinierte Inhalte (z. B. eigene JavaScript-Variablen oder GTM-Templates) funktionieren viele Funktionen des GTM nicht korrekt.
(Quelle)

Spannungsverhältnis: User Experience vs. Security

Auch zwischen Benutzerfreundlichkeit und Sicherheit besteht ein Spannungsverhältnis.
Eine streng konfigurierte CSP, die XSS wirksam unterbindet, erlaubt dem Browser nur genau das, was im HTML-Code explizit zugelassen wurde. Anders gesagt: CSP bedeutet, dem Browser mitzuteilen, was erlaubt ist – und nicht, was verboten ist.

Wenn ein externes Skript versucht, zusätzliche Ressourcen nachzuladen, die nicht explizit freigegeben wurden, blockiert der Browser diese.
Das kann zwar sicherheitstechnisch sinnvoll sein, führt in der Praxis aber häufig zu Problemen oder Verwirrung: „Warum funktioniert das plötzlich nicht mehr?“ – und erhöht so den Aufwand bei der Fehlersuche. Hier besteht ein reales Risiko für die User Experience.

Nutzung von CSP bei Webseiten

Die Akzeptanz von Content Security Policy (CSP) auf Websites nimmt zu, allerdings auf niedrigen Niveau.

Auch wenn Studienergebnisse unterschiedlich sind z.B. weniger als 10% der HTTP-Antworten enthalten einen CSP-Header und/oder ein Meta-Tag.  Jede vierte der 1.000 meistbesuchten Websites verfügt in irgendeiner Form über eine CSP-Implementierung, wobei die Art und Effektivität stark differieren. Die Studien weisen in der Regel darauf hin, dass CSP-Header bzw. andere CSP-Element in einigen Fällen erkannt wurden, jedoch war die Umsetzung häufig unvollständig oder fehlerhaft. So wird darauf hingewiesen, dass aufgrund der Verwendung unsicherer Praktiken wie Inline-Skripte oder der Richtlinie „unsafe-eval“, die die Wirksamkeit der Richtlinie untergraben werden.

Vor diesem Hintergrund kann angenommen werden, dass  eine allgemeinen Annahme und Nutzung von CSP  noch weit entfernt ist. Während das Bewusstsein für die Sicherheitsvorteile und die Bereitstellung von kompatiblen Frameworks und Library zunehmen, bleibt die vollständige und korrekte Umsetzung für viele Website-Betreiber und -Entwickler eine Herausforderung.

Herausforderungen bei der Einführung:

  • Hohe Komplexität: Die Konfiguration einer umfassenden CSP erfordert die genaue Definition aller vertrauenswürdigen Inhaltsquellen – insbesondere bei großen oder dynamischen Websites eine anspruchsvolle Aufgabe.
  • Wartungsaufwand: Änderungen an Inhalten oder Drittanbieter-Integrationen erfordern eine laufende Anpassung der Richtlinie.
  • Kompatibilitätsrisiken: Strikte CSPs können bestehende Funktionen beeinträchtigen, etwa wenn Inline-Skripte oder externe Ressourcen blockiert werden. Dies führt häufig zu vorsichtiger oder unvollständiger Umsetzung.
  • Fehlkonfigurationen: Viele CSP-Implementierungen sind zu lasch oder fehlerhaft, wodurch die Sicherheitswirkung verloren geht.
  • Überwachungsaufwand: Für effektive CSP-Nutzung ist die Einrichtung eines Reportingsystems zur Erkennung und Analyse von Richtlinienverstößen erforderlich.

Fazit: Obwohl die Akzeptanz von CSP als wertvolle Sicherheitsmaßnahme innerhalb der Sicherheits- und Entwicklungsgemeinschaften hoch ist, weisen der tatsächliche Einsatz und die effektive Implementierung auf einer großen Anzahl von Websites immer erhebliche Verbesserungspotenziale auf.

Quellen:
https://www.bitsight.com/blog/content-security-policy-limits-dangerous-activity-so-why-isnt-everyone-doing-it
https://bluetriangle.com/blog/why-are-so-many-major-websites-operating-without-a-content-security-policy-csp
https://arxiv.org/abs/2410.14924
https://arxiv.org/abs/2309.07782
https://ieeexplore.ieee.org/document/10190533
https://owasp.org/www-chapter-germany/stammtische/hamburg/assets/slides/2021-03-16%20Content%20Security%20Policy%20-%20Past,%20Present,%20Future.pdf

CSP-Implementierung beim Neos CMS

Es gibt keine native Unterstützung, doch es können Packages und verschiedene Ansätze verwendet werden.

Die Integration von Content Security Policy (CSP) in Neos CMS ist nicht nativ im Core-System vorhanden. Allerdings gibt es mehrere Ansätze und Packages von Drittanbietern, um CSP in Neos-Projekten zu implementieren.

  1. nieuwenhuizen/content-security-policy:
  2. flowpack/content-security-policy:
  3. codeq/csp-report-endpoint:

Diese Pakete bieten unterschiedliche Ansätze und Funktionalitäten, um CSP in Neos-Projekten zu implementieren. Die Wahl des passenden Pakets hängt von den spezifischen Anforderungen des Projekts ab. Es ist ratsam, sich die Dokumentationen der jeweiligen Pakete genauer anzusehen, um die für den eigenen Anwendungsfall beste Lösung zu finden.

Generelle Beobachtungen und mögliche Herausforderungen:

  • Backend-Komplexität: Das Neos-Backend wird anders gerendert als das Frontend, was eine separate CSP-Konfiguration für den Backend-Bereich erforderlich machen kann (wie im nieuwenhuizen/content-security-policy-Paket berücksichtigt).
  • Inline-Styles und -Skripte: Viele Neos-Projekte verwenden Inline-Styles oder -Skripte, die mit einer restriktiven CSP-Richtlinie in Konflikt geraten können. Hier sind der Einsatz von Nonces oder Hash-basierten Lösungen notwendig.
  • Drittanbieter-Ressourcen: Die Einbindung von Ressourcen von Drittanbietern (z.B. Analyse-Tools, Social-Media-Plugins) erfordert eine sorgfältige Konfiguration der CSP-Direktiven, um diese weiterhin zuzulassen.
  • Wartung und Aktualisierung: CSP-Richtlinien müssen kontinuierlich überwacht und bei Änderungen an der Website oder den verwendeten Diensten angepasst werden, um die Sicherheit aufrechtzuerhalten, ohne die Funktionalität zu beeinträchtigen.
  • Reporting: Die Einrichtung eines CSP-Reporting-Mechanismus ist entscheidend, um Verstöße zu erkennen und die Richtlinien zu optimieren.