Die Mozilla-Foundation bietet über die Adresse observatory.mozilla.org einen Dienst an, der die Sicherheit einer Webseite bewertet. Anhand diesem Artikel beschreibe ich, wie ich mein Sicherheitslevel von F auf A+ verbessern konnte.
Mozilla bewertet eine Seite nach unterschiedlichen Kriterien, die ich hier kurz vorstelle, erläutere und die nötigen Änderungen beschreibe. Da diese Änderungen auch Konfigurationen auf dem Webserver erfordern und einige Webhoster diese Konfiguration über eine Konfigurationsoberfläche anbieten, werde ich hier nur auf das Angebebot des Webhosters all-inkl.com eingehen. Bitte beachte, dass dies erst ab dem Paket PrivatPlus möglich ist.
SSL-Zertifikat einrichten:
Die Sicherheit einer Webseite über ein SSL-Zertifikat wird deutlich erhöht, daher muss dieses unbedingt eingerichtet werden. all-inkl.com bietet eine Einbindung von kostenlosen let’s encrypt-Zertifikaten über das Kundenadministrationssystem für einzelnen (Sub-)Domains an.
- im linken Menu auf Domain bzw. Subdomain klicken
- in der Zeile der zu bearbeitenden (Sub-)Domain auf das Icon „bearbeiten“ klicken
- im Bereich SSL-Schutz auf das Icon „bearbeiten“ klicken
- „Let’s Encrypt“ auswählen
- das Checkfeld „Haftungsausschluß akzeptieren“ setzen und auf „jetzt ein Let’s Encrypt Zetrifikat beziehen und einbinden“ klicken
- nach einer kurzen Wartezeit öffnet sich das Fenster „SSL Schutz“ direkt im Bereich „SSL Zertifikat“. Die Felder wie folgt anpassen
- SSL-Aktivieren: Ja (gesetzt nach der Einrichtung als Vorbelegung)
- SSL erzwingen: Ja (verhindert den Aufruf der http-Seite)
- HSTS aktivieren: Ja
- max-age: 15.768.000 Sekunden (entspricht einem Zeitraum von 6 Monaten)
- „Änderungen speichern“ anklicken
Für die Einrichtung des SSL-Zertifikates ist es das schon gewesen.
Anmerkung: Ob der von der Mozilla-Foundation vorgeschlagene Wert der maximalen Gültigkeitsdauer der let’s Encrypt-Zertifikate widerspricht, muss ich beobachten. Im schlechtesten Fall würde die Seite nicht aufgerufen werden können. Dann sollte der Wert halbiert werden, hätte dann aber einen negativen Einfluss auf das Testergebnis.
Auswirkungen auf das Testergebnis:
Score: F auf D+
Behandelte Kategorie: HTTP Strict Transport Security
X-XXS-Protection verbessern
Hierzu ist es nötig, in der WordPress-Installation ein Plugin zu installieren. Ich habe mich hier für die Ninja Firewall (WP-Edition) entschieden. Diese Entscheidung erwies sich als Glücksfall, da es sich hier um ein mächtiges Werkzeug handelt.
Die Installation erfolgt im WordPress-Menu unter Plugins -> Plugin installieren. Für die Einrichtung muss festgelegt werden, welche PHP-Version der Webhoster anbietet und wie dieses eingebunden ist. In dem Fall konnte ich einfach PHP7 auswählen, „Next“ anklicken und das Plugin stand zur Verfügung.
Auswirkungen auf das Testergebnis:
Score: D+ auf C
Behandelte Kategorien: Cookies, Cross-origin Resource Sharing, Redirection, X-Content-Type-Options, X-XSS-Protection
Einbinden der Webseite als Frame verhindern
Es wird bewertet, ob Deine Webseite als Frame in eine andere Seite eingebunden werden kann. Wenn Deine Seite beispielsweise www.deine-Seite.de heisst, kann diese durch eine Frame-Seite eingebunden werden. Im besten Fall erscheinen dann über deiner „entführten“ Seite, die dann über www.deine-entfuehrte-Seite.de erreichbar ist, Werbebanner. In anderen Fällen werden dann Schadprogramme oder illegale Inhalte „angeboten“. Auf den ersten Blick sieht es dann so aus, dass Du der Anbieter der Schadprogramme dann bist.
Diese Einstellungen kannst Du auch in der Ninja-Firewall vornehmen. Dazu klickt Du im WordPress-Menu auf „NinjaFirewall -> Firewall Policies“ und scrollst bis zum Punkt „Set X-Frame-Options to protect against clickjacking attempts“ herunter. Diesen Wert setzt Du auf „Sameorigin“ oder „Deny“.
Auswirkungen auf das Testergebnis:
Score C auf B
Behandelte Kategorie: X-Frame-Options
Content-Security-Policy einrichten
Weiterhin kann in der Ninja-Firewall die Einstellung vorgenommen werden, welche Inhalte von externen Webseiten und Diensten eingebunden werden.
Die Konfiguration, die ich aktuell für das Frontend gewählt habe ist, sehr strikt:
script-src 'self'; style-src 'self' 'unsafe-inline' connect-src 'self'; media-src 'self'; child-src 'self'; object-src 'self'; form-action 'self'; img-src 'self' data:;
Ich erlaube hiermit, dass sämtlich eingebundene Daten auf der eigenen Domäne gespeichert sein müssen. Auch die standardmäßigen WordPressquellen wie gravator.com, wp.com, etc. werden hier ausgesperrt.
Etwas großzüger ist es im Backend. Dort habe ich einige Standardwerte (zunächst) gelassen. Ein Zugriff auf *.wp.com und *.w.org erlaube ich weiterhin, da Updateprüfungen, etc. noch durchgeführt werden sollen. Die anderen Quellen wie google.com, youtube.com oder videopress.com habe ich entfernt, da sie im Frontend nicht genutzt werden.
script-src 'self' 'unsafe-inline' 'unsafe-eval' *.wp.com; style-src 'self' 'unsafe-inline' *.jquery.com; connect-src 'self'; media-src 'self' *.w.org; child-src 'self' ; object-src 'self'; form-action 'self'; img-src 'self'*.wp.com *.w.org data:;
Auswirkungen auf das Testergebnis:
Score: B auf A+
Behandelte Kategorie: Content Security Policy
Optionale Einstellungen
Aktuell sind noch die optionalen Punkte „HTTP Public Key Pinning“ und „Subresource Integrity“ offen. „HTTP Public Key Pinning“ verhindert sogenannte „Man-in-the-middle“-Angriff mit gefälschten Zertifikaten anerkannter Zertifizierungsstellen, „Subresource Integrity“ sichert die Integrität von eingesetzten Skripten.