Die Sicherheit ist ein bei Website-Betreibern gern vernachlässigtes Thema. Um alles wird sich gekümmert, neue Funktionen implementiert und für ein schickes Design gesorgt. Doch eines Tages ist es vielleicht zu spät und deine Website ist gehackt worden.
Um dieses wirklich unschöne Gefühl niemals Realität werden zu lassen, bedarf es einer Strategie und etwas Einsatz. Wenn du zudem noch einen eigenen Server hast, solltest du dich erst recht um seine Sicherheit kümmern. Um dich dabei zu unterstützen, stelle ich dir heute das Online-Tool securityheaders.io vor, das dir die Schwächen deines Servers zeigt und dir Ratschläge gibt, wie du sie abstellst.
Analyse der HTTP-Header
Securityheaders.io heißt der Online-Dienst, der anhand der gesendeten HTTP-Response-Header feststellen kann, wie sicher dein Server ist. Natürlich existieren mittlerweile viele Dienste, welche die HTTP-Response-Header analysieren können. Doch das Besondere an securityheaders ist das Rating-System, in dem die Ergebnisse einsortiert werden. Dieses Rating-System sortiert die Ergebnisse in einen Bereich von A bis F ein. Das A steht hierbei für einen hervorragend abgesicherten Server, das F hingegen steht für einen sehr schlechten Sicherheitszustand.
Der Online-Dienst mit seinem Betreiber Scott Helme möchte zu mehr Sicherheit im Internet beitragen. Denn es werden nicht nur die Response-Header analysiert, sondern auch handfeste Tipps gegeben, wie die Sicherheitsprobleme zu beheben sind. Denn das Senden der richtigen HTTP-Response-Header verspricht ein hohes Maß an zusätzlicher Sicherheit, und sollte daher umgesetzt werden. Der zeitliche Aufwand hierfür ist vergleichsweise gering, der Zuwachs an potenzieller Sicherheit jedoch groß.
Sehr viele Server sind potenziell unsicher
Wer mit dem Online-Tool etwas herum experimentiert, wird schnell feststellen, dass der überwiegende Teil der geprüften Server potenziell unsicher ist. Egal, welche Domain ich eingab und testete, jedes Mal bekam ich ein F zu sehen. Auch bei meinen eigenen Websites. Bisher ging ich davon aus, dass ein Managed-Server oder ein Managed-WordPress-Hosting sicher sei und man sich um diesen Bereich nicht kümmern müsse. Nun weiß ich, dass Managed nicht gleich sicher bedeutet. Auch Shared-Hosting-Systeme sind nicht sicherer, denn auch dort bekam ich ein F zu sehen.
Eine potenziell schlechte Sicherheit wird nicht nur mit einem F im Rating-System versehen, sondern auch noch farblich rot unterlegt, um die Unsicherheit zu visualisieren. Sehr sichere Server hingegen bekommen demzufolge eine grüne Farbe, wie ein Scan der securityheaders-Website zeigte.
Gute Erklärungen der Ergebnisse und Tipps zum Umsetzen
Jedes (schlechte) Scan-Resultat zeigt genau auf, welche HTTP-Response-Header fehlen. Eine kurze Erklärung erläutert dir, warum diese Header wichtig sind und welche Auswirkungen die fehlenden Header haben können.
Die einzelnen Ergebnisse sind mit Links versehen, hinter denen sich gute und fundierte Fachartikel zu den einzelnen Bereichen verbergen. Auf diese Weise lernst du viel über die jeweiligen Header. Und du weißt im Anschluss genau, was du umsetzen solltest und vor allem auch warum. Hinter dem fehlenden Header »Content-Security-Police« verbirgt sich der Artikel “Content Security Policy – An Introduction“. Zudem existieren gute Erklärungen in deutscher Sprache zu diesem Bereich.
Wie HTTP-Response-Header Server sicherer machen
Der »Content-Security-Police-Header« ist ein guter Schutz gegen das Problem des Cross-Site-Scripting. Sogenannte XSS- oder Cross-Site-Scripting-Angriffe gehören zu den größten Sicherheitsproblemen bei Webanwendungen. Hierbei geht es um einen Schutz gegen von außen in die Website eingebrachten Code. Mittels des »Content-Security-Police«-Headers kann genau festgelegt werden, auf welche Scripte von außen zugegriffen werden kann. Die Grundeinstellung soll nur die Ausführung von Scripten erlauben, die auf dem eigenen Server liegen. Zusätzlich definiert man alle externen Scripte, auf die zugegriffen werden muss. Zum Beispiel Google Adsense und Google Analytics Code. Jeder andere – externe – Code wird ignoriert und demzufolge nicht ausgeführt.
Dies gilt auch für Bilder, Frames und Videos. Also für alle Dinge, die nicht auf dem eigenen Server liegen. Diese Ausnahmen festzulegen ist eine mühsame Angelegenheit. Jedoch wird man mit einem erheblichen Zuwachs an Sicherheit belohnt.
Weitere Response-Header
Vier fehlende HTTP-Response-Header ergab der Scan meiner persönlichen Website. Unter anderem der bereits angesprochene »Content-Security-Header«, der »X-Frame-Options-Header«, der »X-XSS-Protection-Header« und der »X-Content-Type-Options-Header«.
Der »X-Frame-Options-Header« schützt deine Website davor, in einem Frame ausgeführt zu werden. Es existieren durchaus Menschen, die sich im Web mit fremden Federn schmücken wollen. Diese Menschen entwickeln einen Rahmen, in dem deine Website dann mittels eines iFrames integriert wird. So kommt man an gute Inhalte, ohne sie selbst verfassen zu müssen.
Der »X-XSS-Protection-Header« konfiguriert den internen “Cross-Site-Scripting-Filter”, der in den meisten Browsern bereits integriert ist. Mit der empfohlenen Konfiguration “X-XSS-Protection: 1; mode=block” schützt du deine Besucher vor dem Angriff auf ihren Computer. Folgende Browser unterstützen den Filter: Internet Explorer, Chrome und Safari (Webkit).
Der »X-Content-Type-Options-Header« kann nur den Wert “nosniff” setzen. Dieser Wert verhindert, dass Internet Explorer und Google Chrome nach anderen MIME-Typen suchen, als durch den deklarierten Content-Type (zum Beispiel text/html) vorgegeben wurde. Google Chrome wird dadurch auch am Herunterladen von Erweiterungen gehindert. Somit sind sogenannte Drive-by-Download-Attacken nicht mehr möglich. Euer Rechner kann somit nicht mehr mit Schadcode infiziert werden. Das gilt natürlich nur für die Website, die diesen Response-Header gesetzt hat.
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
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).
- text/css
Scripte
- application/ecmascript
- application/javascript
- application/x-javascript
- text/ecmascript
- text/javascript
- text/jscript
- text/x-javascript
- text/vbs
- text/vbscript
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.
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-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.
Obacht vor dem Public-Key-Pinning
Erwähnt werden sollte der Vollständigkeit halber noch, dass es noch den Public-Key-Pins-Header gibt.
Jedoch kann das Public-Key-Pinning zu Problemen führen, sobald das eigene SSL-Zertifikat abgelaufen ist und durch ein neues ersetzt werden muss. Haben die Besucher in ihrem Browser dann noch das alte Zertifikat als einzig zu akzeptierendes abgespeichert, können sie nicht mehr auf die Seite zugreifen, wenn das SSL-Zertifikat mit einem neuen Public Key generiert wurde.
Das Smashing Magazine hat zum Thema Public-Key-Pinning einen Beitrag geschrieben, der auf die Problematik näher eingeht.
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.
Der Online-Dienst securityheaders kann für erheblich mehr Sicherheit sorgen. Wir können durch den Einsatz der richtigen HTTP-Response-Header nicht nur den eigenen Server absichern, sondern auch die Sicherheit unserer Besucher verbessern. Das Online-Tool zeigt dir genau auf, wo Sicherheitslücken bestehen und wie diese geschlossen werden können.
Dieser Beitrag wurde zuletzt am 12. Februar 2020 aktualisiert und um die Problematik Public Key Pinning erweitert.
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
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.
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-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.
Obacht vor dem Public-Key-Pinning
Erwähnt werden sollte der Vollständigkeit halber noch, dass es noch den Public-Key-Pins-Header gibt.
Jedoch kann das Public-Key-Pinning zu Problemen führen, sobald das eigene SSL-Zertifikat abgelaufen ist und durch ein neues ersetzt werden muss. Haben die Besucher in ihrem Browser dann noch das alte Zertifikat als einzig zu akzeptierendes abgespeichert, können sie nicht mehr auf die Seite zugreifen, wenn das SSL-Zertifikat mit einem neuen Public Key generiert wurde.
Das Smashing Magazine hat zum Thema Public-Key-Pinning einen Beitrag geschrieben, der auf die Problematik näher eingeht.
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.
Der Online-Dienst securityheaders kann für erheblich mehr Sicherheit sorgen. Wir können durch den Einsatz der richtigen HTTP-Response-Header nicht nur den eigenen Server absichern, sondern auch die Sicherheit unserer Besucher verbessern. Das Online-Tool zeigt dir genau auf, wo Sicherheitslücken bestehen und wie diese geschlossen werden können.
Dieser Beitrag wurde von drweb kopiert und zuletzt am 12. Februar 2020 aktualisiert und um die Problematik Public Key Pinning erweitert.