Ein einfacher Remote-Browser teilt einen einzigen Browser-Prozess unter vielen Benutzern. In einer Sitzung gesetzte Cookies erscheinen in der nächsten; localStorage-Daten überschreiten Sitzungsgrenzen; der Authentifizierungsstatus eines Benutzers kann von einem anderen übernommen werden. Selbst wenn die geschützte Anwendung selbst sich gut verhält, wird der geteilte Browser zu einem Seitenkanal, der jede Zugriffskontrolle auf Anwendungsebene umgeht.
Hinzu kommt die Navigation. Ein Benutzer mit reiner Anzeigeberechtigung auf einem einzigen internen Dashboard klickt innerhalb dieses Dashboards auf einen Phishing-Link, öffnet einen neuen Tab für ein persönliches Konto oder folgt einem externen Link, den er nicht beabsichtigt hat. Ohne Durchsetzung auf der Browser-Schicht entkommt die Sitzung aus der geschützten Anwendung — und nun werden die Sitzungs-ID der geschützten Anwendung, die Identität des Benutzers und der aktive Browsing-Zustand für den Ort sichtbar, an den der Browser gegangen ist.
Die Browser-Kontext-Isolation schließt beides. Jede Sitzung läuft in ihrem eigenen Browser-Kontext ohne geteilten Zustand. Der Browser selbst erzwingt eine Allowlist der Domains, die die Sitzung erreichen darf, und blockiert jeden Kanal, den der Benutzer nutzen könnte, um woandershin zu gehen — neue Tabs, Popups, Linkklicks zu nicht erlaubten Domains, programmatische Navigation durch die Seite selbst.
Jede Sitzung erhält ihren eigenen Browser-Kontext innerhalb der Rendering-Engine — vollständig getrennt vom Zustand jeder anderen Sitzung. Eine strenge Domain-Allowlist greift auf der Navigationsschicht ein — Anfrageabfang, Single-Page-Application-Navigations-Polling und Linkklick-Abfang sorgen gemeinsam dafür, dass die Sitzung niemals eine nicht erlaubte Domain erreicht. Darunter tragen die gerenderten Pixel selbst kontinuierliche Low-Level-Modifikationen, die Automatisierungstools stören, die versuchen, die Sitzung auszulesen oder mit ihr zu interagieren.
Jede Benutzersitzung wird in ihrem eigenen isolierten Browser-Kontext geöffnet — einem brandneuen Profil mit eigenem Cookie-Jar, eigenem lokalen Speicher und eigenem Sitzungszustand. Zwei Benutzer auf derselben geschützten Anwendung haben völlig unabhängige Browser; nichts aus einer Sitzung ist für die andere sichtbar. Das Sitzungsende zerstört den Kontext vollständig; kein Zustand überlebt.
Jeder Navigationsversuch wird abgefangen, bevor er ausgeführt wird. Die Anfrageschicht blockiert nicht erlaubte Domains auf Netzwerkebene; Linkklicks innerhalb der Seite werden auf der Rendering-Schicht abgefangen; Single-Page-Application-Navigationen (pushState, replaceState) werden per Polling erfasst. Die Sitzung kann keine Domain außerhalb der Allowlist erreichen, ob der Benutzer es absichtlich versucht oder die Seite es von sich aus versucht.
Der Browser im Kiosk-Stil erlaubt dem Benutzer nicht, neue Tabs zu öffnen, Popups zu erzeugen oder das Rechtsklick-Kontextmenü zu verwenden. Jeder Kanal, den der Benutzer nutzen könnte, um aus der geschützten Anwendung zu entkommen, ist in der Browser-Konfiguration geschlossen. Der Benutzer arbeitet innerhalb der für ihn geöffneten Sitzung — nicht mehr.
Unter dem sichtbaren Inhalt trägt der gerenderte Pixelstream kontinuierliche Low-Level-Modifikationen — zufälliges Rauschen, feine Farbverschiebungen, Mikro-Elementverschiebung, Subpixel-Vibration. Diese beeinträchtigen nicht, was der Benutzer sieht, stören aber Automatisierungstools (Selenium, Puppeteer-Skripte, Screen Scraper), die versuchen, die Sitzung außerhalb des offiziellen Eingabekanals auszulesen oder mit ihr zu interagieren.
Jedes der folgenden Verhalten wird pro geschütztem Service konfiguriert und nicht im Code der geschützten Anwendung, sondern auf der Browser-Schicht erzwungen. Die geschützte Anwendung muss von ihrer Existenz nichts wissen — die Grenze ist aus der Laufzeit der Anwendung unsichtbar.
Jede Sitzung läuft in ihrem eigenen Browser-Kontext — einer Konstruktion auf Chromium-Ebene, die der Sitzung ihren eigenen Cookie-Jar, ihren eigenen lokalen Speicher, ihre eigene Service-Worker-Registrierung, ihre eigenen Berechtigungen und ihren eigenen Sitzungszustand gibt. Zwei Sitzungen auf derselben geschützten Anwendung teilen auf Browser-Ebene nichts.
Jede Navigationsanfrage — Hauptdokument, Unterdokument, Fetch, XHR — durchläuft einen Abfänger, der die Ziel-Domain gegen die Allowlist der Sitzung prüft. Nicht erlaubte Domains werden blockiert, bevor eine Verbindung aufgebaut wird. Es gibt keine Race Condition zwischen dem Klick des Benutzers und der Prüfung der Navigation.
Moderne Single-Page-Applications navigieren, indem sie pushState oder replaceState aufrufen, ohne eine Netzwerkanfrage zu stellen. Ein einfacher Anfrageabfänger kann diese nicht erfassen. ZeroLeak pollt außerdem die aktuelle URL innerhalb der Seite in kurzen Intervallen, sodass SPA-Navigationen zu nicht erlaubten Pfaden innerhalb von Sekunden erfasst und rückgängig gemacht werden.
Linkelemente mit nicht erlaubtem Ziel, window.open()-Aufrufe, programmatische Standortänderungen — alle werden innerhalb der gerenderten Seite abgefangen, bevor sie ausgeführt werden. Ein Benutzer, der auf einen Link klickt, dem er nicht folgen darf, wird im Moment des Klicks blockiert, nicht erst nachdem die Netzwerkanfrage bereits begonnen hat.
Der Browser ist so konfiguriert, dass jeder Versuch, ein neues Browsing-Ziel zu erzeugen — durch den Benutzer, die Seite oder ein Skript — sofort abgefangen und verworfen wird. Die Sitzung hat immer genau einen sichtbaren Tab, und das ist der Tab der geschützten Anwendung.
Jede Sitzung überwacht die Benutzerinteraktion. Wenn der Benutzer länger als das konfigurierte Timeout im Leerlauf ist, wird die Sitzung ordnungsgemäß beendet, der Browser-Kontext zerstört und (wenn konfiguriert) ein Webhook informiert den Koordinator, sodass die Zielrichtlinie aktualisiert werden kann. Keine speicherzehrenden verlassenen isolierten Browser.
Über die Isolation pro Sitzung und die Navigationsgrenze hinaus trägt der gerenderte Pixelstream selbst kontinuierliche Low-Level-Modifikationen. Ihr Zweck ist es, Automatisierungstools zu stören — Skripte, die andernfalls den Sitzungsbildschirm auslesen, Elemente identifizieren und über inoffizielle Kanäle interagieren würden — ohne zu beeinflussen, wie die Seite für den menschlichen Benutzer aussieht oder sich verhält.
Ein Canvas-Overlay zeichnet kontinuierlich zufälliges Rauschen geringer Intensität über die gerenderte Seite. Das menschliche Auge nimmt höchstens eine leichte Textur wahr; OCR- und Template-Matching-Skripte, die versuchen, den Bildschirm auszulesen, verlieren die konsistenten Pixelgrenzen, auf die sie sich verlassen. Rauschintensität und Aktualisierungsrate sind pro geschütztem Service konfigurierbar.
Ein halbtransparentes Overlay legt einen sich langsam ändernden zufälligen Farbton über die gerenderte Seite. Weiße und schwarze Bereiche erscheinen dem Auge weiterhin effektiv weiß und schwarz, aber die tatsächlichen Pixelwerte verschieben sich. Bildbasierte Automatisierungstools, die gegen Farbsignaturen abgleichen, verlieren ihre Referenzen.
Als Bildschirmfilter wird eine sehr leichte kontinuierliche Unschärfe angewendet. Jeder Frame unterscheidet sich in seinen hochfrequenten Details geringfügig, was es OCR- und Mustervergleichern erschwert, stabile Merkmalpunkte zu finden. Der Benutzer nimmt die Unschärfe auf normaler Leseentfernung nicht wahr.
Seitenelemente werden gegenüber ihren normalen Positionen um 1-3 Pixel zufällig verschoben. Die Verschiebung liegt unter der menschlichen Wahrnehmung, stört aber Skripte, die Elemente über absolute Bildschirmkoordinaten finden. Automatisierungstools können sich von einem Frame zum nächsten nicht auf eine stabile Elementposition verlassen.
In kurzen Intervallen wird die gesamte gerenderte Oberfläche um einige Pixel verschoben — klein genug, um das Lesen nicht zu stören, groß genug, um Automatisierungstools zu schlagen, die für die Eingabesimulation auf konsistente absolute Pixelkoordinaten angewiesen sind. Replay-Angriffe im Selenium-Stil verlieren ihre festen Punkte.
Oberflächen für kritische Infrastruktur, bei denen ein Zustandsleck zwischen Sitzungen oder eine unerwünschte Navigation physische Systeme beeinflussen könnte. Die Isolation pro Sitzung garantiert, dass zwei Operatoren an derselben Konsole die Sitzung des jeweils anderen nicht sehen können; die strenge Allowlist sorgt dafür, dass keiner von ihnen von der Betriebskonsole zu einem externen Link wechselt.
Interne Dashboards, Prüfoberflächen und Reporting-Tools, auf die viele Benutzer zugreifen — einschließlich Auftragnehmer und externe Prüfer. Jede Sitzung ist ihr eigener Browser, die Zugriffsrichtlinie wird auf der Navigationsschicht erzwungen, und die Abwehrmaßnahmen auf Rendering-Ebene widerstehen der Automatisierung von jedem, der versucht, den Bildschirm auszulesen.
Der Kontext pro Sitzung bedeutet, dass ein Auftragnehmer, der einen Datenraum betrachtet, weder die Cookies, den Suchverlauf noch die Sitzungs-IDs eines anderen Auftragnehmers in einem anderen Datenraum sehen kann. Die Allowlist sorgt dafür, dass die Datenraumsitzung niemals ins weitere Internet geht.
Studienportale, in denen mehrere Forscher unter strengen Offenlegungsgrenzen auf Patientendaten zugreifen. Die Isolation pro Sitzung erzwingt die Grenze auf der Browser-Schicht; die Allowlist erzwingt sie auf der Navigationsschicht; die Rendering-Abwehrmaßnahmen widerstehen der Automatisierung von jedem, der versucht, über den Datenbildschirmkanal auszulesen.
Wir führen zwei Sitzungen auf derselben geschützten Anwendung nebeneinander aus, zeigen, dass nichts zwischen ihnen leckt, versuchen, die Allowlist zu verlassen, und versuchen, die Sitzung mit einem externen Automatisierungstool zu steuern — und zeigen, was passiert.