Dass WordPress zu den größten Content Management Systemen gehört, dürfte wohl unbestritten sein. Gerade ein hoher Marktanteil bringt natürlich immer das Risiko einer großen Angriffsfläche mit sich. Ein großflächig gestreuter Angriff auf kleine unbedeutende Nischensysteme ist in vielen Fällen kein lohnendes Ziel. Daher ist es natürlich auch wichtig, die eigene WordPress Installation soweit wie möglich abzusichern. Auf allgemeine Themen wie “Setze nur die Plugins ein, die auch wirklich nötig sind” oder “Gebe nur den Leuten Zugänge, denen Du auch vertrauen kannst” möchte ich in dem Artikel nicht eingehen. Hierzu gibt es bereits eine sehr große Anzahl an Beiträgen, die eine Grundabsicherung sicherstellen. Vielmehr geht es mir um ein paar Detailkonfigurationen, die im heutigen Web Betrieb aber nicht mehr fehlen sollten, um Angriffe zu minimieren.
Diese Konfigurationen werden in Form von HTTP Response Headern ausgeliefert. Wenn ein Client einen Webserver anfragt, schickt dieser als Antwort einen Response Header mit. In diesem können ganz allgemeine Informationen wie zum Beispiel das aktuelle Datum, der verwendete Zeichensatz oder die eingesetzte PHP Version stehen. Über den HTTP Security Header können jedoch auch Informationen vom Webserver mitgesendet werden, wie sich ein Browser verhalten soll, um damit die Sicherheit zu erhöhen. Folgende Security Header sind hierbei relevant.
Strict-Transport-Security-Header (HSTS):
Diese Einstellung ist ausschließlich für Seiten, die über HTTPS ausgeliefert werden relevant und sorgt dafür, dass die Seite auch tatsächlich nur über HTTPS ausgeliefert werden kann.
X-Frame-Options:
Damit wird sichergestellt, dass die eigene Seite nicht in einem anderen (fremden) Frame ausgeführt werden kann.
X-Content-Type-Options:
Hiermit werden Angriffe mit fremden MIME Types verhindert. Werden Inhalte mit unbekannten/undefinierten MIME Types geladen, verhindert der Browser die Ausführung.
X-XSS-Protection:
Hiermit werden Cross Site Scripting (XSS) Filter im Browser erzwungen. Schadhafte Seiten können somit nicht mehr geladen werden.
Content Security Policy:
Dies ist die vermutlich aufwendigste Konfiguration und Bedarf für unterschiedliche Anwendungsfälle jeweils andere Konfigurationen. Hierüber wird definiert, welche Inhalte von welchen Quellen geladen werden dürfen. Eine falsch gesetzte CSP kann dazu führen, dass die eigene Seite nicht mehr ordnungsgemäß ausgeliefert wird.
Die genannten HTTP Response Header können über unterschiedliche Arten gesetzt werden. Im Optimalfall werden diese direkt in der Webserverkonfiguration mit angegeben. Dies setzt jedoch voraus, dass ein Zugriff auf die Konfigurationsdateien möglich ist. In einem Shared Hosting ist dies jedoch nicht möglich. Hier können die Header dann z.B. in einer “.htaccess” Datei für den Apache Webserver oder direkt in der “functions.php” von WordPress gesetzt werden. Die beiden zuletzt genannten Beispiele werden im Folgenden gezeigt. Die Content Security Policy wird jeweils eigenständig mit angegeben.
.htaccess
Header set Strict-Transport-Security “max-age=15768000"
Header set X-Frame-Options "sameorigin"
Header set X-Content-Type-Options nosniff
Header set X-XSS-Protection "1; mode=block"
CSP:
Header set Content-Security-Policy "default-src 'self' 'unsafe-inline' 'unsafe-eval' https: data: *.doenselmann.com;”
Dieses Beispiel wird auf meinem eigenen Blog eingesetzt und sollte erstmal getestet werden, ob es auf anderen Blogs auch eingesetzt werden kann.
functions.php
Alternativ können die Security Header auch innerhalb von WordPress über die functions.php geladen werden. Dazu werden folgende Zeilen am Ende mit eingefügt.
/* Add security header */
header('Strict-Transport-Security:max-age=15768000');
header('X-Frame-Options: SAMEORIGIN’);
header('X-Content-Type-Options: nosniff');
header('X-XSS-Protection: 1; mode=block');
header("Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' https: data: *.doenselmann.com”);
Die neuen Konfigurationen können über die Mozilla Observatory Seite getestet werden. Hier werden ggf. auch noch weitere Optimierungsmöglichkeiten angezeigt. Allerdings ist es wichtig alle Optionen ordentlich zu testen, um nicht einzelne Funktionen zu blockieren, die vielleicht nur selten benötigt werden.