Einsatz von modernen Security-Headers bei Webapplikationen

Only in German available.

Die verschiedenen Security-Header bei HTTP-Antworten können wesentlich zur Sicherheit von Webapplikationen beitragen. Im Gegenzug können falsch oder nicht gesetzte Security-Header Applikationen unsicherer machen. Dabei gilt es zwischen modernen Security-Header und veralteten Security-Header zu unterscheiden. In einem vorherigen Blog-Beitrag Einsatz von veraltete Security-Headers bei Webapplikationen haben wir den Einsatz und die Verbreitung von veralteten Security-Header angeschaut. In diesem Beitrag schauen wir uns die Verbreitung und den Einsatz der modernen Security-Header an. Dabei klassifizieren wir bei jedem Header die Einstellungen, sofern möglich.

Fazit

Unsere Analyse zeigt, dass Security-Headers entweder wenig restriktiv oder gar nicht eingesetzt werden. Bei neueren Security-Headern gibt es unsichere Einstellungen, die für den Menschen leicht als unsicher erkennbar sind (z. B. unsafe-inline, unsafe-none, unsafe-eval). Trotz ihrer offensichtlich unsicheren Natur werden solche Werte häufig verwendet. Schreibfehler, die zu Syntaxfehlern führen, wurden ebenfalls festgestellt, wenngleich sie in der Gesamtzahl keine signifikante Rolle spielten. Neuere Security-Header wie die Content-Security-Policy sind allerdings robust genug, dass Fehler in einzelnen Direktiven nicht den gesamten Header ungültig machen. Auffällig ist, dass die gewählten Einstellungen häufig auf grösstmögliche Kompatibilität statt auf maximale Sicherheit abzielen. Hinsichtlich Sicherheit wäre es wünschenswert, dass Security-Headerhäufiger und restriktiver implementiert werden. Während einige Header mit geringem Aufwand korrekt gesetzt werden können, erfordern andere grössere Anpassungen.

Top 6 der am häufigsten verwendeten Security-Header. Die zwei roten Security-Header (X-Frame-Options und X-XSS-Protection) gelten als veraltet und sollten nicht mehr eingesetzt werden.

Daten zu den Security-Header

Access-Control-Allow-Origin

Empfehlung: Wird dieser Header verwendet, die genaue Origin angeben und nicht "*" als Wildcard.

Der HTTP Access-Control-Allow-Origin-Response Header gibt an, mit wem die Daten der Antwort geteilt werden dürfen. Wird dieser Header nicht verwendet, ist die Webseite automatisch durch die Same-Origin-Policy geschützt. Mit diesem Header wird die Same-Origin-Policy unter bestimmten Umständen gelockert.

Dieser Header wird sehr selten eingesetzt. Da er verwendet wird, um die Same-Origin-Policy aufzuweichen, ist der geringe Einsatz positiv zu werten.

Von den gesetzten Headern haben über 90% den "*" gesetzt. So wie dieser Header mehrheitlich eingesetzt wird, macht er die Webapplikationen unsicherer.

Content Security Policy

Empfehlung: Der CS- Header kann je nach Anwendung sehr komplex sein. Die einzelnen Direktiven sollten so restriktiv wie möglich gesetzt werden.

Wenn immer möglich sollte auf Einstellungswerte mit "unsafe" im Namen verzichtet werden. Eine sichere CSP muss für jede Applikation einzeln definiert und gepflegt werden, ein generischer Ansatz mit Standardwerten funktioniert nicht.

Der Content-Security-Policy-Header stellt einen umfassenden Mechanismus zur Verfügung, der die Konfiguration zahlreicher sicherheitsrelevanter Einstellungen ermöglicht. Er kann als eine Art "Browser-Firewall" angesehen werden, welche dem Browser angibt, von welchen Quellen externe Inhalte (Bsp. Bilder, Frame-Inhalte, etc.) geladen werden dürfen oder von wo Javascript-Code ausgeführt werden darf. Um den besten Nutzen einer CSP für eine Webapplikation zu erhalten, muss auch die Webapplikation entsprechend entwickelt werden.

Eine Auswertung der CSP auf vorhanden bzw. nicht vorhanden greift zu kurz. Bei einer CSP müssen die einzelnen Direktiven im Detail ausgewertet werden.

Es wurde eine Gesamtübersicht über die 15 meist verwendeten und explizit gesetzten Direktiven erstellt. Von den vier wichtigen Direktiven frame-ancestors, default-src, script-src und object-src wurden die konkret eingestellten Werte auf mögliche Probleme untersucht und gemäss der Klassifikation des Google-CSP-Validators klassifiziert.

Dieser Header wird von etwas mehr als 6% eingesetzt. Da die Content-Security-Policy einen grossen Beitrag zur Sicherheit leisten kann und viele veraltete Security-Header ablöste, wäre es wünschenswert, diesen öfters anzutreffen.

Diese Auflistung zeigt, dass mehrheitlich der Source gesetzt wird. Ob bei jeder Webapplikation die korrekten Direktiven ausgewählt wurden, kann nicht bewertet werden, da diese von der Funktionalität der Webapplikation abhängig sind.

frame-ancestors

Diese Direktive wird von knapp 70% aller CSPs eingesetzt. Bei fast 99% ist der Einsatz in Ordnung, somit darf der Inhalt nicht in fremden Seiten eingebettet werden.

default-src

Diese Direktive wird von etwas mehr als 40% aller CSPs eingesetzt. Bei 68% ist der Einsatz in Ordnung. Bei knapp 29% ergab die Analyse ein hohes Risiko. Die Direktive default-src ist eine Fallback-Direktive (Fallback für Bsp. img-src, style-src, connect-src, etc.), weshalb ihr eine besondere Bedeutung zukommt. Zu wenig restriktive Werte haben hier einen grossen Einfluss.

script-src

Diese Direktive wird von etwas mehr als 39% aller CSPs eingesetzt. Bei 19% ist der Einsatz in Ordnung. Bei 40% besteht die Möglichkeit, mit falschen Werten oder je nach eingesetzten Technologien den script-src unsicher zu machen. Bei knapp 41% ergab die Analyse ein hohes Risiko.

object-src

Diese Direktive wird von etwas mehr als 20% aller CSPs eingesetzt. Bei 72% ist der Einsatz in Ordnung. Bei 23% besteht die Möglichkeit mit falschen Werten oder je nach eingesetzten Technologien den object-src unsicher zu machen. Bei knapp 5% ergab die Analyse ein hohes Risiko.

Content-Type

Empfehlung: Header verwenden und das Charset explizit angeben.

Der Content-Type Header ist kein eigentlicher Security-Header. Dennoch kann er bei HTML-Dokumenten einen Schutz vor XSS-Angriffen bieten. Wird dieser Header ohne das Charset gesetzt, kann ein Angreifer durch die Verwendung "exotischer" Charsets, die vom Browser nicht unterstützt werden und ein Fallback auslösen, potenzielle XSS-Filter-Mechanismen umgehen und schädlichen XSS-Content einschleusen.

99.9% aller Webapplikationen setzen diesen Wert. Das Setzen dieses Headers ist Standard.

Bei 22.5% wird kein Charset gesetzt. Wird kein Charset gesetzt, ist die Seite potenziell anfälliger für XSS-Angriffe. Das explizite Setzen des Charsets hat in der Regel keinen Einfluss auf die Funktion der Seite, deshalb gibt es keinen Grund, das Charset nicht explizit zu definieren.

Cross-Origin-Embedder-Policy (COEP)

Empfehlung: Ein Dokument sollte Ressourcen nur von derselben Origin oder explizit erlaubte Ressourcen von anderen Origins laden, deshalb sollte der Header auf require-corp gesetzt werden und erlaubte Ressourcen mit dem Attribut crossorigin kennzeichnen.

Der HTTP Cross-Origin-Embedder-Policy Header konfiguriert die Einbettung von crossorigin Ressourcen in das Dokument.

Gerade einmal 0.3% aller Antworten enthielten eine Cross-Origin-Embedder-Policy. Die Verbreitung dieses Headers ist sehr gering.

Die Auswertung der gesetzten Werte ergab folgendes Bild: 12% der Einstellungen können als sicher betrachtet werden. Bei 58% war credentialless gesetzt. Dieser Wert ist nicht ideal, da dadurch potenziell sensible Informationen geleakt werden können. In 30% der Fälle war unsafe-none gesetzt, was bedeutet, dass Cross-Origin-Ressourcen geladen werden können.

Cross-Origin-Opener-Policy (COOP)

Empfehlung: Der Browsing-Kontext sollte ausschliesslich auf Dokumente mit der gleichen Origin isoliert werden.

Mit dem Cross-Origin-Opener-Policy Response-Header kann eine Website steuern, ob ein neues Dokument der obersten Ebene, das mit Window.open() oder durch navigieren zu einer neuen Seite geöffnet wird, in derselben Browsing-Kontextgruppe oder in einer neuen Browsing-Kontextgruppe geöffnet wird.

Nur 1.3% der Webapplikationen setzt diesen Header ein. Die Verbreitung dieses Headers ist gering.

Wird der Header verwendet, ist er bei 82.9% sicher gesetzt. Bei 1.9% ist der Wert potentiell unsicher eingestellt. Bei 15.2% ist der Wert auf unsafe-none gesetzt, was die gemeinsame Nutzung von Dokumenten in seiner Browsing-Kontextgruppe erlaubt und ist somit unsicher.

Cross-Origin-Resource-Policy (CORP)

Empfehlung: Das Laden von Ressourcen sollte auf die Domain und Subdomains beschränkt werden.

Der HTTP Cross-Origin-Resource-Policy Header gibt an, ob der Browser no-cors Cross-Origin- oder Cross-Site-Anfragen blockieren soll.

Nur 0.3% der Webapplikationen setzt den Header ein, dieser Header wird somit äusserst selten eingesetzt.

Wird der Header verwendet, ist er bei 75.2% sicher gesetzt. Bei 24.8% ist der Wert auf cross-origin gesetzt, dies erlaubt den Zugriff auf Ressourcen von beliebigen Domains, vorausgesetzt andere Mechanismen wie CORS schränkt dies nicht ein.

Permissions-Policy

Empfehlung: Der Header sollte so gesetzt werden, dass alle Funktionen, welche die Webapplikation nicht benötigt, deaktiviert werden.

Werden Funktionen benötigt, sollten diese nur für bestimmte Domains aktiviert werden.

Der HTTP Permissions-Policy Header bietet Einstellungen, um die Verwendung von Browser-Funktionen zu erlauben oder zu verweigern (Bsp. Zugriff auf den Standort oder das Mikrofon). Dieser Header gilt zurzeit als experimentell. Die Browserunterstützung ist noch gering und ist je nach Direktive nicht vorhanden.

Die Analyse des Headers beschränkt sich auf vorhanden, nicht vorhanden und vorhanden jedoch mit ungültiger Syntax. Eine Auswertung auf die einzelnen Direktiven und ihren Einsatz wurde nicht gemacht, da nicht eruiert werden kann, ob die Einstellung der Direktive für den Einsatz in der jeweiligen Webapplikation sinnvoll ist.

Referrer-Policy

Empfehlung: Bei modernen Browsern wird der Standard strict-origin-when-cross-origin verwendet, wenn kein Header explizit gesetzt wird. Trotzdem sollte der Header immer explizit auf strict-origin-when-cross-origin gesetzt werden.

Bei dieser Einstellung kann die Origin an Dritte übermittelt werden (nicht jedoch der gesamte Pfad oder Query-String). Sollen keine Informationen an Dritte gesendet werden, ist no-referrer oder same-origin als Einstellung zu wählen.

Der Referrer-Policy Header steuert, wie viele Referrer-Informationen (die mit dem Referer Header gesendet werden) in die Anfragen aufgenommen werden.

Bei etwas mehr als bei 6.3% wird dieser Header gesetzt. Die Verbreitung ist somit eher gering. Bei 93.7% wird der Header implizit auf strict-origin-when-cross-origin}gesetzt, was gut aber nicht ideal ist.

Knapp ein Drittel (32.7%) der explizit gesetzten Werte sind sicher. 55.2% sind nicht ideal und 12.1% sind unsicher gesetzt.

Strict-Transport-Security (HSTS)

Empfehlung: Dieser Header sollte immer gesetzt werden.

Die Empfehlung für den max-age-Wert liegt bei 2 Jahren (63’072’000s). Nach Möglichkeit sollte das preload Flag auch gesetzt werden. Fehlerhafte Einstellungen dieses Headers können dazu führen, dass der Browser den Zugriff auf die Domain blockiert.

Der Strict-Transport-Security Header informiert den Browser darüber, dass der Zugriff auf die Website nur über HTTPS erfolgen sollte und dass alle künftigen Zugriffsversuche über HTTP automatisch auf HTTPS umgestellt werden sollten.

Bei 33% aller Antworten ist dieser Header gesetzt. Im Vergleich zu anderen Headern ist dies ein hoher Wert.

Alle Werte, die bei diesem Header gesetzt werden können, machen die Verbindung sicherer, ausser max-age=0, welcher den HSTS-Mechanismus deaktiviert. Bei 77% war max-age gesetzt, dadurch verwendet der Browser für die angegebene Zeit nur HTTPS. Bei 16% waren zusätzlich Subdomains angegeben, für die ebenfalls nur noch HTTPS verwendet werden soll. Bei 7% war zudem noch preload aktiviert.

51.9% der max-age-Werte sind kleiner oder gleich 6 Monate, was keiner Empfehlung entspricht. Solche tiefen Werte sollten nur während der Einführung des HSTS Headers verwendet werden.

X-Content-Type-Options

Empfehlung: Der Content-Type Header sollte stets korrekt gesetzt werden. Der X-Content-Type-Options Header sollte immer auf nosniff gesetzt sein.

Dadurch wird MIME-Typ-Sniffing überflüssig und potenzielle Missverständnisse oder Sicherheitsrisiken werden vermieden.

Der Antwort-Header X-Content-Type-Options gibt an, dass die in den Content-Type Headern angegebenen MIME-Typen respektiert und nicht verändert werden. Mit diesem Header kann das MIME-Typ-Sniffing deaktiviert werden.

Bei 18.1% der Antworten ist dieser Wert gesetzt. Im Vergleich zu anderen Headern ist dies ein eher hoher Wert. Da nur nosniff gesetzt werden kann wurde auf eine detaillierte Auswertung verzichtet. 306 Domains / Subdomains verwenden einen ungültigen Wert (Syntax-Error).

X-DNS-Prefetch-Control

Empfehlung: Das DNS-Prefetching sollte, um Informationslecks vorzubeugen, deaktiviert werden.

Bei Webapplikationen sollte zugunsten der Sicherheit ein möglicher Performance-Einfluss in Kauf genommen werden. Für reguläre Webseiten mit statischen Inhalten kann hingegen der Performance-Vorteil genutzt werden.

Der X-DNS-Prefetch-Control Header konfiguriert das DNS-Prefetching, eine Funktion, mit der Browser proaktiv die Auflösung von Domänennamen durchführen, um die Lade-Geschwindigkeit für den Benutzer zu verbessern. Dies ist kein Standard-Header, dennoch wird er von den meisten Browsern (ausser Safari) unterstützt.

Gerade einmal 0.3% verwenden diesen Header. 13 Domains weisen eine fehlerhafte Syntax auf.

Bei 52% ist der Wert auf off gestellt, 48% setzen den Wert auf on. Bei Webapplikationen gilt der Wert on als unsicher, da über DNS-Anfragen Rückschlüsse gemacht werden können.