Viele von euch denken sich jetzt sicherlich: “Oh mein Gott Security. Schnell den Post wieder schließen”. Ich gebe zu es ist durchaus ein mühsames Thema, aber absolut notwendig in der heutigen Zeit! Gerade wenn man als Entwickler im Web unterwegs ist sollte man zumindest von den Web Security Headern gehört haben. Deshalb geht es in diesem Artikel auch nicht darum wie man die Security Header umsetzt. Stattdessen beschreibe ich kurz, was HTTP Security Header sind und wozu sie nützlich sein können. Außerdem gibt dieser Artikel einen Überblick über die wichtigsten Security Header die heute verwendet werden.

Jeder der im Web arbeitet kennt (sollte) das HTTP-Protokoll. Es wird überall im Web verwendet und ist daher eines der wichtigsten Kommunikationsprotokolle. Mit der Einführung der Internet of Things (IoT) wurde die Notwendigkeit, das HTTP-Protokoll zu sichern, noch größer als bisher. Die Vorteile von HTTP sind seine Einfachheit und seine breite Verfügbarkeit von Software-Implementierungen. Die Nachteile sind allerdings, dass es keine Sicherheitsimplementierung gibt.

Aus diesem Grund wurde das HTTPS-Protokoll entwickelt. HTTPS umschließt HTTP in TLS-Zertifikaten (Transport Layer Security), was der erste Schritt zum Sichern der Kommunikation über das Internet war. Aber nur die Verwendung des HTTPS-Protokolls, ist immer noch nicht ausreichend. Um die Kommunikationssicherheit auf ein höheres Niveau zu bringen, verwenden IT-Security Experten jetzt die HTTP-Response-Header. Diese sind einfache Key-Value Paare, um Sicherheitsrichtlinien von Servern auf Clients zu übertragen. Einer der ersten Security Header ist der HTTP Strict Transport Security-Header, der den Browser des Benutzers zwingt, nur HTTPS-Anforderungen für die Kommunikation mit einer Domäne zu verwenden. Außerdem haben die Entwickler von Browsern mehr und mehr Security-Header wie X-Frame-Options eingeführt. Dieser informiert den Browser darüber, wie Daten interpretiert werden müssen und wo sie angefordert werden dürfen.

Was sind HTTP Security Header?

Ein HTTP-Header ist ein Key-Value-Paar, das Metadaten über den Inhalt der Antwort beschreibt. HTTP-Security Header geben einem User Agent (z.B: Browser) Informationen über die Verarbeitung des Inhalts in der Antwort. Anbieter von Browsern veröffentlichten neue HTTP-Header, um die korrekte Interpretation der empfangenen Daten sicherzustellen und ihre Benutzer zu schützen. Im Gegensatz zu HTTPS ändert es nicht, wie die Daten übertragen werden. HTTPS verschlüsselt zum Beispiel Daten, aber die Header können User Agents beschränken, um Anfragen nur an einige vertrauenswürdige Domains statt an jede verfügbare Domain zu richten.

Unterschied zwischen HTTPS und Security Headers

HTTPS schützt nur die Daten von Requests und Responses. HTTP-Security Headers liefert stattdessen Informationen über die Daten und darüber, wie der Client damit umgehen soll. Während HTTPS für die Verwaltung sicherer Verbindungen zuständig ist, sind HTTP-Header dafür verantwortlich, wie der Inhalt angezeigt wird und von welchen Domänen ein User Agent andere Informationen wie Stylesheets, Skript-Dateien oder Bilder anfordern darf. Der Benutzer soll mit diesen Headern vor Angriffen wie Clickjacking oder Cross-Site Scripting (XSS) geschützt werden.

Die bekanntesten Security-Header

Referrer-Policy

Ein Client kann einen Referer [sic!] – Request-Header enthalten, der angibt auf welcher Webseite der Benutzer zuvor war, beziehungsweise von welchem Server der Benutzer umgeleitet wurde. Dieser Header wird hauptsächlich für Analysen verwendet und sollte niemals als Authentifizierungsmethode verwendet werden. Ein Server möchte diese Art von Informationen jedoch möglicherweise nicht teilen. Hierfür kann der Server eine Referrer-Policy verwenden. Wenn der Wert dieses Headers beispielsweise kein Verweis ist, sollte ein Client niemals einen Referer-Header an diese Site oder an die erste Anfrage an einen anderen Webserver senden.

Content-Security-Policy

Dieser Header wird verwendet um zu steuern, von welchen Domänen eine Quelle wie ein Stylesheet oder ein Skript geladen werden kann. Jede andere Domäne wird nicht in Betracht gezogen und verhindert somit einen XSS-Angriff.

Public Key Pinning

Ein Webserver kann das Risiko von Man-in-the-Middle-Attacken (MIT) reduzieren, indem er seinen öffentlichen Schlüssel, der dann in nachfolgenden TLS-Verbindungen verwendet wird, in die allererste HTTP-Antwort einfügt. Der User Agent speichert es und verwendet nur noch diesen spezifischen Schlüssel für zukünftige Anfragen. Ein Angreifer könnte jedoch den Header so manipulieren, dass ein Benutzer den falschen öffentlichen Schlüssel speichert.

X-Frame-Options

Dieser Header soll  Clickjacking-Angriffe verhindern. Mit den Optionen DENY, SAMEORIGIN oder einer Gruppe zulässiger Domänen muss ein Client überprüfen, ob ein HTTP-Inhalt in einem Frame angezeigt werden kann. Clickjacking wird durchgeführt, indem eine andere Website in einen unsichtbaren Iframe geladen und über den geladenen Inhalt gelegt wird. Wenn ein Opfer versucht, auf eine Schaltfläche zu klicken, um beispielsweise einen Dialog zu schließen, löst es eine Aktion im Iframe aus, beispielsweise eine Anmeldung an ein E-Mail-Konto.

X-XSS-Protection

Ein Webserver kann die XSS-Erkennung auf einem Client-Webbrowser aktiv aktivieren. Der Server verwendet hierfür den X-XSS-Protection-Header. Mit der Option 0 sollte ein Client den XSS-Schutz nicht deaktivieren. Wenn Sie ihn jedoch auf 1 setzen, sollte der Web-Browser versuchen, das XSS zu bereinigen und die Seite dennoch rendern. Fügt man Optionsmodus = Block hinzu, wird dem Webbrowser geraten, den Inhalt nicht zu rendern. Ein Webserver kann auch eine URL bereitstellen, um eine Erkennung von XSS zu melden. Da es noch nicht standardisiert ist, unterstützen nicht alle Browser diesen Header.

X-Content-Type-Options

Setzt ein Webserver diesen HTTP-Header mit der Option nosniff, interpretiert der Webserver MIME-Dateien nur so wie sie deklariert sind. Wenn beispielsweise eine JavaScript-Datei als reiner Text deklariert ist, sollte sie nicht ausgeführt werden.

Cross-Origin Resource Sharing

Die Cross-Origin Resource Sharing (CORS) ist kein einzelner HTTP-Header, sondern ein Set von vielen Headern. Normalerweise führt ein Webbrowser nur Anforderungen an einen Server mit demselben Ursprung durch. Wenn ein Webserver wünscht, dass eine andere Webanwendung auf seine Ressourcen zugreift, muss er den Header Access-Control-Allow-Origin mit den zulässigen Domänen angeben. Alternativ kann auch ein * zurückgeben werden. Dieser gibt an, dass alle Domänen zulässig sind.

HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) ist ein serverseitiger Sicherheitsmechanismus, der z.B: Webbrowser dazu zwingt, Verbindungen nur über HTTPS herzustellen. Viele Websites wie Banken setzen auf sicheren end-to-end Transport, um die Daten ihrer Nutzer zu schützen. Leider erlauben Browser normalerweise ihren Benutzern, diese Schutzmechanismen zu deaktivieren, um nutzbar zu sein. Wenn zum Beispiel ein Zertifikat eines Webservers abgelaufen ist, erlaubt der Browser dem Benutzer zu entscheiden, ob weiterhin mit dem Server kommuniziert werden soll. Dieses Verhalten wird oft als “click(ing) through”-Security beschrieben. Mit HSTS kann dieses Verhalten verhindert werden.

Hat man HSTS konfiguriert, transformiert der Browser alle unsicheren URIs (http: //) auf HSTS-Hosts in sichere URIs (https: //), bevor die Anforderungen gesendet werden. Wenn somit irgendwo im Code eine Ressource wie ein Bild über eine unsichere HTTP-Verbindung angefordert wird, macht der Browser automatisch eine HTTPS URI daraus. Außerdem werden alle sicheren Anfragen beendet, wenn ein Fehler oder eine Warnung auftritt. Etwa 85% der weltweit verwendeten Browser unterstützen den HSTS-Mechanismus.

Schlusswort

Auch mit diesen Headern gibt es immer noch genug Sicherheitslücken die ein Hacker ausnutzen kann, aber die Verwendung reduziert dieses Risiko zumindest schon mal. Leider (wie oft in der Security) sind manche Header wie z.B: der HSTS etwas mühsam und zeitaufwendig bei der Umsetzung.

P.S. Die meisten von euch werden schonmal einen dieser Header verwendet haben, auch wenn es euch vielleicht nicht aufgefallen ist.