Content Security Policy (CSP) für WordPress

Was ist wichtiger als die Sicherheit einer Website selbst? Eigentlich nicht viel. Leider ignorieren viele jedoch selbst einfache Sicherheitsmechanismen. Aus diesem Grunde möchte ich mich heute einmal der Content Security Policy (CSP) beschäftigen.

Die Content Security Policy ist eine weitere Sicherheitsebene, die vor Angriffen wie Cross Site Scripting (XSS) und data injection schützt. Sofern vom Browser unterstützt, kann man über einen einfachen HTTP-Header angeben, von welchen Ressourcen Inhalte geladen werden dürfen und von welchen nicht.

Ein funktionierender CSP-Header

Mein Header sieht aktuell folgendermaßen aus:

Content-Security-Policy "default-src 'self'; img-src 'self' https://secure.gravatar.com https://s.w.org https://wordpress.org https://ps.w.org data:; font-src 'self' fonts.gstatic.com data:; object-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; connect-src 'self' wss://kittpress.com; child-src 'self'";Code-Sprache: JavaScript (javascript)

Bilder werden von der eigenen Seite sowie von Gravatar und WordPress.org erlaubt. Schriften können außerdem von den Google Fonts geladen werden.

Je nach Theme sind bei den script-src-Angaben zwingend unsafe-inline und unsafe-eval notwendig, wenn JavaScript vorkommt, das inline, also einfach innerhalb von <script></script> ausgeführt wird. Im Theme Twenty Seventeen ist das beispielsweise der Fall.

Zu guter Letzt erlaube ich außerdem CSS von den Google Fonts sowie Verbindungen über WebSockets (WSS).

Eine restriktivere Variante, die beispielsweise bei Plugin-Details, welche zu WordPress leiten, keine Bilder laden, sieht folgendermaßen aus:

Content-Security-Policy "default-src 'self'; img-src 'self' https://secure.gravatar.com https://s.w.org data:; font-src 'self' fonts.gstatic.com data:; object-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; connect-src 'self' wss://kittpress.com; child-src 'self'";Code-Sprache: JavaScript (javascript)

Serverseitige Implementierung

Je nach verwendetem Webserver ist die Implementierung des CSP-Headers unterschiedlich, aber nicht wirklich unterschiedlich schwierig.

Apache

Die folgende Zeile entweder in den Bereich VirtualHost (empfohlen) oder in eine .htaccess schreiben:

Header set Content-Security-Policy "<Header>"Code-Sprache: Apache (apache)

nginx

Die folgende Zeile innerhalb des server {}-Blocks schreiben:

add_header Content-Security-Policy "<Header>";Code-Sprache: Nginx (nginx)

IIS

Die folgenden Zeilen in die web.config schreiben:

<system.webServer>
	<httpProtocol>
		<customHeaders>
			<add name="Content-Security-Policy" value="<Header>" />
		</customHeaders>
	</httpProtocol>
</system.webServer>
Code-Sprache: HTML, XML (xml)

Das <Header> muss jeweils durch den gewünschten CSP-Header ersetzt werden.

Versionen des CSP-Headers

Übrigens: Man trifft je nach Anleitung auf unterschiedliche Varianten des CSP-Headers. Das liegt daran, dass es mittlerweile drei Schreibweisen und vier Versionen gibt.

Die alten Schreibweisen sind:

• X-Webkit-CSP
• X-Content-Security-Policy

Die in meiner Anleitung beschriebene Variante ist die korrekte. Diese hat aktuell CSP Level 2, ist also bereits die zweite Ausbaustufe mit neuen Funktionen. Diese erlaubt das Definieren von erlaubten iframe-, object- und embed-Inhalten, die Art der eingebetteten Medien sowie Formular-Ziele.

Weiterführende (englische) Artikel dazu:
https://content-security-policy.com
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy