Vor kurzem haben wir das Online-Tool Securityheaders.io vorgestellt, mit dem sich die Sicherheit eines Webservers prüfen lässt. Leicht und einfach lassen sich mit diesem Tool die Schwächen des eigenen Servers herausfinden. Zudem bekommt man noch etliche, gute Fachartikel zum Thema geliefert. So gerüstet ist es recht einfach, die wichtigsten Schwächen auszumerzen und ein weiteres Stück Sicherheit zu implementieren. Damit auch du deinen Server sicherer machen kannst, erkläre ich im heutigen Beitrag die Umsetzung der wichtigsten HTTP Security-Header.
Vorab: Server scannen und Ausgangszustand feststellen
Nutze zum Scannen das Online-Tool securityheaders.io. Wahrscheinlich wirst du rot sehen, denn diese Farbe bekommst du präsentiert, wenn dein Server potenziell unsicher ist. Das ist nicht weiter schlimm, denn geschätzte 80 Prozent der Webserver sind nicht sicher.
Der Scan hat nun genau die Ergebnisse produziert, die am weitesten verbreitet sein dürften. Bei Websites mit HTTPS-Zertifikat kommen noch zwei weitere Punkte hinzu, wovon wir einen umsetzen werden.
Die bei diesem Scan ausgeworfenen Sicherheitslecks wollen wir in diesem Beitrag abdichten. Des Weiteren wollen wir analysieren, ob wirklich alle Punkte Sinn ergeben und umgesetzt werden sollten.
Diese HTTP Security-Header werden wir in diesem Beitrag umsetzen
- X-Frame-Options
- X-XSS-Protection
- X-Content-Type-Options
- Strict-Transport-Security (Nur HTTPS-Websites)
Was sind HTTP Security-Header?
Jedes Mal, wenn ein Browser eine Seite von einem Webserver anfordert, antwortet der Server mit der Auslieferung der Seite und sendet einen HTTP-Response-Header mit dem Inhalt. Diese Header können Metadaten wie Zeichensätze, Cache-Steuerung und Fehlercodes haben. Jedoch kann man auch sicherheitsrelevante Einstellungen mit den Response-Headern senden, welche die Browser anweisen, wie sie sich zu verhalten haben. Zum Beispiel würde ein Strict-Transport-Security-Header dem Browser die Anweisung erteilen, nur über HTTPS zu kommunizieren. Insgesamt existieren sechs verschiedene HTTP Security-Header. Wir empfehlen dir in diesem Artikel, welche Header du einsetzen solltest und von welchen du besser die Finger lässt.
Wichtig: Alle angesprochenen HTTP Security-Header kommen in die .htaccess Datei im Rootverzeichnis der Website.
Grundsätzlich gibt es drei Methoden, die Header zu setzen. Einmal über die Konfigurationsdatei des Apache-Webservers (httpd.conf), dann über PHP direkt innerhalb der zu schützenden Website und über die Server-Steuerungsdatei .htaccess. Ich werde alle drei Methoden behandeln. Wie immer, sorgt ein Klick auf die Grafik zum Öffnen des Gists bei GitHub, wo der Code dann heruntergeladen werden kann.
1 – Der X-Frame-Options Header
Der X-Frame-Options Header soll deine Website davor bewahren, in einem Frame ausgeführt zu werden. Professionelle Content-Diebe erstellen gerne Websites, die sich die Inhalte von anderen Websites holen. Diese Inhalte werden dann zumeist in einem Frame ausgeführt. Die fertige Website des Diebes sieht im Anschluss so aus, als ob die Inhalte von der eigenen Seite stammen. Um diese Praxis zu verhindern, setzt man einen X-Frame-Options Header. Dieser verhindert sehr effektiv die Ausführung in einem Frame.
Browser-Support: IE 8+, Chrome 4.1+, Firefox 3.6.9+, Opera 10.5+, Safari 4+
Nachteil dieses Headers: Die Website kann nicht mehr als Frame ausgeführt werden. Dies schliesst auch die »Responsive Layouts« der Webdeveloper Toolbars von Google Chrome und Firefox, sowie die Website »Am I Responsive« mit ein. Der Header sollte also erst gesetzt werden, wenn sich die Website nicht mehr im Entwicklungsmodus befindet.
2 – Der X-XSS-Protection Header
Der X-XSS-Protection Header wurde entwickelt, um die Cross-Site-Scripting (XSS) Schutzfilter in den modernen Browsern anzusprechen und zu aktivieren. Grundsätzlich sollte der Filter bereits aktiviert sein. Mit diesem Header wird die Nutzung jedoch erzwungen, daher sollte er genutzt werden.
Es existieren drei verschiedene Einstellmöglichkeiten: 0 um den Filter zu deaktivieren, 1 zum Aktivieren (der Browser versucht die schadhafte Seite zu bereinigen und anzuzeigen) und 1; mode=block aktiviert den Filter (die schadhafte Seite wird geblockt).
Browser-Support: Internet Explorer 8+, Chrome und Safari
3 – Der X-Content-Type-Options Header
Dieser Header schützt vor Angriffen mit falschen MIME-Typen. Wenn der MIME-Typ als nicht korrekt erkannt wird, lehnt der Browser das Laden von Styles und Scripten ab. Die Einstellung kann in diesem Header nur NOSNIFF heißen. Ist der Header gesetzt, werden nur Styles und Scripte mit korrektem MIME-Typ geladen. Folgende MIME-Typen werden als korrekt anerkannt:
Styles
- text/css
Scripte
- application/ecmascript
- application/javascript
- application/x-javascript
- text/ecmascript
- text/javascript
- text/jscript
- text/x-javascript
- text/vbs
- text/vbscript
Browser-Support: Internet Explorer und Google Chrome
4 – Der Strict-Transport-Security-Header (nur für HTTPS-Websites)
Der Strict-Transport-Security-Header weist den Browser an, nur über eine sichere HTTPS-Verbindung auf die Website zuzugreifen. Dies gewährleistet, dass keine unsichere Verbindung hergestellt werden kann, die potenziell angreifbar wäre. Ebenfalls verhindert dieser HTTP-Response-Header, dass User auf die Seite zugreifen können, falls das TLS-Zertifikat des Servers nicht vertrauenswürdig sein sollte.
Einstellungsmöglichkeiten:
- max-age – Die Anzahl der Sekunden, innerhalb die der Browser die sichere Verbindung erzwingen soll.
- includeSubDomains – Sagt dem Browser, dass die sichere Verbindung auch für Subdomains erzwungen werden soll.
Browser-Support: IE 11+, Chrome 4+, Firefox 4+, Opera 12+, Safari 7+.
Alle bisher behandelten HTTP Security-Header sollten verwendet werden. Wenn deine Website nur über HTTP ausgeliefert wird, dann benötigst du den letzten Header nicht. Die drei oberen hingegen empfehle ich dringend zu setzen.
Wenn alle angesprochenen Header korrekt gesetzt wurden, wird der nächste Scan mit securityheaders ein solides B ergeben. Das ist ein praxisgerechter Wert.
Der Content-Security-Policy-Header
Der Content-Security-Policy Header ist mit Vorsicht zu genießen, da er deine Website direkt beeinflussen und auch lahmlegen kann, wenn er nicht akribisch notiert wird. WordPress-User werden zudem ziemliche Probleme im Adminbereich der Website bekommen, da sich dieser Header auch dort auswirkt. Daher kann nicht allgemein empfohlen werden, ihn umzusetzen.
Die Content Security Policy ist als Schutz vor Cross-Site-Scripting (XSS) und anderen Code-Injection-Angriffen entwickelt worden. Die Idee hinter diesem Header ist, dass eine sogenannte Whitelist erstellt wird, in der alle erlaubten Ressourcen aufgeführt sind. Content-Quellen oder Arten, die nicht explizit erlaubt sind, werden nicht vom Browser geladen und verarbeitet. Ist die CSP nicht aktiv, lädt der Browser alle Daten und gibt sie aus, ohne Rücksicht darauf, ob die Quelle schädlich sein könnte. Mit aktiver CSP werden nur die erlaubten Dateien geladen, alle anderen hingegen nicht.
Alle modernen Browser unterstützen die Content-Security-Policy.
Die Möglichkeiten dieses Response-Headers sind sehr umfangreich; zu umfangreich für diesen Artikel. Wer sich jedoch näher mit dem Content-Security-Policy-Header beschäftigen möchte, dem empfehle ich folgende Artikelserie und die CSP-Referenz:
- Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 1
- Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 2
- Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 3
- Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 4
- Content Security Policy Reference (mit Beispielen)
Content-Security-Policy-Generator
Um die zum Teil sehr langen Code-Snippets für die korrekte Funktion einer Website mit CSP komfortabel erstellen zu können, gibt es einen guten Online-Generator. Dieser führt dich über Tabs durch die Einstellungsmöglichkeiten und lässt dich die Policy immer wieder anpassen, bis sie letztendlich funktioniert.
Erwähnt werden sollte der Vollständigkeit halber noch, dass es noch den Public-Key-Pins-Header gibt. Dieser kann ebenfalls unbedenklich gesetzt werden, erscheint mir jedoch nur für Server-Profis machbar.
Fazit
Die wichtigsten HTTP Security-Header haben wir angesprochen und können sie leicht umsetzen, indem wir die betreffenden Code-Snippets in die Server-Steuerungsdatei .htaccess kopieren. Ein B im securityheaders.io Scan kann auch ein Nicht-Fachmann erreichen und damit viel für die Sicherheit seiner Website tun. Ein A oder A+ hingegen ist nur für die wirklichen Fachleute zu erreichen. Wenn man WordPress einsetzt, ist es äußerst mühsam, die CSP umzusetzen, denn der Adminbereich muss ebenfalls mit einer eigenen CSP versehen werden, wenn nicht alles freigegeben wird. Im letzteren Falle kann man sich das Setzen der CSP allerdings auch gleich sparen.
(dpe)
