Sicherheitsauswirkungen von HTTP-Response-Headern

Wenn ein Webserver eine HTTP-Anfrage empfängt, verarbeitet er sie und sendet eine Antwort zurück, die die angeforderte Ressource und zusätzliche Informationen in Form von HTTP-Response-Headern enthält. Diese Header liefern wichtige Daten wie das Datum der letzten Änderung, Inhaltstypen und Cache-Control-Einstellungen. Der Browser verwendet diese Informationen anschließend, um zu bestimmen, wie die jeweilige Ressource angezeigt oder gespeichert wird. Dieser Prozess sorgt für eine effiziente Kommunikation zwischen Webservern und Browsern.

Aus Sicht der Cybersicherheit stellen HTTP-Response-Header potenzielle Angriffsvektoren dar, bieten aber auch Möglichkeiten für zusätzliche Schutzmaßnahmen. Sie können sensible Daten wie Authentifizierungstoken, Cookies und Sitzungs-IDs enthalten. Gelangen diese in die Hände von Angreifern, können sie damit Autorisierungskontrollen umgehen oder Benutzerkonten übernehmen. Gleichzeitig können wir Header nutzen, um das Caching zu steuern, den Typ der zurückgegebenen Inhalte festzulegen und Angriffe wie Cross-Site-Scripting (XSS) und Clickjacking zu verhindern.

HTTP-Response-Header bieten verschiedene Sicherheitsfunktionen – darunter Authentifizierung, User-Agent-Tracking, den Schutz vor XSS und die Durchsetzung der HTTPS-Nutzung. Einige HTTP-Header wie Etag, Last-Modified und Content-Type sind für Sicherheitszwecke zwar nicht hilfreich, doch die Header Content Security Policy (CSP), HTTP Strict Transport Security (HSTS) und X-Frame-Options bieten Möglichkeiten, unsere Server besser abzusichern.

Dieser Artikel stellt mehrere HTTP-Header vor, die sich auf die Sicherheit auswirken, und empfiehlt Best Practices für den Einsatz von HTTP-Response-Headern zum Schutz von Webanwendungen.

HTTP-Response-Header für mehr Sicherheit nutzen

Mit HTTP-Response-Headern können wir verschiedene Arten ausnutzbarer Sicherheitslücken entschärfen.

Sicherheitslücken im Zusammenhang mit HTTP-Response-Headern

Die richtigen HTTP-Response-Header entschärfen direkte Angriffe und helfen auch bei Sicherheitslücken, die nicht unmittelbar mit ihnen zusammenhängen. Beispiele für verschiedene Arten von Angriffen und Sicherheitslücken sind:

• Cross-Site-Request-Forgery (CSRF): Angreifer können CSRF, auch als One-Click-Angriffe bekannt, nutzen, um den Webbrowser einer Person dazu zu bringen, in ihrem Namen unerwünschte Aktionen auszuführen.

• Sitzungsübernahme: Angreifer verschaffen sich unbefugten Zugriff, indem sie Sitzungs-IDs authentifizierter Benutzer stehlen und deren bestehende Sitzungen ohne Zugangsdaten wie Benutzername und Passwort übernehmen. So umgehen sie herkömmliche Authentifizierungssysteme.

• Datenlecks: HTTP-Response-Header können Passwörter, Kreditkartennummern und andere sensible Informationen enthalten, die bei einer fehlerhaften Konfiguration möglicherweise offengelegt werden.

• Man-in-the-Middle-Angriffe (MITM): Angreifer nutzen MITM-Angriffe, um während einer Transaktion die Kommunikation zwischen zwei Parteien abzufangen, zu verändern oder zu blockieren. Keine der beiden Parteien bemerkt, dass die andere mit einer unbefugten dritten Partei kommuniziert.

• Clickjacking-Angriffe: Indem Angreifer Schwachstellen in den HTML-Frames einer Website ausnutzen, können sie Nutzern gefälschte Inhalte anzeigen. Ein Klick darauf veranlasst sie zu unbeabsichtigten Aktionen oder dazu, unwissentlich vertrauliche Informationen preiszugeben.

Die Sicherheit von Webanwendungen ist entscheidend, insbesondere angesichts der vielen möglichen Angriffswege. In den vergangenen Jahren haben wir eine Zunahme öffentlichkeitswirksamer Sicherheitsverletzungen mit schwerwiegenden Folgen erlebt. Zum Beispiel:

• Bei einem kürzlich bekannt gewordenen Datenleck beim Kreditauskunftsunternehmen TransUnion erbeuteten Angreifer die Daten von mehr als 50 Millionen Menschen in Südafrika und forderten ein Lösegeld von 15 Millionen US-Dollar.

• WordPress-Plug-ins für die DSGVO können für XSS- und CSRF-Angriffe anfällig sein. Ein Plug-in betraf 2018 10.000 Websites, ein anderes legte 2020 700.000 Websites offen.

• Große Technologieunternehmen sind besonders attraktive Ziele. Für das Fahrdienstunternehmen Uber kosteten CSRF- und Sitzungsübernahme-Schwachstellen glücklicherweise nur rund 5.000 US-Dollar an ausgezahlten Bug-Bountys.

Angesichts der Häufigkeit und des Ausmaßes solcher Angriffe ist klar: Die Sicherheit zu erhöhen und aufrechtzuerhalten – auch durch HTTP-Header – ist unverzichtbar.

HTTP-Response-Header mit Auswirkungen auf die Sicherheit

Datenlecks sind eine Sicherheitslücke, die direkt mit HTTP-Response-Headern zusammenhängt. CSRF-, Sitzungsübernahme- und MITM-Angriffe müssen HTTP-Response-Header nicht zwangsläufig einbeziehen. Dennoch können wir sie durch sichere HTTP-Header wie CSP und HTTP Strict Transport Security (HSTS) entschärfen und Best Practices für andere sicherheitsrelevante Header befolgen, darunter die folgenden.

HTTP-Strict-Transport-Security-Header

Der HSTS-Response-Header schützt Anwendungen vor MITM-Angriffen, Datenlecks und Clickjacking. Er erzwingt, dass die gesamte Kommunikation zwischen Browser und Server über HTTPS statt über unverschlüsseltes HTTP erfolgt. So verhindert er, dass Angreifer den Datenverkehr über ihre schädlichen Proxyserver umleiten und sensible Daten abfangen oder manipulieren, ohne dass eine der beiden Parteien davon etwas bemerkt.

HSTS enthält Informationen zu den Sicherheitsrichtlinien einer Website, zum Beispiel:

• Wie lange die Verbindung aktiv bleibt (max age).

• Ob der Schutz auch Subdomains umfasst.

• Welche Zertifikatstypen akzeptiert werden.

Um den HSTS-Response-Header optimal zu nutzen, sollten wir immer einen Wert für die maximale Dauer festlegen. Dieser sollte dem Zeitraum entsprechen, in dem sich Clients merken sollen, eine sichere Verbindung herzustellen, bevor sie eine weitere Anfrage über den TLS/SSL-Tunnel senden.

Content-Security-Policy-Header

CSP ist wichtig, um sich gegen verschiedene Arten von Angriffen zu schützen. Entwickler können damit zulässige Ressourcen und ihre Ursprünge auf eine Positivliste setzen, Direktiven definieren, festlegen, ob Inline-Skripte oder eval() erlaubt sind, und entscheiden, ob Style-Attribute in HTML zugelassen werden.

Mit dem HTTP-Content-Security-Policy-Response-Header können wir festlegen, welche Domains und Ressourcen in den Inhalten einer Website erlaubt oder blockiert sind. Er schützt vor XSS und den bereits genannten Sicherheitslücken sowie vor weiteren schädlichen Aktivitäten wie Clickjacking, Dateninjektion, Code-Injection, CSRF und dem unbefugten Zugriff auf sensible Informationen. CSP enthält Direktiven, die Browsern vorgeben, wie sie Anfragen aus nicht vertrauenswürdigen Quellen außerhalb unserer Domain behandeln sollen. Das gilt auch für das Laden von Skripten, Bildern und anderen ausnutzbaren Ressourcen.

Diese Richtlinien helfen dabei, den CSP-Header so zu konfigurieren, dass er proaktiv vor Sicherheitslücken schützt:

• Verwenden Sie nach Möglichkeit Richtlinien, die Aktivitäten blockieren, statt sie zu erlauben. So werden Anfragen aus nicht vertrauenswürdigen Quellen außerhalb Ihrer Domain standardmäßig blockiert.

• Nutzen Sie Wildcard-Subdomains (das Präfix *.<your-domain-name> vor Ihrem Hauptdomainnamen).

• Beschränken Sie den Zugriff auf bekannte, vertrauenswürdige Quellen, statt Anfragen von beliebigen Quellen pauschal zu erlauben. Ergänzen Sie außerdem Direktiven, die Browsern vorschreiben, wie sie bestimmte Anfragen aus nicht vertrauenswürdigen Quellen außerhalb unserer Domain behandeln müssen – etwa das Laden von Skripten, Bildern und anderen ausnutzbaren Ressourcen.

Eine konsequente Sicherheitsstrategie stellt sicher, dass nur autorisierte Clients sensible Informationen einsehen können, und verhindert Datenlecks über unbeabsichtigte nachgelagerte Wege. Außerdem können wir strenge Validierungsmechanismen wie Subresource Integrity (SRI) einsetzen, um die Integrität der Ressourcen einer Website zu überprüfen und sicherzustellen, dass Angreifer sie nicht manipuliert haben.

Durch die Kombination von SRI und CSP können wir sicherstellen, dass nur vertrauenswürdige, unveränderte Ressourcen von Drittanbietern in unsere Webseiten geladen werden.

X-Content-Type-Options-Header

Mit dem X-Content-Type-Options-Header können wir Browser anweisen, den Typ der bereitgestellten Datei oder des Inhalts niemals automatisch zu ermitteln. Dadurch wird es für Angreifer deutlich schwieriger, schädlichen Code in eine Website einzuschleusen, da der Browser beliebige Skriptdateien, die mitgesendet werden, nicht parsen oder ausführen kann. Der X-Content-Type-Options-Header ist somit eine erste Verteidigungslinie gegen schädliche Inhalte und XSS-Angriffe.

Achten Sie bei der Konfiguration und Verwendung dieses Headers darauf, dass alle Websites Inhalte mit strikt festgelegten MIME-Typen bereitstellen. Vermeiden Sie nach Möglichkeit Wildcards (*) in diesen Werten. Wenn Sie konkrete Dateitypen angeben, wissen Browser genau, welche Ressourcen sie erwarten können, und müssen diese nicht selbst ermitteln.

X-Frame-Options-Header

X-Frame-Options schützt Webanwendungen vor Clickjacking-Angriffen. Der Header enthält eine Direktive, die dem Browser mitteilt, ob er den Inhalt innerhalb eines <iframe>-Elements auf einer Website eines Drittanbieters anzeigen darf.

Zwei Direktiven kommen häufig zum Einsatz. DENY verhindert, dass die angeforderte Ressource auf anderen Websites in einen Frame eingebettet wird. SAMEORIGIN erlaubt die Anfrage nur, wenn beide Seiten demselben Ursprung gemäß Same-Origin-Policy angehören. Diese Konfiguration schützt vor Clickjacking und anderen XSS-Sicherheitslücken.

Am besten stellen Sie sicher, dass alle von der Webanwendung bereitgestellten Ressourcen immer X-Frame-Options enthalten – mit DENY statt SAMEORIGIN. Außerdem sollten wir standardmäßig den höchstmöglichen Schutz wählen, da wir nie sicher wissen können, wann und wie Inhalte außerhalb unseres Ursprungs gelangen.

Referrer-Policy-Header

Der Referrer-Policy-Header steuert, wie Referrer-Informationen von einer Anwendung oder Website an eine andere weitergegeben werden. Er umfasst vier zentrale Direktiven – none, no-referrer, no-referrer-when-downgrade und origin –, die festlegen, wie ein Browser bei der Navigation die verweisende URL an andere Websites oder Anwendungen weitergibt.

Wir können diesen Header an unsere individuellen Anforderungen anpassen, um sicherzustellen, dass sensible Daten nicht versehentlich offengelegt werden, während Nutzer zwischen verschiedenen Webangeboten oder Domains navigieren.

Idealerweise setzen Sie Referrer-Policy auf no-referrer, damit Request-Header keine Referrer-Informationen enthalten, wenn Nutzer auf externe Links klicken. Diese Einstellung schützt die Privatsphäre, indem sie verhindert, dass personenbezogene Daten über unbeabsichtigte Kanäle nach außen gelangen.

Sicherheits-Header in JavaScript festlegen

Im folgenden Abschnitt stellen wir drei Tools vor, mit denen Sie bei der Entwicklung mit JavaScript Sicherheits-Header festlegen können. Beachten Sie, dass Sie diese Tools auch mit anderen Sprachen und Ökosystemen verwenden können.

Nach einem Überblick über die einzelnen Tools zeigen wir anhand eines praktischen Beispiels, wie Sie damit Sicherheits-Header festlegen.

Helmet für Express.js

Helmet ist eine Sammlung sicherheitsrelevanter HTTP-Response-Header, die Webanwendungen vor Angriffen und Sicherheitslücken schützt. Helmet für Express.js ist eine Erweiterung des Helmet-Pakets, die speziell für das Express.js-Framework entwickelt wurde. Sie stellt neun kleinere Middleware-Funktionen bereit, die bestimmte sicherheitsrelevante HTTP-Response-Header für Anwendungen festlegen.

Helmet für Express.js lässt sich einfach einrichten. Installieren Sie Helmet zunächst mit diesem Befehl:

1npm install helmet

Verwenden Sie anschließend den folgenden Code, um sowohl das Express-Framework als auch das Helmet-Paket einzubinden und deren Middleware-Funktionen zu nutzen. Damit können wir die Response-Header festlegen:

1const express = require("express");
2const helmet = require("helmet");

Erstellen Sie als Nächstes mit diesem Code eine Express-Anwendungsinstanz, weisen Sie sie einer Variablen zu und verwenden Sie die Middleware-Funktionen von Helmet:

1const app = express();
2app.use(helmet());

Bei der Initialisierung von Helmet werden mehrere Sicherheits-Header festgelegt, darunter die fünf oben besprochenen. Die Optionen einzelner Header in Helmet für Express.js können Sie anpassen, indem Sie sie mit folgendem Code zur Middleware helmet() hinzufügen:

1app.use(
2  helmet({
3    X-Frame-Options: { policy: "DENY" },
4  })
5);

Helmet für Fastify

Helmet für Fastify ist ein Middleware-Paket, mit dem Sie dem Fastify-Webframework wichtige Sicherheits-Header hinzufügen können. Es handelt sich im Wesentlichen um einen Wrapper für Helmet, der dieselben Optionen unterstützt.

Installieren Sie Helmet für Fastify mit folgendem Befehl:

1npm i @fastify/helmet.

Binden Sie anschließend mit diesem Code das Fastify-Framework und Helmet für Fastify ein:

1const fastify = require('fastify');
2const helmet = require('@fastify/helmet');

Registrieren Sie als Nächstes das Helmet-Plug-in für Ihre Anwendung, indem Sie diesen Code ausführen:

1fastify.register(helmet);

Mit diesem Befehl werden die grundlegenden Sicherheits-Header automatisch festgelegt.

check-my-headers

Check-my-headers ist ein kostenloses CLI-Tool, mit dem wir die HTTP-Header unserer Website schnell auf potenzielle Schwachstellen testen können. Es ist kostenlos und unabhängig vom Framework. Das heißt, es prüft unsere Header, ohne zu berücksichtigen, womit wir sie konfiguriert haben.

Wir können das Tool global mit npm install -g check-my-headers installieren und einen schnellen Einzelscan starten, indem wir npx check-my-headers https://yourwebsite.com in die CLI eingeben.

Fazit 

Einige wichtige HTTP-Antwort-Header wirken sich auf die Websicherheit aus. Wenn wir bewährte Methoden für ihren Einsatz nutzen, schaffen wir eine zusätzliche Sicherheitsebene für Webanwendungen. Die fünf hier besprochenen Header helfen vor verschiedenen Schwachstellen zu schützen, darunter CSRF-Angriffe, Session-Hijacking, Datenlecks, MITM-Angriffe und Clickjacking – Angriffe, die erhebliche und oft irreparable Schäden verursachen können. Zu verstehen, wie HTTP-Antwort-Header die Sicherheit beeinträchtigen oder stärken, ist ein wichtiger Schritt, um diese verbreiteten Angriffsvektoren einzudämmen.

Richtig eingesetzt und konfiguriert sind Antwort-Header für die Websicherheit unverzichtbar. Sie schützen die Privatsphäre der Nutzer und ermöglichen mehr Flexibilität bei der Absicherung der Kommunikation zwischen Webservern und Clients.