In den letzten Jahren erhielten Webbrowser immer mehr Funktionen und aus traditionellen Anwendungen wurden Webanwendungen. Die Entwicklung von Browsern erfolgt in raschen Zyklen, so ist Google Chrome bei Version 87, Mozilla Firefox bei Version 83, Microsoft Edge bei Version 87 und Microsoft verwendet nun die Chromium Engine. Der Microsoft Internet Explorer (IE) verbleibt bei Version 11 und wird nur noch spärlich weiterentwickelt. Jedoch wird der IE vor allem in Unternehmen noch eingesetzt. Als Folge dessen müssen Webanwendungen ein breites Feld mit unterschiedlichen Versionen unterstützen. Das gilt sowohl für die Bedienung als auch für die Sicherheit der Webanwendungen. Ein Bestandteil von Sicherheitsmassnahmen sind die HTTP Response Header.

Ein Response Header kann durch die Webanwendung selbst, oder durch die Konfiguration des Webservers gesetzt werden. Die Konfiguration erfolgt dabei nicht in jedem Fall durch die Entwickler, so dass eine Abstimmung zwischen der Konfiguration und der Entwicklung der Anwendung notwendig ist. Im Artikel HSTS Preload als Angriffsvektor setzte sich Marc Ruef damit auseinander, dass der Header Strict-Transport-Security übergreifenden Einfluss auf weitere Dienste haben kann, als nur die HTTPS-Sicherheitsrichtline der Webanwendung zu steuern. Das Response Header nicht nur für Sicherheit sorgen können, sondern bei einer fehlerhaften Konfiguration auch Einfluss auf den Betrieb haben, beschrieb Stefan Friedli im Artikel zu HTTP Strict Transport Security.

Wir haben bereits einige Beiträge über sicherheitsrelevante Response Header geschrieben. Veit Hailperin stellte im Januar 2016 mit dem Artikel Inglorious Headers diverse Header vor, Michael Schneider erklärte die Anwendung der Content Security Policy im August 2016, Andrea Hauser beschrieb Sicherheitsmassnahmen im Artikel Response Header Hardening im März 2018 und Michael Schneider stellte neue Header im Artikel Die Fortsetzung der HTTP-Header-Saga im August 2018 vor. Seither sind mehr als zwei Jahre vergangen, daher betrachten wir den aktuellen Stand der Entwicklung und stellen eingeführte Änderungen sowie Pläne für die Zukunft der Response Header vor.

Expect-CT

Der Header Expect-CT signalisiert, dass die Webseite den Standard Certificate Transparency (CT) unterstützt. Der Browser wird aufgefordert jedes Zertifikat der Webseite in den öffentlichen CT-Logs zu prüfen. Der Header wird unterstützt ab Edge 79 und Chrome 61, der Status in Firefox ist nicht dokumentiert.

Dieser Header wird ab Juni 2021 obsolet, da ab Mai 2018 neu ausgestellte Zertifikate über die Unterstützung von Signed Certificate Timestamps (SCT) verfügen sollten. Zertifikate, die vor März 2018 ausgestellt wurden, haben eine maximale Laufzeit von 39 Monaten, welche dementsprechend im Juni 2021 auslaufen.

X-Frame-Options

Der Header X-Frame-Options deklariert, ob eine Webseite in einem Frame oder Objekt gerendert werden darf. Der Header wird durch die Direktive frame-ancestors der Content-Security-Policy abgelöst. Da der Header Content-Security-Policy jedoch durch Microsoft Internet Explorer partiell unterstützt wird, muss der Header X-Frame-Options solange gesetzt werden, wie der Internet Explorer noch verwendet wird. Daher muss dieser Header weiterhin parallel zur Content-Security-Policy gesetzt werden.

Content-Security-Policy

Der Header Content-Security-Policy findet breite Anwendung und wird von allen modernen Browsern unterstützt. Bei Web Application Penetration Tests beobachten wir meist eine “zweistufige” Entwicklung. Zuerst wird der CSP-Header mit einer offenen Direktive gesetzt. Meistens erlaubt die Direktive script-src noch unsafe-inline und unsafe-eval. Erst in der nächsten Stufe ist die Webseite soweit, dass eine restriktive Direktive eingesetzt werden kann.

Zukünftig wird die Direktive report-uri durch report-to abgelöst. Derzeit wird report-to aber erst in Chrome und Edge unterstützt. Vorgesehen ist, dass sobald report-to in den meisten Browsern implementiert ist, die Direktive report-uri durch den Browser ignoriert wird. Damit report-to genutzt werden kann, muss ein sogenannter Endpoint definiert werden, dies geschieht über die Reporting API.

Reporting API

Die Reporting API, spezifiziert im W3C Working Draft vom 25. September 2018, definiert den Header Reports-To, mit jenem ein oder mehrere Endpoints definiert werden. Auf die definierten Endpoints wird dann mittels der CSP-Direktive report-to verwiesen. Die Definition eines Endpoints erfolgt im JSON-Format und sieht folgendermassen aus:

Report-To: {"group":"default","max_age":10886400,"endpoints":[{"url":"https://example.com/reports","priority":1},{"url":"https://backup.example.com/reports","priority":2}]}

Das JSON-Format ist in dieser Form nur schwer von Auge zu lesen, in einer formatierten Ausgabe sieht der Inhalt wie folgt aus:

Report-To: { "group": "csp",
  "max_age": 10886400,
  "endpoints": [
    { "url": "https://example.com/reports", "priority": 1 },
    { "url": "https://backup.example.com/reports", "priority": 2 }
  ] }

Durch die Anweisung max_age speichert der Browser die Endpoint-Konfiguration über die vorgegebene Zeit und verwendet die Liste der Endpoints um Reports an diese URLs zu senden.

Im Editor’s Draft zur Reporting API vom 19. Oktober 2020 wurde der Header Report-To jedoch bereits mit dem Header Reporting-Endpoints ersetzt. Dieser Header verwendet das Structured-Header-Format (SH) und wurde in der Konfiguration vereinfacht. Für jeden Endpoint muss nur noch ein Name und eine URL definiert werden. Der Header wird so gesetzt:

Reporting-Endpoints: csp="https://example.com/reports"

Da in Chrome bereits der Header Report-To implementiert wurde, sind beide Header noch gültig. Zukünftig soll nur noch der Header Reporting-Endpoints verwendet werden.

Origin-Policy

Der Web-Plattform-Mechanismus Origin-Policy hat das Ziel eine origin-weite Konfiguration zu verwenden, anstelle diese pro HTTP Response in mehreren Headern zu kommunizieren. Der Draft Community Group Report vom 8. Juni 2020 enthält mehrere Änderungen gegenüber dem Stand von vor zwei Jahren im Artikel Fortsetzung der HTTP-Header-Saga. So wird unter anderem der Header Sec-Origin-Policy nicht mehr verwendet, sondern nur noch Origin-Policy. Im Wert dieses Headers wird spezifiziert, welche Policy für die Origin gültig ist:

Origin-Policy: allowed=("example-1")

Die Policy wird über die URL https://example.com/.well-known/origin-policy als JSON-Datei bereitgestellt:

{
  "ids": ["example-1"],
  "content_security": {
    "policies": ["default-src 'none'; connect-src 'self'; img-src 'self'; style-src 'self'; frame-ancestors 'none';"]
  }
}

Bei Origin-Policy handelt es sich erst um einen Vorschlag, der noch in keinem Browser unterstützt wird.

Feature-Policy

Der Header Feature-Policy wird ab Chrome 74 und Edge 79 vollständig unterstützt; eine partielle Unterstützung ist in Firefox ab Version 74 vorhanden. Zirka zwei Jahre nach Einführung des Headers wird dieser bereits durch den Header Permissions-Policy abgelöst. Der Security-Researcher Scott Helme hatte sich im Artikel Goodbye Feature Policy and hello Permissions Policy! mit der Ablösung auseinandergesetzt.

Die Direktive des Headers hat Ähnlichkeiten zum Header Content-Security-Policy und sieht so aus:

Feature-Policy: camera 'none'; microphone 'none'; geolocation 'none'; speaker 'self'

Permissions-Policy

Der Nachfolger des Headers Feature-Policy heisst Permissions-Policy und wird zurzeit nur ab Chrome 86 experimentell unterstützt. Der Header wird im Editor’s Draft vom 29. September 2020 spezifiziert.

Das Format der Direktive ist anders als beim Feature-Policy Header, daher reicht es bei einer Umstellung nicht aus den Header umzubenennen. Im Format des neuen Headers sieht das vorherige Beispiel folgendermassen aus:

Permissions-Policy: camera=(), microphone=(), geolocation=(), speaker=(self)

Bis der Header Permissions-Policy in den meistverbreiteten Browsern implementiert ist, wird ein Parallelbetrieb der beiden Header notwendig.

Fazit

Die Entwicklung der Response Header wurde in den letzten zwei Jahren mit einer rasanten Geschwindigkeit vorangetrieben. In den Browsern wird die Unterstützung von Headern bereits implementiert, obwohl der Standardisierungsprozess des Headers noch in Entwicklung ist. Dies führt dazu, dass es mehrere gültige Schreibweisen und Formate gibt, und alle entsprechend abgedeckt werden müssen. So muss zum Beispiel für den Internet Explorer 11 die Content-Security-Policy auch mit dem Header X-Content-Security-Policy gesetzt werden.

Der Verlauf der Entwicklung des Header Feature-Policy mit einer Umbenennung und der Änderung der Syntax zum Header Permissions-Policy innerhalb von zwei Jahren ist ebenfalls ein Beispiel dafür, was passieren kann, wenn Header vorschnell implementiert und genutzt werden. Meiner Meinung nach ist die neue Syntax komplexer, weicht von der Deklarationsform anderer Header ab und die parallele Unterstützung von zwei Headern mit unterschiedlichen Formaten für den gleichen Zweck wird der Adaption des Headers und somit auch der Sicherheit mehr schaden als nützen.

Ich wünsche mir, dass durch eine bedachtere Ausarbeitung der Standards und mit Einbezug aller Browser-Hersteller beim Entwurf und der Entwicklung von HTTP Response Header mehr Stabilität einkehrt. Dadurch erhoffe ich mir eine grössere Abdeckung im Einsatz dieser sicherheitsrelevanten Header. Denn momentan beobachten wir eine zögerliche Nutzung der Header, und die Änderungspolitik wie im Falle der Feature-Policy wird dies nicht beschleunigen. Ich hoffe, dass die Einführung der Origin-Policy das Setzen von Response Header vereinfachen wird, und dadurch die Konfiguration aller Header an einer Stelle möglich sein wird. Damit am Ende mehr sicherheitsrelevante Header eingesetzt werden und die Sicherheit von Webanwendungen erhöht wird.

Über den Autor

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• https://caniuse.com/feature-policy
• https://caniuse.com/mdn-http_headers_csp_content-security-policy
• https://caniuse.com/mdn-http_headers_expect-ct
• https://caniuse.com/permissions-policy
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Feature_Policy
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expect-CT
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
• https://scotthelme.co.uk/
• https://scotthelme.co.uk/goodbye-feature-policy-and-hello-permissions-policy/
• https://w3c.github.io/reporting
• https://w3c.github.io/webappsec-permissions-policy/
• https://wicg.github.io/origin-policy/
• https://www.certificate-transparency.org
• https://www.certificate-transparency.org/known-logs
• https://www.w3.org/TR/reporting-1/