Security Headers: Schutz für Webseiten und Nutzer

Security Headers Titel

Security Headers haben durch Angriffsszenarien wie Spectre und Meltdown extrem an Relevanz gewonnen. Security Headers sind Einstellungen am HTTP-Header, die Regeln für die Kommunikation mit der Webseite setzen. So bieten sie Schutz sowohl für die Webseite als auch deren Nutzer. Mehr zum Thema Website Security in unserem großen Übersichtsartikel.

Davor schützen Security Headers

Neben Spectre und Meltdown gibt es eine Reihe weiterer Angriffsszenarien, die sich durch die korrekte Verwendung von HTTP Security Headern verhindern lassen:

Clickjacking durch Security Headers verhindern

Clickjacking (auch User Interface Redress Attack oder UI Redressing) ist eine Technik, bei der Angreifer verschiedene transparente oder opake Ebenen nutzen, um den Nutzer dazu zu bringen, auf ein manipuliertes interaktives Element zu klicken.

Klickt der Nutzer nun auf das überlagernde Element, wird nicht die erwartete Aktion, sondern schadhafter Code im Browser ausgeführt. Die Tragweite der Attacke reicht dabei vom ungewollten Post auf Twitter oder das unbeabsichtigte Liken einer Seite auf Facebook, bis hin zu Veränderungen von Plugin Einstellungen, die Kamera und Mikrofon freigeben.

Schutz gegen Clickjacking bietet die richtige Einstellung des Security Headers X-Frame-Options. Durch DENY wird die Darstellung eigener Inhalte auf fremden Domains komplett unterbunden. SAMEORIGIN erlaubt die Darstellung nur auf eigenen Domain, wohingegen ALLOW-FROM gefolgt von einer Domain, die Darstellung der Inhalten auf bestimmten Domains erlaubt.

Drive-By Download durch Security Headers verhindern

Ein Drive-By Download bezeichnet das ungewollte Herunterladen und Ausführen einer Schadsoftware auf dem Rechner des Besuchers. Dabei tarnt der Angreifer eine ausführbare Datei beispielsweise als style.css. Um den Content Type der Datei zu ermitteln, checkt der Browser den Inhalt der Ressource. Erkennt er dabei eine ausführbare Datei, bietet er diese zum Download an und führt sie ggf. aus.

Der Angreifer kann so beliebigen Code auch außerhalb des Browsers ausführen. Angriffe dieser Art können dabei auch über andere Wege wie zum Beispiel Web Sockets stattfinden.

Will man seine Nutzer vor Drive-By Downloads schützen, setzt man den X-Content-Type-Options HTTP-Header auf nosniff und sendet ihn möglichst bei jeder Ressource mit. Dadurch wird verhindert, dass der Browser den Content-Type herausfinden will und so schadhafte Dateien herunterlädt bzw. ausführt. Bestenfalls sind die Content-Type Header im Backend bereits richtig konfiguriert, damit gar kein Sniffing notwendig ist.

Im Kontext der aktuellen Angriffsszenarien Spectre und Meltdown wurde das Setzen der korrekten Content-Type Header und die Option nosniff von Chromium-Entwicklern empfohlen.

Cross Site Scripting (XSS) durch Security Headers verhindern

Bei XSS Attacken werden Schwachstellen in der Applikation ausgenutzt, um Code in die Seite einzuschleusen und im Browser-Kontext auszuführen. Beispielsweise kann der Angreifer das Inputfeld einer unsicheren Webseite nutzen, um Code über ein Formular einzugeben, welcher dann direkt nach Abschicken des Formulars von der Seite gerendert wird.

Ziel des Angriffs sind meist sensible Nutzerdaten. Durch das Einschleusen von JavaScript-Code können zum Beispiel Session-Cookies ausgelesen werden, womit der Angreifer die Identität des Opfers annehmen kann.

XSS-Attacken lassen sich unter anderem durch den Security Header X-XSS-Protection abwehren. Dabei versucht der Browser über Heuristiken eine XSS-Attacke zu erkennen und abzuwehren. XSS Heuristiken variieren sehr stark zwischen den einzelnen Browsern: Im Chrome per default eingeschaltet, ist der Browser-interne XSS Auditor im Safari über den Header zu aktivieren. Im Firefox bot in unseren Tests auch der gesetzte Header keinen Schutz.

Umfangreicher Schutz gegen XSS Attacken bietet der Content-Security-Policy (CSP) Header, der detailliert angibt, welche Quelle für welche Ressource erlaubt ist. Da durch den CSP Header allerdings auch das Ausführen von eigenen Inline Skripten beeinflusst werden kann, empfiehlt es sich zunächst die Reporting-Option zu nutzen (Content-Security-Policy-Report-Only), bevor man die einzelnen Regeln für seine Ressourcen im Header konfiguriert.

Information Disclosure durch Security Headers verhindern

Webserver und auch Browser können über HTTP-Header zu viele Informationen preisgeben und so potentielle Angriffe ermöglichen. Schickt der Webserver zu viel Information über die verwendete Software, kann ein Angreifer schnell herausfinden, welche Server sich über welche Sicherheitslücke angehen lassen.

Neben Webservern kann außerdem der Browser zu viel Information über den Referrer Header preisgeben, sodass der Angreifer empfindliche Informationen auslesen kann.

Mit Hilfe des Referrer-Policy Headers kann man dem Information Disclosure entgegenwirken. So lässt sich über den Header steuern, an welche Ziele der Browser den Referrer in welcher Form kommunizieren darf. no-referrer schickt beispielsweise gar keine Information weiter, wohingegen no-referrer-when-downgrade generell den Referrer mit schickt, aber nicht, wenn die Zielseite weniger sicher ist. Dies ist bei der Navigation von HTTPS nach HTTP der Fall.

Eine umfangreiche Dokumentation der Referrer-Policy Header Optionen mit Beispielen findet man auf der Seite des Security Researchers Scott Helme.

Security Headers automatisiert eingerichtet

Mit dem Cloud-Service wao.io lassen sich Sicherheitseinstellungen wie Security Headers automatisieren. Dafür ist keine Änderung am Quellcode der Seite vonnöten. In Ihrem Konto finden Sie im Tab “Security” alle wichtigen Einstellungsmöglichkeiten der vorgestellten Security Headers und erzielen so umfangreichen Schutz gegen Angreifer.

Security Headers und andere Sicherheitseinstellungen auf wao.io

Webseiten, die beim Test von securityheaders.com in der Hall of Shame landen, lassen sich durch das gezielte Setzen der Security Headers in wao.io out-of-the-box zu einem positiven Scoring verhelfen.

Jetzt ausprobieren – Schützen Sie Ihre Nutzer mit wao.io

 

Zur Blog-Startseite