Fortsetzung der HTTP-Header-Saga - Erweiterte Sicherheitsmöglichkeiten

Fortsetzung der HTTP-Header-Saga

Erweiterte Sicherheitsmöglichkeiten

Michael Schneider
von Michael Schneider
am 09. August 2018
Lesezeit: 11 Minuten

Keypoints

Diese neuen HTTP Security Header müssen Sie kennen

  • Subresource Integrity schützt vor Veränderung von eingebetteten Objekten von Drittparteien
  • Feature Policy ermöglicht die Kontrolle von Browser-Features
  • Origin Policy bietet eine zentrale Verwaltung von HTTP-Headern
  • Applikationen können voneinander unter demselben Origin durch Suborigins isoliert werden

Im Artikel Response Header Hardening hat sich Andrea Hauser mit dem Hardening von HTTP-Headern auseinandergesetzt. Die Entwicklung von HTTP-Headern sowie der Browser- und Web-Applikations-Sicherheit geht stetig weiter. Auf neue Funktionen werden auch entsprechende Kontrollmöglichkeiten eingeführt. In diesem Labs stellen wir aktuelle Techniken vor, die künftig zum Repertoire der Web-Applikation-Sicherheit gehören.

Subresource Integrity

Subresource Integrity (SRI) ist zwar kein HTTP-Header, trägt jedoch auch zum Schutz der Web-Applikation bei. Viele Applikationen nutzen heutzutage Inhalte von Content Delivery Networks (CDN), meistens in Form von JavaScript- oder CSS-Bibliotheken. Diese werden direkt von CDNs in die eigene Seite eingebunden, um von deren Erreichbarkeit und performanten Anbindung zu profitieren sowie um Bandbreite zu sparen. Die Bibliothek wird in die Web-Applikation eingebunden, ohne dass verifiziert wird, ob es sich überhaupt um den gewünschten Inhalt handelt. Es wäre aber möglich, dass eine solche Bibliothek verändert oder gar komplett ersetzt worden ist. SRI schafft hier Abhilfe.

Die aktuelle Version der Spezifikation von Subresource Integrity wurde am 23. Juni 2016 von den Verfassern Devdatta Akhawe (Engineer bei Dropbox), Frederik Braun (Senior Security Engineer bei Mozilla), François Marier (Software Developer bei Mozilla) und Joel Weinberger (mittlerweile Security Engineer bei Snap, vorher Software Engineer bei Google), als W3C Recommendation veröffentlicht. Durch die Verwendung von SRI erhält der Browser die Anweisung eine Integritätsprüfung der zu ladenden Datei einer Drittpartei durchzuführen.

Dabei wird bei der Verwendung der HTML-Tags script und link der Base64-kodierte Hash der gewünschten Datei im Attribut integrity hinterlegt. Wenn die Überprüfung des Hash-Werts erfolgreich ist, wird die Datei durch den Browser geladen. Ansonsten wird das Laden abgebrochen. Der Security Researcher Scott Helme hat ein Tool geschrieben, um SRI-Hashes zu generieren. Ein Beispiel für das Einbinden der Bibliothek jQuery sieht folgendermassen aus:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8= sha384-tsQFqpEReu7ZLhBV2VZlAu7zcOV+rXbYlF2cqB8txI/8aZajjp4Bqd+V6D5IgvKT sha512-+NqPlbbtM1QqiK8ZAo4Yrj2c4lNQoGv8P79DPtKzj++l5jnN39rHA/xsqn8zE9l0uSoxaCdrOgFs6yjyfbBxSg==" crossorigin="anonymous"></script>

Wie das Beispiel zeigt, können mehrere Hash-Algorithmen verwendet werden. Der Browser wählt dabei immer den stärksten Algorithmus. SRI wird von den Browsern Microsoft Edge, Mozilla Firefox, Google Chrome und Safari bereits unterstützt.

Feature Policy

Der HTTP-Header Feature Policy ist ein Vorschlag von Ian Clelland (Software Engineer bei Google) zur Verwaltung von Browser-Features und -APIs durch Webseiten. Durch das Setzen des Headers kann eine Seite kontrollieren, welche Features wie genutzt werden können. Auf GitHub wurde die Liste der durch die Policy kontrollierten Browser-Features veröffentlicht.

Die Definition von Feature Policy hat Ähnlichkeiten zum Header Content Security Policy. In der Header-Direktive werden Restriktionen für die einzelnen Features spezifiziert und von welchem Origin auf diese zugegriffen werden können. Die Browser-Default-Einstellung für die meisten der Features ist self. Die untenstehende Direktive verbietet zum Beispiel die Nutzung von camera, microphone und geolocation, erlaubt die Nutzung von speaker nur für den eigenen Kontext und fullscreen für alle Origins.

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

Es ist aber auch vorgesehen innerhalb von einzelnen Elementen die Policy für die eigene Seite zu übersteuern. Wenn auf der Seite ein iframe genutzt wird, kann für den Inhalt im iframe die Nutzung von geolocation aktiviert werden:

<iframe src="https://example.com" allow="geolocation">

Der Header Feature Policy wird im Juli 2018 von Google Chrome und Safari unterstützt.

Origin Policy

Mike West (Engineer bei Google) hat mit dem Entwurf der Origin Policy am 30. Mai 2017 einen Vorschlag definiert, wie die Handhabung vieler sicherheitsrelevanter Header vereinfacht werden kann. Bisher ist es so, dass verschiedene Header wie Strict-Transport-Security oder Content Security Policy für jede einzelne Ressourcen einer Web-Applikation gesetzt und ausgeliefert werden müssen. Die Regeln gelten dann für den ganzen Origin einer Web-Applikation. Das heisst mit jeder Response werden Kilobytes an Header-Information gesendet, die sich immer und immer wiederholen. Zudem müssen die Header für alle Ressourcen gesendet werden, damit deren Einstellungen für die jeweilige Ressource auch gültig sind. Oftmals werden unter anderem bei 404-Fehlerseiten nicht alle Policies im Response-Header gesetzt.

Der Vorschlag von Mike sieht vor, dass über den Header Sec-Origin-Policy definiert wird, welche Policy für die Seite gilt. Der Client fragt zu Beginn in einem Request mittels des Headers Sec-Origin-Policy: 1 die Policy an. Der Server antwortet darauf mittels des Headers Sec-Origin-Policy: "policy-1" und teilt mit, welche Policy gültig ist. Daraufhin ruft der Client die URL https://example.com/.well-known/origin-policy/policy-1 auf, bevor er mit dem Öffnen der eigentlichen Webseite fortfährt. Die Policy wird vom Client zwischengespeichert und gilt fortan für die ganze Seite. Eine solche Policy kann wie folgt aussehen:

{
  "headers": [
    {
      "name": "Content-Security-Policy",
      "value": "default-src 'none'; connect-src 'self'; img-src 'self'; style-src 'self'; frame-ancestors 'none';",
      "type": "baseline"
    },
    {
      "name": "Referrer-Policy",
      "value": "strict-origin-when-cross-origin",
      "type": "fallback"
    }
    {
      "name": "Strict-Transport-Security",
      "value": "max-age=63072000; includeSubDomains; preload",
      "type": "baseline"
    },
    {
      "name": "X-Content-Type-Options",
      "value": "nosniff",
      "type": "baseline"
    }
  ],
  "cors-preflight": {
    "origins": "*"
  }
}

Wenn zu einem späteren Zeitpunkt die Policy geändert werden soll, wird dies durch eine Anpassung des Headers Sec-Origin-Policy: "policy-2" an den Client kommuniziert. Dieser aktualisiert entsprechend die bereits gespeicherte Policy. Falls die Policy komplett gelöscht werden soll, wird der Header auf Sec-Origin-Policy: 0 gesetzt. Der Client löscht dann die Information im Cache, aber bestimmte Einstellungen, unter anderem die Strict-Transport-Security-Einstellungen, bleiben solange weiter in Kraft, bis die definierte Zeit (max-age) abgelaufen ist.

Suborigins

Die Spezifikation für Suborigins wurde von Devdatta Akhawe und Joel Weinberger (beide bekannt für den Entwurf von Subresource Integrity) sowie Jochen Eisinger (Software Engineer bei Google) verfasst und am 18. Mai 2017 veröffentlicht. Mit der Spezifikation können verschiedene Applikationen, welche unter demselben physischen Origin laufen, voneinander isoliert werden. Suborigins ermöglicht es, einen Namespace per HTTP-Header zu definieren, der mit dem Origin-Tupel Schema/, Host und Port (http://example.com:80) gepaart wird.

So werden die Applikationen https://example.com/shop und https://example.com/blog innerhalb des physischen Origins example.com betrieben, auch wenn es unterschiedliche Applikation sind. Daher kann sich eine XSS-Schwachstelle unter https://example.com/blog auch auf https://example.com/shop auswirken – auch dann wenn https://example.com/shop durch eine restriktive Content Security Policy geschützt ist. Suborigins bietet nun die Möglichkeit solche Applikationen voneinander aufzusplitten ohne verschiedene physische Origins nutzen zu müssen, wie zum Beispiel shop.example.com und blog.example.com.

Für Suborigins gibt es die folgenden Anwendungszwecke:

Die Spezifikation für Suborigins ist zwar noch im Draft-Status, es hat aber grosses Potential die Sicherheit von Web-Applikationen durch Isolierung weiter zu verbessern.

Fazit

Die vorgestellten Technologien sind zurzeit noch nicht alle nutzbar, da diese noch im Draft-Status sind, und somit noch nicht von allen Browsern unterstützt werden. Nichtsdestotrotz lohnt es sich bereits heute sich mit diesen neuen Möglichkeiten auseinanderzusetzen und ihre Implementierung zu planen. So werden auch wir diese in unseren Testkatalog für Penetration Tests aufnehmen und unseren Kunden deren Nutzen entsprechend näherbringen.

Über den Autor

Michael Schneider

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 geschrieber Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

Haben Sie Interesse an einem Penetration Test?

Unsere Spezialisten kontaktieren Sie gern!

×
HardeningKitty

HardeningKitty

Michael Schneider

KleptoKitty

KleptoKitty

Michael Schneider

Linux Hardening

Linux Hardening

Michael Schneider

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv