Spaces. Smartes Cloud Hosting für anspruchsvolle Webprojekte. Loslegen und Spaces testen. Von Mittwald.
Andreas Hecht 18. April 2016

HTTP Security-Header: So machst du deine Website sicher

HTTP Security-Header: So machst du deine Website sicher

Vor kur­zem haben wir das Online-Tool Securityheaders.io vor­ge­stellt, mit dem sich die Sicherheit eines Webservers prü­fen lässt. Leicht und ein­fach las­sen sich mit die­sem Tool die Schwächen des eige­nen Servers her­aus­fin­den. Zudem bekommt man noch etli­che, gute Fachartikel zum Thema gelie­fert. So gerüs­tet ist es recht ein­fach, die wich­tigs­ten Schwächen aus­zu­mer­zen und ein wei­te­res Stück Sicherheit zu imple­men­tie­ren. Damit auch du dei­nen Server siche­rer machen kannst, erklä­re ich im heu­ti­gen Beitrag die Umsetzung der wich­tigs­ten 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 die­se Farbe bekommst du prä­sen­tiert, wenn dein Server poten­zi­ell unsi­cher ist. Das ist nicht wei­ter schlimm, denn geschätz­te 80 Prozent der Webserver sind nicht sicher.

Scanresultat mit securityheaders.io

Der Scan hat nun genau die Ergebnisse pro­du­ziert, die am wei­tes­ten ver­brei­tet sein dürf­ten. Bei Websites mit HTTPS-Zertifikat kom­men noch zwei wei­te­re Punkte hin­zu, wovon wir einen umset­zen wer­den.

Die bei die­sem Scan aus­ge­wor­fe­nen Sicherheitslecks wol­len wir in die­sem Beitrag abdich­ten. Des Weiteren wol­len wir ana­ly­sie­ren, ob wirk­lich alle Punkte Sinn erge­ben und umge­setzt wer­den soll­ten.

Diese HTTP Security-Header wer­den wir in die­sem Beitrag umset­zen

  • 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 anfor­dert, ant­wor­tet der Server mit der Auslieferung der Seite und sen­det einen HTTP-Response-Header mit dem Inhalt. Diese Header kön­nen Metadaten wie Zeichensätze, Cache-Steuerung und Fehlercodes haben. Jedoch kann man auch sicher­heits­re­le­van­te Einstellungen mit den Response-Headern sen­den, wel­che die Browser anwei­sen, wie sie sich zu ver­hal­ten haben. Zum Beispiel wür­de ein Strict-Transport-Security-Header dem Browser die Anweisung ertei­len, nur über HTTPS zu kom­mu­ni­zie­ren. Insgesamt exis­tie­ren sechs ver­schie­de­ne HTTP Security-Header. Wir emp­feh­len dir in die­sem Artikel, wel­che Header du ein­set­zen soll­test und von wel­chen du bes­ser die Finger lässt.

Wichtig: Alle ange­spro­che­nen HTTP Security-Header kom­men in die .htac­cess Datei im Rootverzeichnis der Website.

Grundsätzlich gibt es drei Methoden, die Header zu set­zen. Einmal über die Konfigurationsdatei des Apache-Webservers (httpd.conf), dann über PHP direkt inner­halb der zu schüt­zen­den Website und über die Server-Steuerungsdatei .htac­cess. Ich wer­de alle drei Methoden behan­deln. Wie immer, sorgt ein Klick auf die Grafik zum Öffnen des Gists bei GitHub, wo der Code dann her­un­ter­ge­la­den wer­den kann.

1 – Der X-Frame-Options Header

Der X-Frame-Options Header soll dei­ne Website davor bewah­ren, in einem Frame aus­ge­führt zu wer­den. Professionelle Content-Diebe erstel­len ger­ne Websites, die sich die Inhalte von ande­ren Websites holen. Diese Inhalte wer­den dann zumeist in einem Frame aus­ge­führt. Die fer­ti­ge Website des Diebes sieht im Anschluss so aus, als ob die Inhalte von der eige­nen Seite stam­men. Um die­se Praxis zu ver­hin­dern, setzt man einen X-Frame-Options Header. Dieser ver­hin­dert sehr effek­tiv 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 die­ses Headers: Die Website kann nicht mehr als Frame aus­ge­führt wer­den. Dies schliesst auch die »Responsive Layouts« der Webdeveloper Toolbars von Google Chrome und Firefox, sowie die Website »Am I Responsive« mit ein. Der Header soll­te also erst gesetzt wer­den, wenn sich die Website nicht mehr im Entwicklungsmodus befin­det.

2 – Der X-XSS-Protection Header

Der X-XSS-Protection Header wur­de ent­wi­ckelt, um die Cross-Site-Scripting (XSS) Schutzfilter in den moder­nen Browsern anzu­spre­chen und zu akti­vie­ren. Grundsätzlich soll­te der Filter bereits akti­viert sein. Mit die­sem Header wird die Nutzung jedoch erzwun­gen, daher soll­te er genutzt wer­den.

Es exis­tie­ren drei ver­schie­de­ne Einstellmöglichkeiten: 0 um den Filter zu deak­ti­vie­ren, 1 zum Aktivieren (der Browser ver­sucht die schad­haf­te Seite zu berei­ni­gen und anzu­zei­gen) und 1; mode=block akti­viert den Filter (die schad­haf­te 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 fal­schen MIME-Typen. Wenn der MIME-Typ als nicht kor­rekt erkannt wird, lehnt der Browser das Laden von Styles und Scripten ab. Die Einstellung kann in die­sem Header nur NOSNIFF hei­ßen. Ist der Header gesetzt, wer­den nur Styles und Scripte mit kor­rek­tem MIME-Typ gela­den. Folgende MIME-Typen wer­den als kor­rekt aner­kannt:

Styles

  • text/css

Scripte

  • application/ecmascript
  • application/javascript
  • app­li­ca­ti­on/x-java­script
  • text/ecmascript
  • text/javascript
  • text/jscript
  • tex­t/x-java­script
  • 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 siche­re HTTPS-Verbindung auf die Website zuzu­grei­fen. Dies gewähr­leis­tet, dass kei­ne unsi­che­re Verbindung her­ge­stellt wer­den kann, die poten­zi­ell angreif­bar wäre. Ebenfalls ver­hin­dert die­ser HTTP-Response-Header, dass User auf die Seite zugrei­fen kön­nen, falls das TLS-Zertifikat des Servers nicht ver­trau­ens­wür­dig sein soll­te.

Einstellungsmöglichkeiten:

  • max-age – Die Anzahl der Sekunden, inner­halb die der Browser die siche­re Verbindung erzwin­gen soll.
  • includeSubDomains – Sagt dem Browser, dass die siche­re Verbindung auch für Subdomains erzwun­gen wer­den soll.

Browser-Support: IE 11+, Chrome 4+, Firefox 4+, Opera 12+, Safari 7+.

strict-transport-security

Alle bis­her behan­del­ten HTTP Security-Header soll­ten ver­wen­det wer­den. Wenn dei­ne Website nur über HTTP aus­ge­lie­fert wird, dann benö­tigst du den letz­ten Header nicht. Die drei obe­ren hin­ge­gen emp­feh­le ich drin­gend zu set­zen.

Wenn alle ange­spro­che­nen Header kor­rekt gesetzt wur­den, wird der nächs­te Scan mit secu­ri­tyhea­ders ein soli­des B erge­ben. Das ist ein pra­xis­ge­rech­ter Wert.

Der Content-Security-Policy-Header

Der Content-Security-Policy Header ist mit Vorsicht zu genie­ßen, da er dei­ne Website direkt beein­flus­sen und auch lahm­le­gen kann, wenn er nicht akri­bisch notiert wird. WordPress-User wer­den zudem ziem­li­che Probleme im Adminbereich der Website bekom­men, da sich die­ser Header auch dort aus­wirkt. Daher kann nicht all­ge­mein emp­foh­len wer­den, ihn umzu­set­zen.

Die Content Security Policy ist als Schutz vor Cross-Site-Scripting (XSS) und ande­ren Code-Injection-Angriffen ent­wi­ckelt wor­den. Die Idee hin­ter die­sem Header ist, dass eine soge­nann­te Whitelist erstellt wird, in der alle erlaub­ten Ressourcen auf­ge­führt sind. Content-Quellen oder Arten, die nicht expli­zit erlaubt sind, wer­den nicht vom Browser gela­den und ver­ar­bei­tet. Ist die CSP nicht aktiv, lädt der Browser alle Daten und gibt sie aus, ohne Rücksicht dar­auf, ob die Quelle schäd­lich sein könn­te. Mit akti­ver CSP wer­den nur die erlaub­ten Dateien gela­den, alle ande­ren hin­ge­gen nicht.

Alle moder­nen Browser unter­stüt­zen die Content-Security-Policy.

content-security-header

Die Möglichkeiten die­ses Response-Headers sind sehr umfang­reich; zu umfang­reich für die­sen Artikel. Wer sich jedoch näher mit dem Content-Security-Policy-Header beschäf­ti­gen möch­te, dem emp­feh­le ich fol­gen­de Artikelserie und die CSP-Referenz:

Content-Security-Policy-Generator

Um die zum Teil sehr lan­gen Code-Snippets für die kor­rek­te Funktion einer Website mit CSP kom­for­ta­bel erstel­len zu kön­nen, gibt es einen guten Online-Generator. Dieser führt dich über Tabs durch die Einstellungsmöglichkeiten und lässt dich die Policy immer wie­der anpas­sen, bis sie letzt­end­lich funk­tio­niert.

content-security-policy-generator

Erwähnt wer­den soll­te der Vollständigkeit hal­ber noch, dass es noch den Public-Key-Pins-Header gibt. Dieser kann eben­falls unbe­denk­lich gesetzt wer­den, erscheint mir jedoch nur für Server-Profis mach­bar.

Fazit

Die wich­tigs­ten HTTP Security-Header haben wir ange­spro­chen und kön­nen sie leicht umset­zen, indem wir die betref­fen­den Code-Snippets in die Server-Steuerungsdatei .htac­cess kopie­ren. Ein B im securityheaders.io Scan kann auch ein Nicht-Fachmann errei­chen und damit viel für die Sicherheit sei­ner Website tun. Ein A oder A+ hin­ge­gen ist nur für die wirk­li­chen Fachleute zu errei­chen. Wenn man WordPress ein­setzt, ist es äußerst müh­sam, die CSP umzu­set­zen, denn der Adminbereich muss eben­falls mit einer eige­nen CSP ver­se­hen wer­den, wenn nicht alles frei­ge­ge­ben wird. Im letz­te­ren Falle kann man sich das Setzen der CSP aller­dings auch gleich spa­ren.

(dpe)

Andreas Hecht

Andreas Hecht

entwickelt WordPress-Websites und bietet dir einen Website Sicherheit Service und einen Performance Service für deine Website. Außerdem ist er Spezialist für Onpage SEO und bringt Deine Website in die Top-Suchergebnisse von Google. Auf seinem Blog schreibt er über WordPress, SEO und Content SEO.

5 Kommentare

  1. Ich habe auf mei­ner Webseite eine CSS-Datei ein­ge­bun­den und dar­über hin­aus auch Inline-CSS.
    Genauso ist es mit Javaskript.
    Mit den Generator bekom­me ich fol­gen­den Code:
    Header set Content-Security-Policy: “default-src ’self’; script-src ‘unsafe-inli­ne’ ‘unsafe-eval’; style-src ‘unsafe-inli­ne’ ”
    Header set X-Content-Security-Policy: “default-src ’self’; script-src ‘unsafe-inli­ne’ ‘unsafe-eval’; style-src ‘unsafe-inli­ne’ ”
    Header set X-WebKit-CSP: “default-src ’self’; script-src ‘unsafe-inli­ne’ ‘unsafe-eval’; style-src ‘unsafe-inli­ne’ ”

    Leider funk­tio­niert dann mei­ne Webseite nicht mehr rich­tig.
    Es wird wohl noch das inli­ne-CSS berück­sich­tigt. Und das Java Skript funk­tio­niert gar nicht mehr.
    Wäre super, wenn mir jemand mit­tei­len könn­te, wie mein Code lau­ten muss. Vielen Dank schon mal!

    • Das kann Dir nie­mand ein­fach mit­tei­len. Das ist so kom­plex, da hel­fen nur ein­ge­hen­de Tests. Es sind aus­rei­chend gute Artikel zu die­sem Thema im Beitrag ver­linkt.

    • Die bei­den X-H4eader kannst du weg­las­sen, die wer­den mitt­ler­wei­le nicht mehr benö­tigt.
      Achte bei der CSP unbe­dingt auf die Syntax und füge bei script-src und style-src noch self hin­zu.
      Kleines Beispiel: Header set Content-Security-Policy: “default-src ’self’; script-src ’self’ ‘unsafe-inli­ne’ ‘unsafe-eval’; style-src ’self’ ‘unsafe-inli­ne’ ”

      • Vielen Dank für den Tipp!
        Werde ich sobald wie mög­lich aus­pro­bie­ren.

        Euch bei­den noch einen schö­nen Tag

      • Leider funk­tio­niert das auch nicht. Ich bekom­me fol­gen­des ange­zeigt:
        Internal Server Error
        The ser­ver encoun­te­red an inter­nal error or mis­con­fi­gu­ra­ti­on and was unab­le to com­ple­te your request.
        Please con­tact the ser­ver admi­nis­tra­tor at [no address given] to inform them of the time this error occur­red, and the actions you per­for­med just befo­re this error.
        More infor­ma­ti­on about this error may be avail­ab­le in the ser­ver error log.

Schreibe einen Kommentar

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