Content Security Policy (CSP) für Hoster #

Diese Seite ist für Systemadministratoren und Support-Mitarbeitende bei einem Hoster und für Produktmanager, die erwägen, die „Durchsetzung der CSP“ als Teil eines verwalteten Tarifs anzubieten. Eine Content Security Policy sagt dem Browser, welche Skripte, Styles, Bilder und Verbindungen eine Seite nutzen darf; mit einer strengen Richtlinie läuft ein Skript nicht, das über einen Wert eingeschleust wurde, den ein Template zu maskieren vergaß. Die Referenz ist Content Security Policy.

Inhalt #

1. Was mitgeliefert wird
2. Meldungen sammeln
3. Einen Siteaccess auf Durchsetzung umstellen
4. Was meist mehr als self braucht
5. Rückfall
6. Es als Dienst anbieten
7. Checkliste

Was mitgeliefert wird #

Die Richtlinie wird aus site.ini [ContentSecurityPolicy] gesendet, neben den fünf Sicherheitsheadern aus [HTTPHeaderSettings] SecurityHeaders[].

Die mitgelieferten Direktiven erlauben nur Dateien der Website selbst: script-src 'self' (kein Inline-<script>, keine Attribute on...=, keine Links javascript:, kein eval()), style-src 'self', object-src 'none', base-uri 'self', form-action 'self', frame-ancestors 'self', mit data: und blob: für Bilder und Medien. Mit Nonce=enabled (der Standard) bekommt jede Anfrage eine Nonce für script-src.

Also ändert sich in der Auslieferung für einen Besucher nichts: Die Administration meldet nur, die öffentlichen Websites senden keine Richtlinie. Durchsetzen ist eine Entscheidung pro Siteaccess, nach einer Prüfung getroffen.

Meldungen sammeln #

Der Kernel sammelt Meldungen selbst. Die Ansicht csp/report nimmt, was der Browser sendet, und schreibt pro Verstoß eine Zeile nach var/log/csp.log, im Log-Viewer als Berichte der Content Security Policy aufgeführt (Schlüssel csp). Richten Sie die Richtlinie pro Siteaccess darauf:

# settings/siteaccess/<admin siteaccess>/site.ini.append.php
[ContentSecurityPolicy]
ReportEndpoint=enabled

• Die Ansicht ist für jeden Besucher offen (Browser senden Meldungen ohne Anmeldung), antwortet mit einem Status und ohne Inhalt und wird nie zwischengespeichert.
• Sie ist pro Client (ReportsPerMinute=60) und insgesamt (ReportsPerMinuteTotal=600) begrenzt; eine Flut wird zu einer Zeile abuse/csp-report-flood pro Minute in security.log.
• Adressen werden wie in den Anfrage-Logs maskiert; die Fehlerübersicht gruppiert csp.log nach Direktive und blockierter Quelle.
• csp.log wird wie die Anfrage-Logs rotiert: 5 Archive, komprimiert, 10 MB, nach 30 Tagen bereinigt.

Siehe Meldungen.

Einen Siteaccess auf Durchsetzung umstellen #

Die Schritte aus Auf Durchsetzung umstellen, Schritt für Schritt, so wie ein Hoster sie für einen Kunden ausführt:

1. Prüfen Sie die Templates der Installation, mit jeder Erweiterung, die sie nutzt:

   CSP_ALL_EXTENSIONS=1 php vendor/bin/phpunit tests/tests/design/AdminContentSecurityPolicyTest.php

   Jede Zeile mit einem Fehler ist ein Template mit Inline-Code, das eine durchgesetzte Richtlinie kaputtmachen würde.

2. Sammeln Sie einige Tage lang Meldungen aus echter Nutzung mit ReportEndpoint=enabled: die Seiten jeder Erweiterung, die Editoren, die Dialoge und Kontextmenüs.

3. Setzen Sie zuerst einen Siteaccess durch, am besten einen zweiten Siteaccess der Administration, den nur der leitende Redakteur des Kunden nutzt, mit denselben Designs und Erweiterungen.

4. Lockern Sie nur, was Sie müssen, pro Siteaccess und pro Direktive, zum Beispiel einen Host für Karten:

   [ContentSecurityPolicy]
   Mode=enforce
   AdditionalSources[]=script-src https://maps.example.com

5. Leeren Sie den INI-Cache (php bin/php/ezcache.php --clear-tag=ini), laden Sie PHP-FPM neu und starten Sie Velocity neu, damit jeder Prozess den neuen Header sendet.

Für die öffentlichen Websites beginnen Sie mit Mode=report-only in ihrem Siteaccess; ihre Designs und der Rich Text, den sie rendern, sind vom Test nicht abgedeckt.

Tipp ReportOnlyDirectives[] sendet eine strengere Richtlinie im Berichtsmodus neben einer durchgesetzten, sodass Sie den Weg zu style-src 'self' messen können, während die durchgesetzte Richtlinie noch Styles mit 'unsafe-inline' erlaubt (Durchsetzen: Nonce, mehr Quellen, eine strengere Begleiterin, Rückfall).

Was meist mehr als self braucht #

Die klassischen Designs der Administration bleiben unter Mode=enforce über ReportOnlyDesigns[] (admin, admin2, admin_classic) im Berichtsmodus, sodass ein Benutzer, der eines mit dem Umschalter der Oberfläche wählt, eine funktionierende Seite behält. Siehe Bevor Sie auf der Administration durchsetzen.

Rückfall #

Setzen Sie Mode=report-only im Siteaccess, leeren Sie den INI-Cache, laden Sie PHP-FPM neu und starten Sie Velocity neu. Sonst ändert sich nichts: Dieselbe Richtlinie wird im Berichtsmodus gesendet, und die strengere Begleiterin wird nicht mehr gesendet.

# settings/siteaccess/<siteaccess>/site.ini.append.php
[ContentSecurityPolicy]
Mode=report-only

Es als Dienst anbieten #

Ein Hoster kann wählen, Arbeit an der CSP in einen verwalteten Tarif aufzunehmen. Was die Quellen als Umfang stützen:

• Sammeln von Meldungen auf der Administration ab dem ersten Tag (ReportEndpoint=enabled), mit Durchsicht der Übersicht im monatlichen Betriebsrundgang (Checkliste für den monatlichen Betrieb);
• ein Projekt zur Durchsetzung pro Website: die Prüfung, ein Zeitraum für Meldungen, zuerst ein Siteaccess, dann der Rest;
• eine Regel, dass Erweiterungen und Designs von Kunden vor dem Ausrollen auf Inline-Code geprüft werden.

Ob und wie Sie dafür abrechnen, entscheidet der Hoster; siehe Hosting-Tarife gestalten.

Checkliste #

• To do: ReportEndpoint=enabled auf dem Siteaccess der Administration; csp.log erscheint im Log-Viewer.
• To do: Die Prüfung der Templates mit jeder Erweiterung der Installation ausgeführt.
• To do: Ein Zeitraum für Meldungen mit echter Redaktionsarbeit, einschließlich Dialogen und Kontextmenüs.
• To do: Zuerst ein Siteaccess durchgesetzt; Erweiterungen und Editoren durch Nutzung geprüft.
• To do: Ausnahmen nur pro Siteaccess und Direktive hinzugefügt und aufgeschrieben.
• To do: Rückfall getestet: Mode=report-only, INI-Cache geleert, PHP-FPM neu geladen, Velocity neu gestartet.

Verwandte Seiten #

• Sicherheit für Hoster: Überblick
• Content Security Policy (Referenz der Funktion)
• Sicherheitshärtung: Cross-Site-Scripting und die Content Security Policy
• Sicherheitslog
• Härtung für Hoster
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.