Bringt Browser Isolation mehr Sicherheit?

Mitte Oktober 2020 stellte Cloudflare ein neues Browser Isolation as a Service Angebot vor. Ich möchte die Gelegenheit nutzen, um aufzuzeigen, aus welcher Perspektive ich solche Angebote betrachte, prüfe und wie ich letztendlich auch berate. Dazu stelle ich zunächst die Motivation hinter Browser Isolation vor. Im folgenden Abschnitt gehe ich auf die Sicherheitsrisiken im Browser-Umfeld ein, um im dritten Kapitel auf den möglichen Nutzen von Browser Isolation einzugehen. Kurz Angebundene können direkt zum abschließenden Fazit springen.

Motivation

Meine Anfänge in der Web-Entwicklung gehen ziemlich genau in die Zeit zwischen dem ersten iPhone und dem späteren Start des Apple App Store zurück. Damals war die größte Herausforderung noch der Internet Explorer und seine eigenwillige Interpretation der Standards. Media Queries wurden von keinem Browser unterstützt. An Responsive Webdesign war entsprechend nicht zu denken. Service Worker und Progressive Web Apps waren absolute Zukunftsmusik. Heute sieht dies völlig anders aus und die Frage, ob wir auf unseren Endgeräten mehr als einen Browser brauchen, stellt sich an einigen Stellen bereits und wird in Zukunft immer häufiger gestellt werden. Der Funktionsumfang unserer Browser ist deutlich gestiegen. Damit einher auch die Komplexität, sodass Browser inzwischen ein relevantes Sicherheitsrisiko darstellen. Browser Isolation versucht dieses Risiko durch eine weitere Isolationsschicht zu begrenzen. Solche Barrieren begrenzen den Blast Radius von Sicherheitslücken und sind damit grundlegend zu begrüßen. Für eine tiefer gehende Kosten-Nutzen-Analyse braucht es zunächst jedoch einen Überblick, welche Arten von Sicherheitslücken im Browserumfeld zu erwarten sind.

Sicherheitsrisiken im Umfeld des Browsers

Ich werde an dieser Stelle auf vier verschiedene Ebenen, aus denen sich jeweils Sicherheitsvorfälle ergeben können, eingehen. Diese Liste ist nicht vollständig und lediglich ausreichend für den Fokus dieses Beitrages.

Cross-Site Risiken

Keine NutzerIn würde einen Browser nutzen, wenn sie bei jedem Klick ihre Zugangsdaten eingeben müsste. Aus diesem Grund besitzt jede moderne Webseite mit Benutzerauthentifizierung einen Log-In-Dialog. Hat sich die NutzerIn erfolgreich authentifiziert, wird ein temporärer Sitzungsschlüssel erzeugt und vom Browser mit jeder Anfrage mitgeschickt. Von den vollständigen Log-in-Daten unterscheidet sich dieser Schlüssel nur insofern, dass er nach einer gewissen Zeit ungültig wird.

In diesem Zusammenhang sind vor allem XSS- und CSRF-Angriffe relevant. Ein Angreifer kann dabei entweder entsprechende Sitzungsschlüssel extrahieren oder ohne Wissen der NutzerIn eine Anfrage initiieren. Bei Letzterem schickte der Browser entsprechend der Spezifikation den Sitzungsschlüssel mit. Der Angreifer kann damit ohne Wissen der NutzerIn in ihrem Namen handeln.

Berechtigung des Browsers

Heutige Browser benötigen weitreichenden Zugriff auf das System der NutzerIn. Angefangen beim Dateisystem über Mikrofon und Kamera bis hin zum Standort. Über Plugins lässt sich dies beliebig erweitern. Normalerweise kümmert sich der Browser darum, diesen Zugriff nur berechtigten Webseiten zur Verfügung zu stellen. In diesem Berechtigungsmanagement kann es jedoch Lücken geben. Genauso kann es in anderen Teilen des Browsers Lücken geben, wodurch eine geschickt präparierte Webseite den Browser in einen ungeplanten Zustand versetzen kann. Dies kann womöglich wiederum dazu genutzt werden, die Berechtigungen des Browsers zu missbrauchen. Gleiches gilt für Plug-ins.

Meistens ist es jedoch viel einfacher. Das Herunterladen einer infizierten Datei ist häufig der erste Schritt. Macht der Angreifer die NutzerIn noch heiß auf den Inhalt, ist das Öffnen als zweitem Schritt schnell getan. Der Browser ist in diesem Szenario lediglich das Vehikel, weist selber jedoch keine Sicherheitslücke auf.

Berechtigung anderer Anwendungen

Haben andere Anwendungen entsprechende Zugriffsrechte auf dem System, können sich daraus auch entsprechende Sicherheitsrisiken ergeben. Ähnlich zur ersten Ebene kann entsprechende Software womöglich sensitive Daten auslesen. Mit direktem Zugriff auf die Dateien und Datenbank des Browsers kann das Berechtigungsmanagement des Browsers zum Teil umgangen werden.

Genauso ist es unter Umständen möglich, ohne Wissen der NutzerIn zusätzliche Plug-ins zu installieren oder Einstellungen zu verändern. Mit entsprechender Berechtigung kann auch der Browser selbst manipuliert werden. Was für die NutzerIn aussieht wie Chrome oder ein anderer Browser, muss nicht Chrome oder ein anderer Browser sein.

Netzwerk

Man-in-the-Middle-Angriffe führen an dieser Stelle zu weit. Das Netzwerk ist trotzdem wichtig zu betrachten. Der Browser läuft auf dem Endgerät der NutzerIn und damit womöglich in einem firmeninternen, privaten oder anderweitig schützenswerten Netzwerk.

Über Javascript kann eine Webseite im Hintergrund weitere Anfragen starten. Da dies clientseitig geschieht, kommen diese Anfragen netzwerktechnisch vom Gerät der NutzerIn und haben die entsprechenden Berechtigungen. Unter Umständen wird dabei, wie auf der ersten Ebene, ein Sitzungsschlüssel mitgeschickt. Ist das Netzwerk lediglich durch eine Firewall am Gateway geschützt, ist diese in diesem Fall nutzlos.

Nutzen von Browser Isolation

In diesem Abschnitt gehe ich noch einmal auf die vier Ebenen aus dem letzten Abschnitt ein und zeige, welchen Nutzen Browser Isolation jeweils bietet.

Cross-Site Risiken sind vor allem serverseitig

Klassische XSS-Lücken entstehen, wenn Eingaben von BenutzerInnen unzureichend validiert und ungeprüft ausgegeben werden. CSRF-Lücken können die Folge sein oder aber auch durch einen fehlerhaften CORS-Header verursacht werden. Dies ist eine Fehlkonfiguration des Servers.

Einen gewissen Schutz bietet das Abschalten von Javascript. Damit wird allerdings so viel Funktionalität deaktiviert, dass heutige Webanwendungen nicht mehr benutzt werden können.

In dieser Hinsicht ist ein isolierter Browser weiterhin ein Browser. Einen Schutz gegen diese Art von Lücken kann Browser Isolation nicht bieten.

Berechtigungen des Browsers

Auf dieser Ebene wird es spannend. Eine Isolation des Browsers nimmt diesem bestimmte Berechtigungen. Die spannende Frage ist, wie weit man dabei geht. Je mehr Berechtigungen man dem Browser verweigert, desto sicherer wird es. Gleichzeitig leiden aber Benutzerfreundlichkeit und Funktionsumfang. Ein Browser ohne Zugriff auf Kamera & Mikrofon ist beispielsweise für Videokonferenzen nicht mehr geeignet.

Ein Mittelweg sind Proxy-Prozesse. Dabei erfolgt der Zugriff des Browsers beispielsweise auf die Kamera über einen isolierten Prozess mit minimaler Schnittstelle. Dieser Proxy kann den Benutzer jedes Mal fragen, ob er den Zugriff auf die Kamera gestatten möchte. Durch die Isolation zwischen Browser und Proxy reicht es nicht mehr aus, eine Sicherheitslücke im Browser zu finden und damit das Berechtigungsmanagement zu umgehen. Es muss auch noch der Proxy überwunden werden, welcher durch die Isolation und die minimale Schnittstelle ein sehr geringes Angriffspotenzial bietet.

Spätestens beim Dateisystemzugriff sind aber auch hier Grenzen gesetzt. Der Schaden, den eine heruntergeladene Datei anrichten kann, hängt vor allem von der Anwendung ab, mit der sie geöffnet wird. Im Falle von ausführbaren Dateien ist der Benutzer die (psychologische) Sicherheitslücke. In anderen Fällen besteht die Sicherheitslücke in der Anwendung mit der die “schädliche” Datei geöffnet wird. Das Sicherheitsrisiko ist damit an der Schnittstelle zwischen Browser und Dateisystem nicht erfassbar. Während es für die meisten NutzerInnen noch praktikabel ist, das Downloaden ausführbarer Dateien zu verbieten, fehlen in allen anderen Fällen Kontextinformationen. Es gibt jeden Tag neue Dateiformate. Entsprechend aussichtslos ist es, alle validieren zu wollen. Nur weil eine Datei der Spezifikation entspricht, heißt das auch noch lange nicht, dass sie kein Sicherheitsrisiko darstellt. Ein Programm kann genauso die Spezifikation fehlerhaft implementieren und damit von einer validen Datei in einen sicherheitskritischen Zustand versetzt werden.

Virenscanner helfen an dieser Stelle nicht weiter. Diese können maximal bekannte Schadprogramme und Muster erkennen. Gegen diese ist ein funktionierendes Patchmanagement allerdings die bessere Waffe. Zumal Virenscanner, aufgrund ihrer Komplexität und den teils umfangreichen Berechtigungen ebenfalls eine nicht zu unterschätzende Angriffsoberfläche darstellen. Entscheiden sind vor allem sogenannte Zero-Day-Exploits, also Sicherheitslücken, welche bisher unbekannt waren und es daher keine gezielten Gegenmaßnahmen gibt. Gegen diese helfen weder Virenscanner noch Patchmanagement.

Die Isolation des Browsers kann in Bezug auf seine Berechtigungen einen Sicherheitsvorteil bieten. Der Umfang hängt von der konkreten Umsetzung ab und ist durch die Anforderungen an die Funktionalität des Browsers begrenzt. Die Isolation des Browsers allein bietet in dieser Hinsicht im Allgemeinen kein ausreichendes Sicherheitsniveau.

Berechtigung anderer Anwendungen

Die Isolation des Browsers sollte anderen Anwendungen den Zugriff auf den Browser verbieten. Alles andere ist in der Regel eine Fehlplanung. Sollte es anderen Anwendungen möglich sein, dies zu umgehen, ist dies im Allgemeinen ein Implementationsfehler. Insofern kann die Browser Isolation diese Art von Sicherheitsrisiken verhindern.

Netzwerk

Welchen Einfluss die Isolation des Browsers aus netzwerktechnischer Sicht hat, hängt von der Implementation ab. Findet die Isolation auf dem Endgerät der BenutzerIn statt, ändert sich aus netzwerktechnischer Sicht nichts. Natürlich kann an der Isolationsbarriere eine weitere Firewall installiert werden. Wie hilfreich dies ist, kommt auf die Berechtigungen auf dem Endgerät an. Vonseiten des Netzwerks kann die korrekte Funktion dieser Firewall allerdings nicht überprüft werden. Es kann sich ein leichter Sicherheitsnutzen ergeben, allerdings auch ein falsches Sicherheitsgefühl. Alleinstehend ist solch eine Firewall auf jeden Fall unzureichend.

Läuft der isolierte Browser in einem anderen Netzwerk, wird die Angelegenheit komplizierter. Benötigen NutzerInnen Zugriff auf interne Anwendungen, müssen die entsprechenden Netze verbunden werden. Dies erfordert eine ganz eigene Sicherheitsbetrachtung. Haben in diesem Zusammenhang weitere Akteure Zugriff auf isolierte Browser im gleichen Netzwerk, kann dies einer Öffnung interner Netze für externe Akteure gleichkommen. Die Isolation von Netzwerken allein ist zwar in der Regel keine ausreichende Sicherheitsmaßnahme, muss aber trotzdem nicht ohne Not untergraben werden.

Läuft der Browser nicht mehr auf dem Endgerät der NutzerIn, verändern sich auch die Anforderungen an das Netzwerk. Mit Browser - egal in welcher Form - auf dem Endgerät ist die Bandbreite zwischen Server und Endgerät der entscheidende Faktor für die Nutzbarkeit. Relevant ist, wie schnell die notwendigen Daten zum Endgerät kommen. Sind sie einmal da, ist die Latenz auf heutigen Endgeräten vernachlässigbar. Der Einfachheit halber kann Latenz in diesem Zusammenhang als Reaktionsgeschwindigkeit umschrieben werden.

Läuft der Browser nun auf einem externen Gerät, ist weiterhin die Bandbreite zwischen Server und Browser relevant, nun aber auch die Latenz zwischen Browser und Endgerät. Tätigt die NutzerIn eine Eingabe, muss diese zunächst an den Browser gesendet werden. Von dort müssen die notwendigen Befehle zur Darstellung wieder an das Endgerät gesendet werden. Die Latenz steigt sowohl mit der Entfernung als auch mit jeder Umwandlung des Signals. Auch kleinere Störungen, welche natürlicherweise vorkommen und in der Regel nicht auffallen, weil sie automatisch korrigiert werden, steigern die Latenz.

Weiterhin sollte die Resilienz gegen Teilausfälle von Netzwerken betrachtet werden. Ist der eigene DSL-Anschluss gestört, bleibt ein “intern” isolierter Browser erreichbar. Interne Anwendungen können somit weiter genutzt werden. Bei externem Hosting des Browsers sind zwar interne Anwendungen weiterhin erreichbar, können aber aufgrund der Nicht-Erreichbarkeit des Browsers nicht genutzt werden.

Eine Isolation des Browsers auf dem Endgerät ist netzwerktechnisch nicht sichtbar. Ein Hosting in direkter Nähe des Endgerätes, also mindestens im selben Gebäude, schafft unter Umständen einen gewissen Sicherheitsnutzen. Alles andere führt netzwerktechnisch meist zu mehr Probleme als Nutzen.

Fazit

Die Isolation einzelner Komponenten und Prozesse ist ein wichtiger und viel zu selten umgesetzter Sicherheitsmechanismus. Gleichzeitig löst Isolation keine grundlegenden Sicherheitsprobleme, sondern kann maximal den Blast radius begrenzen.

Dies gilt auch und insbesondere im Umfeld eines Web-Browsers, wobei es hierbei sehr stark auf die Implementationsdetails ankommt. Ein Großteil der Implementationen, insbesondere sobald ein externer Anbieter für den Betrieb notwendig ist, schaffen mehr Probleme als Nutzen. Gesondert sei an dieser Stelle auf den Aspekt der Barrierefreiheit hingewiesen, welcher den Umfang dieses Artikels gesprengt hätte.

Wichtiger als die Isolation des Browsers ist ein ganzheitliches Sicherheitskonzept und die Vermeidung grundlegender Sicherheitsrisiken. Dazu gehört insbesondere ein funktionierendes und in diesem Sinne bestenfalls automatisiertes Patchmanagement. Die Isolationsbemühungen sollten dabei nicht am Browser enden.

Wer Browser Isolation als Lösung für ein gescheitertes Patchmanagement sieht, hat entweder den falschen Job oder seinen Job nicht verstanden.