Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03424.jsonl.gz/317

HardeningKitty Score
Michael Schneider
Diese neuen HTTP Security Header müssen Sie kennen
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.
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.
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.
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.
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.
Unsere Spezialisten kontaktieren Sie gern!
Michael Schneider
Michael Schneider
Michael Schneider
Unsere Spezialisten kontaktieren Sie gern!
Weitere Artikel im Archiv