Andreas Hecht 18. April 2016

HTTP Security-Header: So machst du deine Website sicher

HTTP Security-Header: So machst du deine Website sicher

ist WordPress-Entwickler und bietet dir WordPress-Sicherheit für deine Website. Zudem entwickelt er...

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.

HTTP Security-Header: So machst du deine Website sicher

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.

Scanresultat mit securityheaders.io

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+

x-frame-options

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

x-xss-protection

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

x-content-type-options

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+.

strict-transport-security

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.

content-security-header

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:

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.

content-security-policy-generator

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)

Andreas Hecht

ist WordPress-Entwickler und bietet dir WordPress-Sicherheit für deine Website. Zudem entwickelt er WooCommerce Shops mit Ladezeiten von unter einer Sekunde. Er schreibt seit 2012 für Dr. Web. Auf seinem Blog veröffentlicht er unter anderem nützliche WordPress-Snippets.

5 Kommentare

  1. Ich habe auf meiner Webseite eine CSS-Datei eingebunden und darüber hinaus auch Inline-CSS.
    Genauso ist es mit Javaskript.
    Mit den Generator bekomme ich folgenden Code:
    Header set Content-Security-Policy: „default-src ’self‘; script-src ‚unsafe-inline‘ ‚unsafe-eval‘; style-src ‚unsafe-inline'“
    Header set X-Content-Security-Policy: „default-src ’self‘; script-src ‚unsafe-inline‘ ‚unsafe-eval‘; style-src ‚unsafe-inline'“
    Header set X-WebKit-CSP: „default-src ’self‘; script-src ‚unsafe-inline‘ ‚unsafe-eval‘; style-src ‚unsafe-inline'“

    Leider funktioniert dann meine Webseite nicht mehr richtig.
    Es wird wohl noch das inline-CSS berücksichtigt. Und das Java Skript funktioniert gar nicht mehr.
    Wäre super, wenn mir jemand mitteilen könnte, wie mein Code lauten muss. Vielen Dank schon mal!

    1. Das kann Dir niemand einfach mitteilen. Das ist so komplex, da helfen nur eingehende Tests. Es sind ausreichend gute Artikel zu diesem Thema im Beitrag verlinkt.

    2. Die beiden X-H4eader kannst du weglassen, die werden mittlerweile nicht mehr benötigt.
      Achte bei der CSP unbedingt auf die Syntax und füge bei script-src und style-src noch self hinzu.
      Kleines Beispiel: Header set Content-Security-Policy: „default-src ’self‘; script-src ’self‘ ‚unsafe-inline‘ ‚unsafe-eval‘; style-src ’self‘ ‚unsafe-inline'“

      1. Vielen Dank für den Tipp!
        Werde ich sobald wie möglich ausprobieren.

        Euch beiden noch einen schönen Tag

      2. Leider funktioniert das auch nicht. Ich bekomme folgendes angezeigt:
        Internal Server Error
        The server encountered an internal error or misconfiguration and was unable to complete your request.
        Please contact the server administrator at [no address given] to inform them of the time this error occurred, and the actions you performed just before this error.
        More information about this error may be available in the server error log.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.