Content Security Pol… Fallacy

Ich hatte vor ziemlich genau eineinhalb Jahren einen ausführlichen Artikel verfasst, der beschrieb, wie ich mein WordPress-Blog mit zeitgemäßen »Security Headern« und schließlich einer zumindest halbwegs vollständigen »Content Security Policy« (CSP) ausgestattet hatte.

Dabei trat zutage, dass WordPress code-seitig nicht auf dem, sagen wir einmal, neuesten Standard fußt, um eine CSP wirklich umfassend zu realisieren. Es werden eben in rauen Mengen Inline-Skripte und Inline-Styles eingesetzt – Zeuch, dass eigentlich in gutem Webdesign verboten ist.

Wie dem auch sei, die damals ziemlich mühsam handgebaute CSP, die ich formulieren konnte, funktionierte, war aber eben nicht wie gerne gewünscht vollständig.

Kürzlich aber…

…genauer gesagt exakt ab dem Moment, als mein Blögchen automatisch auf die Version 6.3 aktualisiert hatte, stürzte das Ganze komplett ab.

Der komplett neue Website Editor (Gutenberg) zeigte lediglich leere Editorfenster, ich konnte weder neue Artikel schreiben noch vorhandene Artikel editieren. Das Fenster war einfach leer, nur die jeweils angebotene Menüstruktur links und rechts war sichtbar, allerdings ohne Vorschaugrafiken dort, wo welche sein sollten.

Ich war als Autor und Editor völlig lahmgelegt.

Welches Problem hatte mich da ereilt? Ich hatte anfangs noch keinerlei Verdacht in Richtung CSP. Ich fand im deutschen Forum wie im amerikanischen Supportbereich nur zwei oder drei Fälle, die eine vergleichbare Symptomatik zeigten. Die angebotenen Tipps zum Troubleshooting gingen allesamt in die bekannten Richtungen:

• Cache(s) löschen (WordPress, Browser, Server)
• Browser wechseln
• Plugins deaktivieren
• Theme deaktivieren, Standardtheme aktivieren
• Debugmodus in wp-config.php einschalten und prüfen auf Fehlermeldungen
• .htaccess prüfen
• Aktuelle WP-Version neu hochladen, außer dem Verzeichnis wp-content

Das half alles nicht. Das Editorfenster blieb leer. Ich war ratlos… bis…

Das Entwicklertool des Firefox

Ich schaltete per F12 das Entwicklertool des Firefox ein, aktivierte das Debug-Register und rief anschließend den Adminbereich meines Blogs auf. Sofort fiel mir neben einigen eher unwesentlichen Meldungen eine rot getextete Fehlermeldung auf, die ganz eindeutig auf Probleme mit meiner Content Security Policy hinwies! Und zwar in Bezug auf script-src und style-src.

Ach gar? Wer hätte denn das gedacht?

Shitn! Nenenenene!

Also habe ich schnell einmal die Zeile meiner Content Security Policy in der .htaccess auskommentiert, und siehe da:

Ich habe wieder einen vollständig geladenen Editor, mit Fensterinhalt und Vorschaugrafiken!

Wie jetzt weiter?

Ich werde mir jetzt einmal verschiedene Plugins für WordPress anschauen, die antreten, CSPs zu erzeugen und einzubinden. Mindestens eines davon kann wohl sogar zwischen CSPs für den Adminbereich und für das Frontend differenzieren. Was mir ja gelegen käme, denn meinen Adminbereich habe ich ziemlich gut gegen Fremdzugriffe abgesichert. Da wären die faulen Inline-Skripte und -Styles nicht so dramatisch. Aber für das Frontend des Blogs wäre eine schöne und umfassende CSP erfreulich.

Ich schaue mal…

Update am 16.08.2023

Habe mich nach zwei eher unbefriedigenden Versuchen mit Plugins entschieden, doch wieder manuell vorzugehen. Eine manuelle Lösung erspart mir den zusätzlichen »Overhead«, den Plugins normalerweise mit sich bringen und ich lerne mehr dabei. DIY hat ja immer Lerneffekte zur Folge.

Wichtigster Lerneffekt war, dass ich zwei .htaccess benötige:

Die »normale« im Hauptverzeichnis mt einer so gut wie vollständigen Content-Security-Policy sowie eine weitere im Admin-Verzeichnis, die lediglich die CSP-Direktiven enthält, die dort notwendig sind bzw. sinnvoll erscheinen.

Einige Editier- und Hochladeeskapaden später standen die beiden Dateien schließlich – und ich habe jetzt einen funktionierenden Website Editor im Backend und eine taugliche CSP im Blog-Frontend.

Letzteres erreicht zwar im Mozilla Observatory lediglich eine B+, was aber an den angesprochenen Inline-Skript- und -Style-Unzulänglichkeiten in WordPress liegt.

Meine Content-Security-Policy sieht also jetzt so aus (das muss aber nicht der endgültige Stand sein, es gibt noch ein paar Direktiven…):

Header set Content-Security-Policy "default-src 'none'; img-src * data:; font-src 'self' data:; object-src 'none'; media-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; frame-ancestors 'none'; child-src 'self'; base-uri 'self'; form-action 'self'; connect-src 'self'; require-trusted-types-for 'script'"

Noch nicht ganz im Klaren bin ich mir über die Funktionsweise der möglichen Reportdirektiven, die mir bei Vorliegen von Fehlern einen Bericht anfertigen.

In der .htaccess des wp-admin-Verzeichnisses steht die kürzere Zeile:

Header set Content-Security-Policy "img-src * data:; font-src 'self' data: application/x-font-woff; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';"

Wie geschrieben, das scheint für’s Erste zu funktionieren. Aber es ist für mich work in progress, denn noch verstehe ich längst nicht alles, was da vor sich geht und warum.

Ich werde weiter forschen und ausprobieren…