Sandbox und Prozess-Isolation

Das Grundprinzip

Stell dir den Browser nicht als ein einzelnes Programm vor, sondern als mehrere zusammenarbeitende Prozesse mit unterschiedlichen Rechten:

• Ein Browser-Prozess (Hauptprozess), der UI, Tabs, Lesezeichen, Netzwerk und Plattform-Zugriff verwaltet — und vollen OS-Zugriff hat.
• Mehrere Renderer-Prozesse, die jeweils HTML, CSS und JavaScript einer Seite ausführen — mit sehr eingeschränkten OS-Rechten in einer Sandbox.
• Hilfs-Prozesse für Media-Decoding, GPU, Erweiterungen, jeweils mit eigener begrenzter Rechte-Lage.

Die wichtigste Annahme: der Renderer-Prozess wird kompromittiert werden — irgendwann, durch irgendeinen JS- oder Rendering-Exploit. Wenn das passiert, soll der Schaden in diesem Prozess gefangen sein:

• Kein Zugriff auf das Dateisystem (außer ausgewählte temporäre Verzeichnisse).
• Kein direkter Netzwerk-Zugriff (Anfragen gehen über den Browser-Prozess).
• Kein Zugriff auf andere Renderer-Prozesse.
• Kein Zugriff auf System-APIs (Kamera, Mikrofon, Hardware) ohne ausdrückliche Vermittlung.

Diese Sandbox-Architektur ist seit Chrome 1.0 (2008) Konzept-Standard im Web; Firefox hat 2017 mit der Multi-Process-Architektur („Electrolysis") nachgezogen. Safari hat eine eigene WebKit-Sandbox-Lösung, die noch enger ans macOS-Sicherheits-Framework angebunden ist.

Site Isolation: ein Prozess pro Site

Lange galt: ein Tab = ein Renderer-Prozess. Das hat sich mit Site Isolation geändert. Ausgelöst wurde der Wechsel durch eine bestimmte Klasse von Angriffen, die 2018 öffentlich wurde:

Spectre und Meltdown sind Hardware-Schwachstellen in modernen CPUs (Intel, ARM, AMD), die es einem laufenden Programm erlauben, durch spekulative Ausführung Speicher anderer Prozesse zu lesen. Auf Browser angewendet: ein bösartiges JavaScript könnte theoretisch den Speicher des Browser-Prozesses lesen — und damit Cookies, Passwörter, Tokens anderer geöffneter Tabs.

Die Antwort von Chrome (2018) und Firefox (Fission, 2021): Site Isolation.

• Jede Site (Origin: Protokoll + Domain + Port) bekommt einen eigenen Renderer-Prozess.
• iframes von Drittanbietern landen in separaten Prozessen vom Hauptdokument — Spectre-artige Speicher-Reads würden den falschen Prozess treffen.
• Hardware-Mitigations werden mit Browser-Mitigations kombiniert (z. B. weniger präzise performance.now()-Timer in JS, damit Side-Channel-Messungen schwerer werden).

Voraussetzungen:

• Genug RAM. Site Isolation bringt mehr Prozesse, jeder davon braucht Speicher. Chrome empfiehlt 4 GB RAM für die volle Site-Isolation-Erfahrung. Auf älteren Geräten reduziert der Browser automatisch die Isolation.
• Moderne CPU mit unterstützten Mitigations. Manche Spectre-Varianten brauchen Mikrocode-Updates des CPU-Herstellers — auf älteren ungeupdateten Systemen sind die Mitigations weniger wirksam.

Wie der Schutz konkret wirkt

Ein realistisches Beispiel: du hast in deinem Browser drei Tabs offen:

• Tab 1: Online-Banking deiner Sparkasse.
• Tab 2: Webmail bei Gmail.
• Tab 3: Ein Nachrichten-Artikel auf einem unbekannten Blog, dessen Werbe-Banner JavaScript aus einer Werbe-Domain lädt.

Ohne Site Isolation: alle drei Sites teilen sich potenziell denselben Renderer-Prozess. Eine Spectre-Schwachstelle im Werbe-Skript könnte Speicher-Reads aus dem Bank- oder Gmail-Tab versuchen.

Mit Site Isolation:

• Sparkasse läuft in einem eigenen Prozess.
• Gmail in einem zweiten.
• Der Nachrichten-Artikel in einem dritten.
• Das Werbe-iframe innerhalb des Artikels läuft sogar noch einmal isoliert — als eigener Prozess, weil die Origin der Werbe-Domain anders ist.

Eine theoretische Spectre-Attacke aus dem Werbe-iframe könnte höchstens Speicher des Werbe-iframe-Prozesses sehen — der enthält nichts Interessantes. Sparkasse- und Gmail-Cookies sind in einem anderen Prozess und damit nicht erreichbar.

Das ist die zentrale Schutz-Wirkung. Ohne Site Isolation wäre dasselbe Szenario eine reale Bedrohung; mit Site Isolation ist es Theorie.

Die Schichten im Detail

Eine kompakte Übersicht, was wo läuft:

Wer ein modernes OS auf einer modernen CPU mit aktuellem Browser nutzt, profitiert von all diesen Schichten gleichzeitig — meist unsichtbar.

---

Was Site Isolation NICHT leistet

Wichtige Abgrenzung — die Architektur ist mächtig, aber nicht magisch:

• Site Isolation schützt nicht vor Phishing. Wenn du auf einer Phishing-Seite Daten eingibst, wandern sie über die normalen Web-Mechanismen zum Angreifer. Die Prozess-Trennung ändert daran nichts.
• Site Isolation schützt nicht vor XSS. Eine XSS-Schwachstelle in deiner Bank-Seite läuft im Bank-Prozess — und kann dort Bank-Cookies lesen. Site Isolation greift nur zwischen Origins, nicht innerhalb einer Origin.
• Site Isolation schützt nicht vor kompromittierten Browser-Extensions. Extensions haben oft viel weitreichendere Rechte als normale Sites — siehe browser-sicher-einrichten.
• Site Isolation schützt nicht vor Browser-Bugs außerhalb des Renderers. Sandbox-Escapes — Schwachstellen, die einem Renderer-Prozess erlauben, aus der Sandbox auszubrechen — sind selten, aber existieren. Sie werden meist als „Pwn2Own"-Demonstrationen jährlich gezeigt und vom Hersteller schnell gefixt.
• Site Isolation hat Performance-Kosten. Mehr Prozesse = mehr RAM, mehr Kontext-Wechsel. Auf einem Gerät mit 2 GB RAM ist Site Isolation reduziert.

Die Architektur ist eine Schicht, kein vollständiger Schutz. Genau deshalb gibt es Defense-in-Depth — siehe risiko-und-defense-in-depth.

COOP, COEP, CORP: die feine Steuerung

Für Web-Entwickler:innen relevant — für aufmerksame Nutzer:innen als Hintergrund interessant: drei Header, die zusammen einen besonders strikten Isolations-Modus aktivieren.

• COOP (Cross-Origin-Opener-Policy) — kontrolliert, ob die Seite mit anderen Sites über window.opener interagieren darf.
• COEP (Cross-Origin-Embedder-Policy) — verlangt, dass alle eingebetteten Ressourcen (Bilder, iframes) explizit ihre Cross-Origin-Verwendung erlauben.
• CORP (Cross-Origin-Resource-Policy) — gibt Ressourcen mit, ob sie cross-origin geladen werden dürfen.

Wenn eine Seite COOP+COEP setzt und alle eingebetteten Ressourcen mitspielen, läuft sie in einem Cross-Origin Isolated-Modus. Nur in diesem Modus erlaubt der Browser bestimmte mächtige APIs (SharedArrayBuffer, präzise Timer) — weil dann die Spectre-Defenses zuverlässig greifen.

Vertieft in coop-coep-corp.

Mobile Plattformen: zusätzliche Schichten

Auf iOS und Android kommen weitere Sandbox-Schichten dazu:

iOS: Jeder App-Prozess läuft in einer eigenen Sandbox des Betriebssystems. Safari (und durch die WebKit-Pflicht in Europa bis 2024 alle iOS-Browser) erbt diese Sandbox; Browser-eigene Sandbox-Mechanismen liegen darüber. Drittanbieter-Engines (durch die EU-DMA seit 2024 erlaubt) müssen die iOS-Sandbox-Anforderungen genauso erfüllen.

Android: ART-Runtime-Sandbox plus Browser-eigene Renderer-Sandbox plus SELinux-Policies. Chrome auf Android nutzt sowohl die Android-App-Sandbox als auch eigene Renderer-Sub-Sandboxes — defense-in-depth in Reinform.

Konsequenz für die Praxis: Browser auf Mobile-Plattformen sind strukturell sicherer als auf Desktop, weil die OS-Sandbox zusätzlich schützt. Bei OS-Updates ist die mobile Lage allerdings oft schlechter (besonders bei Android-Geräten ohne aktuelle Sicherheitspatches).

Mehr zur mobilen Plattform-Seite in mobile-bedrohungslandschaft.

Besonderheiten

Chrome hat die Site Isolation 2018 als "Notreaktion" ausgerollt

Spectre und Meltdown wurden im Januar 2018 öffentlich. Chrome hat innerhalb weniger Monate die volle Site Isolation ausgerollt — eine sehr aggressive Reaktion mit erheblichen RAM-Kosten, aber strukturell richtig.

Firefox Fission kam 2021 — und ist heute Default

Mozilla hat länger gebraucht — die Multi-Prozess-Architektur war in Firefox bereits da, aber Fission (echte Site Isolation analog zu Chrome) ist erst 2021 standardmäßig aktiviert worden. Seitdem läuft auch in Firefox jede Origin in einem eigenen Renderer-Prozess.

Safari nutzt einen anderen Architektur-Ansatz

WebKit auf macOS und iOS hat seit Jahren eine sehr enge Anbindung an die OS-eigenen Sandbox-Mechanismen (sandbox_init, App Sandbox, XPC Services). Die Site-übergreifende Trennung ist nicht 1:1 wie Chromium-Site-Isolation, erreicht aber vergleichbaren Schutz durch die Plattform-Tiefe.

Pwn2Own demonstriert Sandbox-Escapes jährlich

Die jährliche Pwn2Own-Konferenz zeigt regelmäßig Browser-Sandbox-Escapes — meist eine Kette aus Renderer-Exploit + OS-Schwachstelle. Hersteller schließen die Lücken binnen Tagen. Die Demonstrationen sind ein lebendiger Beweis, dass Sandboxes nicht unbesiegbar sind — aber auch, wie eng der Spielraum ist.

Browser-Prozesse anzeigen lassen

In Chrome: Shift+Esc öffnet den Task-Manager — zeigt pro Tab und Erweiterung den eigenen Prozess mit RAM/CPU. Faszinierende Sicht in die Architektur. In Firefox: about:processes in die Adressleiste.

RAM-Verbrauch ist der Trade-off

Site Isolation kostet RAM — viele Renderer-Prozesse mit eigenem Heap, eigenem JS-Compiler-State, eigenem Memory-Pool. Auf einem 4-GB-Laptop merkst du das beim Surfen mit vielen Tabs. Browser reagieren mit Prozess-Recycling, Tab-Freeze, Throttling — und im Notfall mit reduzierter Isolation.

Browser-Architektur ist immer noch im Wandel

Chrome experimentiert mit weitergehender Isolation (z. B. JavaScript-Engine V8 in eigene Prozesse, Trusted-Types-Pflicht). Firefox plant ähnliche Schritte. Wer das technisch verfolgt: Chromium Blog und Mozilla Hacks sind die besten Quellen für die Architektur-Entwicklung.

Weiterführende Ressourcen

Externe Quellen

• Chromium – Site Isolation Design
• Mozilla – Project Fission (Architektur-Übersicht)
• Google Project Zero – Spectre Reading List
• web.dev – Why coop-coep?
• MDN – Cross-Origin Isolation
• Pwn2Own – ZDI Konferenz-Seite
• Apple Security Research – WebKit-Sandbox
• Microsoft Edge – Process Model

Verwandte Artikel

• Browser sicher einrichten
• HTTPS und Zertifikate
• Download-Hygiene
• COOP, COEP, CORP (Entwickler-Sicht)
• Risiko und Defense-in-Depth
• Mobile Bedrohungslandschaft