Content Security Policy Header für PrestaShop

Was Content Security Policy ist und warum es wichtig ist

Content Security Policy (CSP) ist ein Sicherheitsmechanismus, der über HTTP-Header implementiert wird und dem Browser genau mitteilt, welche Ressourcen auf Ihren Seiten geladen werden dürfen. Es verhindert Cross-Site-Scripting (XSS)-Angriffe, Dateninjektionsangriffe und andere Code-Injektionsschwachstellen, indem es Ihnen eine granulare Kontrolle darüber gibt, woher JavaScript, CSS, Bilder, Schriftarten, Frames und andere Ressourcen stammen dürfen.

Ohne CSP führt ein Browser jedes JavaScript aus, das er auf Ihrer Seite findet, unabhängig davon, woher es stammt. Wenn es einem Angreifer gelingt, ein bösartiges Skript zu injizieren (über ein anfälliges Modul, eine kompromittierte Drittanbieter-Bibliothek oder eine gespeicherte XSS-Schwachstelle), führt der Browser es bereitwillig mit vollem Zugriff auf den Seiteninhalt aus, einschließlich Kundendaten, Formulareingaben und Sitzungs-Cookies.

Mit CSP deklarieren Sie eine Whitelist vertrauenswürdiger Quellen. Wenn der Browser auf eine Ressource stößt, die nicht zur Richtlinie passt, blockiert er sie und protokolliert einen Verstoß. Das bedeutet, dass selbst wenn ein Angreifer einen Weg findet, Code in Ihre Seite einzuschleusen, der Browser die Ausführung verweigert, da er nicht von einer genehmigten Quelle stammt.

Für PrestaShop-Shops, die persönliche Kundendaten, Zahlungsdaten und Authentifizierungsdaten verarbeiten, ist CSP eine kritische Sicherheitsschicht. Es ersetzt nicht die Behebung von Schwachstellen in Ihrem Code, ist aber eine effektive Defense-in-Depth-Maßnahme, die den Schaden begrenzt, wenn eine Schwachstelle existiert.

CSP-Direktiven erklärt

Eine Content Security Policy besteht aus einer oder mehreren Direktiven, die jeweils einen bestimmten Ressourcentyp steuern. Die wichtigsten Direktiven für PrestaShop sind:

default-src: Die Fallback-Direktive. Wenn eine spezifischere Direktive nicht gesetzt ist, verwendet der Browser default-src. Das Setzen von default-src 'self' bedeutet, dass standardmäßig nur Ressourcen von Ihrer eigenen Domain erlaubt sind.

script-src: Steuert, von wo JavaScript geladen werden kann. Dies ist die kritischste Direktive zur XSS-Prävention. Übliche Werte sind 'self' (Ihre eigene Domain), bestimmte CDN-Domains und Analytics-Domains.

style-src: Steuert, von wo CSS geladen werden kann. PrestaShop-Themes und -Module verwenden häufig Inline-Stile, was bedeutet, dass Sie möglicherweise 'unsafe-inline' benötigen, es sei denn, Sie implementieren einen Nonce-basierten Ansatz.

img-src: Steuert, von wo Bilder geladen werden können. PrestaShop-Shops laden oft Bilder von ihrer eigenen Domain, CDN-Domains und Drittanbieterdiensten wie Google (für Benutzer-Avatare oder Maps).

font-src: Steuert, von wo Schriftarten geladen werden können. Google Fonts, Font Awesome CDN und Ihre eigene Domain sind gängige Quellen.

connect-src: Steuert, welche URLs über JavaScript kontaktiert werden können (AJAX-Anfragen, WebSocket-Verbindungen, EventSource). Zahlungsgateways, Analytics-Endpunkte und Ihre eigenen API-Endpunkte müssen hier aufgeführt werden.

frame-src: Steuert, welche Domains in Iframes eingebettet werden können. Zahlungsgateways wie PayPal, Stripe und Klarna verwenden Iframes für ihre Zahlungsformulare. YouTube- und Vimeo-Einbettungen erfordern ebenfalls frame-src-Einträge.

frame-ancestors: Steuert, welche Domains Ihre Seite in einem Iframe einbetten können. Das Setzen von frame-ancestors 'self' verhindert Clickjacking-Angriffe, indem sichergestellt wird, dass Ihr Shop nicht in den Iframe einer anderen Website eingebettet werden kann.

object-src: Steuert Plugin-Inhalte wie Flash. Setzen Sie dies auf 'none', da Flash veraltet ist und keine PrestaShop-Funktionalität es erfordert.

base-uri: Steuert, welche URLs im <base>-Element verwendet werden können. Setzen Sie es auf 'self', um Base-URI-Manipulationsangriffe zu verhindern.

form-action: Steuert, an welche URLs Formulare gesendet werden können. Dies sollte Ihre eigene Domain und alle externen Zahlungsverarbeitungsendpunkte einschließen.

Beginnen Sie mit dem Report-Only-Modus

Die Bereitstellung von CSP in einem PrestaShop-Shop erfordert sorgfältige Vorbereitung, da eine zu restriktive Richtlinie die Funktionalität beeinträchtigt. Der richtige Ansatz ist, mit dem Report-Only-Modus zu beginnen, der den Browser anweist, Verstöße zu melden, ohne tatsächlich etwas zu blockieren.

Anstatt den Content-Security-Policy-Header zu verwenden, verwenden Sie Content-Security-Policy-Report-Only. Dieser Header akzeptiert genau die gleichen Direktiven, generiert aber nur Berichte, ohne die Richtlinie durchzusetzen. Ihr Shop funktioniert weiterhin normal, während Sie Daten darüber sammeln, was blockiert werden würde.

Verstoßberichte einrichten

Fügen Sie Ihrer Richtlinie eine report-uri-Direktive hinzu, die auf einen Endpunkt zeigt, der Verstoßberichte sammelt. Sie können einen kostenlosen Dienst wie Report URI (report-uri.com) verwenden, der ein Dashboard zum Anzeigen und Analysieren von CSP-Verstößen bietet, oder Sie können Ihren eigenen Endpunkt einrichten.

Der Browser sendet Verstoßberichte als JSON-POST-Anfragen. Jeder Bericht enthält die blockierte URI, die verletzte Direktive, die Seite, auf der der Verstoß aufgetreten ist, und andere nützliche Debugging-Informationen. Das Sammeln dieser Berichte über ein oder zwei Wochen in einem Live-Shop gibt Ihnen ein umfassendes Bild aller Ressourcen, die Ihr Shop lädt, und woher sie stammen.

Ihre initiale Richtlinie erstellen

Erstellen Sie anhand der Verstoßberichte aus dem Report-Only-Modus eine Whitelist aller legitimen Ressourcenquellen. Gruppieren Sie sie nach Direktiventyp. Ihre initiale Richtlinie wird wahrscheinlich umfassen:

Ihre eigene Domain für alle Ressourcentypen. CDN-Domains (wie cdnjs.cloudflare.com, fonts.googleapis.com, fonts.gstatic.com) für Skripte, Stile und Schriftarten. Analytics-Domains (wie google-analytics.com, googletagmanager.com, connect.facebook.net) für Tracking. Zahlungsgateway-Domains für Skripte, Frames und Verbindungen. Chat-Widget-Domains, wenn Sie Live-Chat verwenden. Social-Media-Domains für eingebettete Inhalte oder Teilen-Buttons.

Eine CSP für PrestaShop erstellen

PrestaShop stellt spezifische Herausforderungen für die CSP-Implementierung aufgrund seiner Architektur und des Modul-Ökosystems dar.

Umgang mit Inline-Stilen und -Skripten

PrestaShop-Kern, Themes und viele Module verwenden Inline-Stile und Inline-JavaScript umfangreich. Inline-Code wird standardmäßig in CSP blockiert, da ein Angreifer, der Inhalte in Ihre Seite injiziert, Inline-Code injizieren würde. Es gibt drei Ansätze, um damit umzugehen:

'unsafe-inline' verwenden: Der einfachste, aber am wenigsten sichere Ansatz. Das Hinzufügen von 'unsafe-inline' zu script-src und style-src erlaubt allen Inline-Code, was den XSS-Schutz von CSP erheblich schwächt. Für style-src ist dies im Allgemeinen akzeptabel, da Inline-Stile ein viel geringeres Sicherheitsrisiko darstellen als Inline-Skripte. Für script-src vermeiden Sie 'unsafe-inline' wenn irgend möglich.

Nonces verwenden: Der empfohlene Ansatz. Ein Nonce ist ein zufälliges, einmalig verwendetes Token, das bei jeder Anfrage generiert wird. Sie fügen den Nonce zu Ihrem CSP-Header (script-src 'nonce-abc123') und zu jedem legitimen Inline-Script-Tag (<script nonce="abc123">) hinzu. Der Browser führt nur Inline-Skripte mit dem korrekten Nonce aus. Da sich der Nonce bei jeder Anfrage ändert und ein Angreifer ihn nicht vorhersagen kann, werden injizierte Skripte ohne Nonce blockiert.

Die Implementierung von Nonces in PrestaShop erfordert die Änderung des Themes, um Nonce-Attribute zu allen Inline-Script-Tags hinzuzufügen, und die Erstellung eines Mechanismus (typischerweise ein Modul oder ein benutzerdefinierter Hook), der den Nonce generiert, ihn zum CSP-Header hinzufügt und ihn für Templates verfügbar macht. Dies ist ein erheblicher Implementierungsaufwand, bietet aber starken XSS-Schutz.

Hashes verwenden: Sie können bestimmte Inline-Skripte über ihren SHA-256-Hash whitelisten. Der Browser berechnet den Hash jedes Inline-Skripts und vergleicht ihn mit den im CSP aufgelisteten Hashes. Dieser Ansatz funktioniert für Inline-Skripte, die sich zwischen Anfragen nicht ändern (statische Inline-Skripte), ist aber für PrestaShop unpraktisch, da viele Inline-Skripte dynamische Inhalte wie Produkt-IDs, Preise und benutzerspezifische Daten enthalten, die den Hash ändern.

Umgang mit eval und dynamischem Code

Einige JavaScript-Bibliotheken verwenden eval() oder new Function(), um dynamisch Code zu erstellen und auszuführen. CSP blockiert diese standardmäßig. Wenn ein Modul oder eine Bibliothek eval benötigt, müssen Sie 'unsafe-eval' zu script-src hinzufügen. Häufige Verursacher sind ältere Versionen von jQuery-Templates, einige Analytics-Skripte und bestimmte Zahlungsgateway-Bibliotheken.

Prüfen Sie Ihre Verstoßberichte auf Einträge mit eval oder inline als blockierte URI. Diese weisen auf Code hin, der dynamische Auswertung verwendet. Ersetzen Sie die Bibliothek wenn möglich durch eine Version, die eval nicht verwendet. Wenn das nicht möglich ist (z. B. bei einer Zahlungsgateway-Bibliothek eines Drittanbieters, die Sie nicht ändern können), ist 'unsafe-eval' die einzige Option.

Drittanbieter-Dienste

Die meisten PrestaShop-Shops sind auf mehrere Drittanbieter-Dienste angewiesen, die jeweils in Ihrer CSP auf die Whitelist gesetzt werden müssen. Hier sind die häufigsten und die Direktiven, die sie benötigen:

Google Analytics und Google Tag Manager: Diese erfordern Einträge in script-src für www.google-analytics.com, www.googletagmanager.com und tagmanager.google.com. Sie benötigen auch connect-src-Einträge für www.google-analytics.com und analytics.google.com (zum Senden von Tracking-Daten) sowie img-src-Einträge für www.google-analytics.com (für das Tracking-Pixel). Google Tag Manager ist besonders herausfordernd, da er dynamisch Skripte von Domains lädt, die Sie möglicherweise nicht im Voraus kennen, da die geladenen Skripte von den in GTM konfigurierten Tags abhängen.

PayPal: Erfordert script-src- und frame-src-Einträge für *.paypal.com und *.paypalobjects.com. Die genauen Domains hängen davon ab, ob Sie PayPal Standard, PayPal Express oder die neuere PayPal Commerce Platform-Integration verwenden.

Stripe: Erfordert script-src für js.stripe.com, frame-src für js.stripe.com und hooks.stripe.com, sowie connect-src für api.stripe.com.

Google Fonts: Erfordert style-src für fonts.googleapis.com und font-src für fonts.gstatic.com.

YouTube-Einbettungen: Erfordern frame-src für www.youtube.com und www.youtube-nocookie.com.

Facebook Pixel und Social Plugins: Erfordern script-src und connect-src für connect.facebook.net und www.facebook.com, plus img-src für www.facebook.com und *.fbcdn.net.

Live-Chat-Widgets (Tidio, Crisp, Intercom usw.): Jedes hat seinen eigenen Satz von Domains für Skripte, Stile, WebSocket-Verbindungen und Bilder. Prüfen Sie Ihre Verstoßberichte oder die Dokumentation des Anbieters für die genauen erforderlichen Domains.

Ein vollständiges CSP-Beispiel für PrestaShop

Hier ist ein realistischer CSP-Header für einen PrestaShop-Shop, der Google Analytics, Google Fonts, PayPal, YouTube-Einbettungen verwendet und Inline-Stile hat:

Content-Security-Policy: default-src 'self'; script-src 'self' www.google-analytics.com www.googletagmanager.com js.stripe.com 'unsafe-inline' 'unsafe-eval'; style-src 'self' fonts.googleapis.com 'unsafe-inline'; img-src 'self' data: www.google-analytics.com *.paypal.com; font-src 'self' fonts.gstatic.com; connect-src 'self' www.google-analytics.com analytics.google.com api.stripe.com; frame-src 'self' www.youtube.com www.youtube-nocookie.com js.stripe.com *.paypal.com; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self' *.paypal.com;

Diese Richtlinie enthält 'unsafe-inline' und 'unsafe-eval' für Skripte, was den XSS-Schutz schwächt, aber für die meisten PrestaShop-Installationen notwendig ist, die nicht für die Unterstützung von Nonces modifiziert wurden. Für img-src ist die data:-Quelle enthalten, da PrestaShop und viele Module Data-URIs für kleine Bilder und Icons verwenden.

CSP in PrestaShop implementieren

Über .htaccess (Apache)

Für Apache-Server fügen Sie den CSP-Header in Ihrer .htaccess-Datei hinzu. Platzieren Sie ihn am Anfang der Datei, vor den PrestaShop-Umschreibungsregeln:

Header set Content-Security-Policy "default-src 'self'; script-src 'self' ..."

Dies erfordert, dass das Modul mod_headers aktiviert ist. Sie können überprüfen, ob Ihr Server den Header zurückgibt, indem Sie die Browser-DevTools verwenden (Tab Netzwerk, auf die Hauptdokumentanfrage klicken, Antwort-Header prüfen).

Über Nginx-Konfiguration

Für Nginx fügen Sie den Header in Ihrem Server-Block hinzu:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' ..." always;

Der Parameter always stellt sicher, dass der Header auch für Fehlerantworten gesendet wird, was wichtig ist, da Fehlerseiten ebenfalls Ziele für XSS-Angriffe sein können.

Über ein PrestaShop-Modul

Die Implementierung von CSP über ein Modul gibt Ihnen die Möglichkeit, die Richtlinie vom Back-Office aus zu verwalten. Das Modul hakt sich in den actionOutputHTMLBefore ein oder verwendet PHPs header()-Funktion in einem Front-Controller-Hook, um den CSP-Header zu jeder Antwort hinzuzufügen. Ein modulbasierter Ansatz ist einfacher zu warten, da Sie die Richtlinie aktualisieren können, ohne Serverkonfigurationsdateien zu bearbeiten und ohne den Webserver neu zu starten.

Testen Ihrer CSP mit Browser-DevTools

Verwenden Sie nach der Implementierung Ihrer CSP (zunächst im Report-Only-Modus) die Browser-DevTools, um Verstöße zu überwachen. Öffnen Sie den Konsolen-Tab und suchen Sie nach Nachrichten, die mit "[Report Only]" (im Report-Only-Modus) oder "Refused to" (im Durchsetzungsmodus) beginnen. Jede Nachricht sagt Ihnen genau, was blockiert wurde und welche Direktive verantwortlich war.

Testen Sie jeden Seitentyp in Ihrem Shop: die Startseite, Kategorieseiten, Produktseiten, den Warenkorb, den Checkout-Prozess (einschließlich jedes Schritts und jeder Zahlungsmethode), die Kundenkontoseiten und CMS-Seiten. Jeder Seitentyp kann unterschiedliche Ressourcen laden, und Sie müssen sicherstellen, dass Ihre Richtlinie alle abdeckt.

Achten Sie besonders auf den Checkout-Prozess. Ein blockiertes Zahlungsgateway-Skript oder -Iframe während des Checkouts verhindert direkt, dass Kunden ihre Käufe abschließen. Testen Sie jede Zahlungsmethode, die Sie anbieten, einschließlich des 3D-Secure-Verifizierungsablaufs, falls zutreffend, da diese oft zusätzliche Ressourcen von Domains laden, die nicht offensichtlich sind.

Häufige Testfallen

Tests in einer Entwicklungsumgebung decken möglicherweise nicht alle Verstöße auf, da Ihr Entwicklungs-Setup möglicherweise nicht alle Drittanbieter-Dienste enthält, die in der Produktion laufen (Analytics, Werbepixel, Live-Chat, A/B-Testtools). Stellen Sie CSP immer zuerst im Report-Only-Modus in der Produktion bereit und sammeln Sie mindestens ein bis zwei Wochen lang Berichte, bevor Sie zur Durchsetzung wechseln.

Einige Verstöße treten nur unter bestimmten Bedingungen auf. Zum Beispiel könnte ein Zahlungsgateway zusätzliche Verifizierungsskripte nur laden, wenn die Karte eines Kunden eine 3D-Secure-Authentifizierung erfordert. Social-Sharing-Buttons laden möglicherweise Skripte erst, wenn ein Besucher sie anklickt. Dynamische Inhalte, die über AJAX geladen werden, können Ressourcen referenzieren, die beim initialen Seitenaufruf nicht vorhanden sind. Durchlaufen Sie jeden möglichen Benutzerablauf beim Testen.

Schrittweise Durchsetzungsstrategie

Die empfohlene Bereitstellungsstrategie für CSP auf PrestaShop folgt diesen Schritten:

Phase 1: Erkundung. Stellen Sie einen permissiven Content-Security-Policy-Report-Only-Header mit default-src * 'unsafe-inline' 'unsafe-eval' data: blob:; und einer report-uri bereit. Dies protokolliert alle Ressourcen ohne etwas zu blockieren und gibt Ihnen ein vollständiges Inventar dessen, was Ihr Shop lädt.

Phase 2: Richtlinienentwurf. Basierend auf den Verstoßberichten erstellen Sie eine Whitelist-Richtlinie, die alle legitimen Ressourcen abdeckt. Stellen Sie sie im Report-Only-Modus bereit und überwachen Sie Verstöße, die darauf hinweisen, dass Sie eine Ressource übersehen haben.

Phase 3: Verfeinerung. Prüfen Sie über ein bis zwei Wochen täglich die Verstoßberichte und fügen Sie alle legitimen Quellen hinzu, die Sie übersehen haben. Achten Sie auf Berichte, die von bestimmten Seitentypen oder Benutzerabläufen stammen, die Sie möglicherweise nicht manuell getestet haben.

Phase 4: Durchsetzung. Wechseln Sie von Content-Security-Policy-Report-Only zu Content-Security-Policy. Behalten Sie die report-uri-Direktive bei, damit Sie weiterhin Verstoßberichte erhalten. Überwachen Sie in der ersten Woche nach der Durchsetzung genau, um legitime Ressourcen zu finden, die blockiert werden.

Phase 5: Verschärfung. Sobald die Durchsetzung stabil ist, suchen Sie nach Möglichkeiten, die Richtlinie zu verschärfen. Können Sie 'unsafe-inline' in script-src durch Nonces ersetzen? Können Sie Wildcard-Domains auf bestimmte Subdomains eingrenzen? Können Sie Quellen entfernen, die nicht mehr verwendet werden? Jeder Verschärfungsschritt verbessert Ihre Sicherheitslage.

Pflege Ihrer CSP

Eine CSP ist keine Einmal-und-Vergessen-Konfiguration. Jedes Mal, wenn Sie ein neues Modul installieren, einen Drittanbieter-Dienst hinzufügen, Zahlungsgateways wechseln oder Ihr Theme aktualisieren, müssen Sie möglicherweise Ihre CSP aktualisieren, um neue Ressourcenquellen einzuschließen. Machen Sie die CSP-Überprüfung zum Teil Ihres Modul-Installations- und Aktualisierungsprozesses.

Halten Sie Ihre report-uri auch nach der Durchsetzung aktiv, damit Sie Warnungen über neue Verstöße erhalten. Ein plötzlicher Anstieg der Verstoßberichte könnte darauf hinweisen, dass ein Modul-Update neue Ressourcenanforderungen eingeführt hat, oder es könnte auf einen tatsächlichen XSS-Angriffsversuch hinweisen, den Ihre CSP erfolgreich blockiert. In beiden Fällen möchten Sie davon erfahren.

Dokumentieren Sie Ihre CSP und den Grund für jeden Eintrag. Im Laufe der Zeit sammeln sich Einträge für Dienste an, die Sie nicht mehr nutzen. Regelmäßige Überprüfungen zur Entfernung unnötiger Einträge halten die Richtlinie sauber und reduzieren die Angriffsfläche. Eine CSP mit weniger erlaubten Quellen ist inhärent sicherer als eine mit vielen.