Mehr Sicherheit durch Security Header

Security Header haben durch Angriffsszenarien wie Spectre und Meltdown extrem an Relevanz gewonnen. So twitterte Google Developer “Surma” kürzlich einen offiziellen Leitfaden an alle Web-Developer mit konkreten Hinweisen, um seine Nutzer vor Gefahren zu schützen.

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

Clickjacking

Clickjacking (auch User Interface (UI) 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.

  • X-Frame-Options HTTP-Header

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 Downloads

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.

  • X-Content-Type-Options HTTP-Header

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) Attacken

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.

  • X-XSS-Protection HTTP-Header

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.

  • Content-Security-Policy HTTP-Header

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

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.

  • Referrer-Policy HTTP-Header

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 Header in wao.io

wao.io bietet im Tab “Security” alle wichtigen Einstellungsmöglichkeiten der vorgestellten HTTP-Header und bietet so umfangreichen Schutz gegen Angreifer.

Webseiten, die auf dem Security-Header-Testtool securityheaders.io in der Hall of Shame landen, lassen sich durch das gezielte Setzen der Security Header in wao.io out-of-the-box zu einem positiven Scoring verhelfen.

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

Für einen tieferen Einblick in das Thema empfiehlt sich ein Besuch beim nächsten WebPerf Meetup im Kölner Startplatz. Unser Lead Developer Sebastian spricht am Donnerstag, den 1. Februar zum Thema Security-Header in Zeiten von Spectre und Meltdown.

 

 

Zur Blog-Startseite