Website-Isolierung für Webentwickler

Mathias Bynens

In Chrome 67 für Computer ist eine neue Funktion namens Website-Isolierung standardmäßig aktiviert. In diesem Artikel wird erläutert, worum es bei der Website-Isolierung geht, warum sie erforderlich ist und warum Webentwickler sie kennen sollten.

Was ist Website-Isolierung?

Das Internet ist unter anderem ideal, um sich Katzenvideos anzusehen und Wallets für Kryptowährungen zu verwalten. Aber du möchtest nicht, dass fluffycats.example Zugriff auf deine wertvollen Kryptocoins hat. Glücklicherweise können Websites dank der Same-Origin-Policy in der Regel nicht auf die Daten der anderen innerhalb des Browsers zugreifen. Schädliche Websites können jedoch versuchen, diese Richtlinie zu umgehen, um andere Websites anzugreifen, und gelegentlich werden Sicherheitslücken im Browsercode gefunden, der die Same-Origin-Richtlinie erzwingt. Das Chrome-Team ist bestrebt, solche Fehler so schnell wie möglich zu beheben.

Die Website-Isolierung ist eine Sicherheitsfunktion in Chrome, die eine zusätzliche Abwehrlinie bietet, um die Wahrscheinlichkeit eines solchen Angriffs zu verringern. Es sorgt dafür, dass Seiten von verschiedenen Websites immer verschiedenen Prozessen zugewiesen werden, die jeweils in einer Sandbox ausgeführt werden, die die Ausführung des Prozesses einschränkt. Außerdem wird der Prozess daran gehindert, bestimmte Arten sensibler Daten von anderen Websites zu empfangen. Dadurch ist es für eine schädliche Website mit der Website-Isolierung wesentlich schwieriger, spekulative Side-Channel-Angriffe wie Spectre auszuführen, um Daten von anderen Websites zu stehlen. Wenn das Chrome-Team weitere Maßnahmen abschließt, hilft die Website-Isolierung auch dann, wenn die Seite eines Angreifers einige Regeln im eigenen Prozess verletzen kann.

Die Website-Isolierung erschwert es nicht vertrauenswürdigen Websites effektiv, auf Informationen aus Ihren Konten auf anderen Websites zuzugreifen oder diese zu stehlen. Sie bietet zusätzlichen Schutz vor verschiedenen Arten von Sicherheitslücken, wie den aktuellen Meltdown- und Spectre-Seitenkanalangriffen.

Weitere Informationen zur Website-Isolierung finden Sie in unserem Artikel im Blog zur Sicherheit von Google.

Cross-Origin-Leseblockierung

Auch wenn alle websiteübergreifenden Seiten separaten Prozessen zugeordnet sind, können Seiten dennoch legitimerweise einige websiteübergreifende Unterressourcen wie Bilder und JavaScript anfordern. Eine schädliche Webseite könnte ein <img>-Element verwenden, um eine JSON-Datei mit sensiblen Daten wie Ihrem Kontostand zu laden:

<img src="https://your-bank.example/balance.json" />
<!-- Note: the attacker refused to add an `alt` attribute, for extra evil points. -->

Ohne Website-Isolierung würde der Inhalt der JSON-Datei im Arbeitsspeicher des Renderer-Prozesses abgelegt werden. Der Renderer erkennt dann, dass es sich nicht um ein gültiges Bildformat handelt, und rendert kein Bild. Der Angreifer könnte dann jedoch eine Sicherheitslücke wie Spectre ausnutzen, um diesen Speicherblock möglicherweise zu lesen.

Anstelle von <img> könnte der Angreifer auch <script> verwenden, um die sensiblen Daten im Arbeitsspeicher zu speichern:

<script src="https://your-bank.example/balance.json"></script>

Cross-Origin Read Blocking (CORB) ist eine neue Sicherheitsfunktion, die verhindert, dass der Inhalt von balance.json je nach MIME-Typ in den Arbeitsspeicher des Rendererprozessspeichers gelangt.

Sehen wir uns an, wie CORB funktioniert. Eine Website kann zwei Arten von Ressourcen von einem Server anfordern:

  1. Datenressourcen wie HTML-, XML- oder JSON-Dokumente
  2. Medienressourcen wie Bilder, JavaScript, CSS oder Schriftarten

Eine Website kann Datenressourcen aus ihrer eigenen oder anderen Ursprüngen erhalten, wenn dafür CORS-Header wie Access-Control-Allow-Origin: * verwendet werden. Andererseits können Medienressourcen beliebigen Ursprungs enthalten sein, auch ohne moderate CORS-Header.

CORB verhindert in folgenden Fällen, dass der Renderer-Prozess eine ursprungsübergreifende Datenressource (z.B. HTML, XML oder JSON) empfängt:

  • Die Ressource hat einen X-Content-Type-Options: nosniff-Header
  • CORS erlaubt nicht explizit den Zugriff auf die Ressource

Wenn für die ursprungsübergreifende Datenressource der Header X-Content-Type-Options: nosniff nicht festgelegt ist, versucht CorB, den Antworttext zu durchsuchen, um zu ermitteln, ob es sich um HTML, XML oder JSON handelt. Dies ist erforderlich, da einige Webserver falsch konfiguriert sind und Bilder beispielsweise als text/html bereitstellen.

Datenressourcen, die von der CORB-Richtlinie blockiert werden, werden dem Prozess als leer angezeigt, obwohl die Anfrage weiterhin im Hintergrund ausgeführt wird. Daher fällt es einer schädlichen Webseite schwer, websiteübergreifende Daten in den Prozess zu ziehen, um sie zu stehlen.

Für optimale Sicherheit und um von CORB zu profitieren, empfehlen wir Folgendes:

  • Markieren Sie Antworten mit dem richtigen Content-Type-Header. HTML-Ressourcen sollten beispielsweise als text/html, JSON-Ressourcen mit einem JSON-MIME-Typ und XML-Ressourcen mit einem XML-MIME-Typ bereitgestellt werden.
  • Deaktivieren Sie das Sniffing mithilfe des X-Content-Type-Options: nosniff-Headers. Ohne diesen Header führt Chrome eine schnelle Inhaltsanalyse durch, um zu bestätigen, dass der Typ korrekt ist. Da dabei jedoch Antworten zugelassen werden, um zu vermeiden, dass Elemente wie JavaScript-Dateien blockiert werden, ist es besser, aktiv das Richtige selbst zu tun.

Weitere Informationen finden Sie im CORB-Artikel zu Webentwicklern oder in unserer ausführlichen CORB-Erklärung.

Warum ist die Website-Isolierung wichtig für Webentwickler?

Die Website-Isolierung ist zum größten Teil eine Browserfunktion im Hintergrund, die Webentwicklern nicht direkt zugänglich ist. Es gibt zum Beispiel keine neue API, die im Web verfügbar ist. Im Allgemeinen sollten Webseiten bei Ausführung mit oder ohne Website-Isolierung keinen Unterschied erkennen können.

Es gibt jedoch einige Ausnahmen von dieser Regel. Wenn Sie die Website-Isolierung aktivieren, hat das einige geringfügige Nebenwirkungen, die sich auf Ihre Website auswirken können. Wir führen eine Liste bekannter Probleme mit der Website-Isolierung. Die wichtigsten sind nachfolgend beschrieben.

Das ganzseitige Layout ist nicht mehr synchron

Mit der Website-Isolierung ist nicht mehr garantiert, dass ein ganzseitiges Layout synchron ist, da die Frames einer Seite jetzt auf mehrere Prozesse verteilt sein können. Dies kann sich auf Seiten auswirken, wenn sie davon ausgehen, dass eine Layoutänderung sofort für alle Frames auf der Seite übernommen wird.

Betrachten wir als Beispiel eine Website mit dem Namen fluffykittens.example, die mit einem auf social-widget.example gehosteten Social-Media-Widget kommuniziert:

<!-- https://fluffykittens.example/ -->
<iframe src="https://social-widget.example/" width="123"></iframe>
<script>
  const iframe = document.querySelector('iframe');
  iframe.width = 456;
  iframe.contentWindow.postMessage(
    // The message to send:
    'Meow!',
    // The target origin:
    'https://social-widget.example'
  );
</script>

Zuerst ist die <iframe> des Widgets für soziale Netzwerke 123 Pixel breit. Dann ändert die FluffyKittens-Seite die Breite in 456 Pixel (ausgelöstes Layout) und sendet eine Nachricht an das Social-Media-Widget, das den folgenden Code enthält:

<!-- https://social-widget.example/ -->
<script>
  self.onmessage = () => {
    console.log(document.documentElement.clientWidth);
  };
</script>

Immer wenn das Widget für soziale Netzwerke eine Nachricht über die postMessage API erhält, protokolliert es die Breite seines <html>-Stammelements.

Welcher Breitenwert wird protokolliert? Bevor Chrome die Website-Isolierung aktivierte, lautete die Antwort 456. Durch den Zugriff auf document.documentElement.clientWidth wird das Layout erzwungen, das vorher synchron war, bevor die Website-Isolierung in Chrome aktiviert wurde. Wenn die Website-Isolierung aktiviert ist, erfolgt das Neulayout des ursprungsübergreifenden Widgets für soziale Netzwerke jetzt asynchron in einem separaten Prozess. Somit kann die Antwort jetzt auch 123 sein, d.h. der alte width-Wert.

Wenn eine Seite die Größe eines ursprungsübergreifenden <iframe> ändert und dann eine postMessage an sie sendet, erkennt der empfangende Frame mit Website-Isolierung die neue Größe beim Empfang der Nachricht möglicherweise noch nicht. Im Allgemeinen kann das dazu führen, dass Seiten nicht mehr funktionieren, wenn sie davon ausgehen, dass eine Layoutänderung sofort für alle Frames auf der Seite übernommen wird.

In diesem speziellen Beispiel würde eine robustere Lösung den width im übergeordneten Frame festlegen und diese Änderung im <iframe> erkennen, indem auf ein resize-Ereignis gewartet wird.

Beim Entladen von Handlern kann es zu einer häufigeren Zeitüberschreitung kommen

Wenn ein Frame wechselt oder geschlossen wird, führen das alte Dokument sowie alle darin eingebetteten Subframe-Dokumente ihren unload-Handler aus. Wenn die neue Navigation im selben Rendererprozess erfolgt (z.B. bei einer Navigation am selben Ursprung), können die unload-Handler des alten Dokuments und seiner Subframes eine beliebige Zeit lang ausgeführt werden, bevor das Commit der neuen Navigation möglich ist.

addEventListener('unload', () => {
  doSomethingThatMightTakeALongTime();
});

In diesem Fall sind die unload-Handler in allen Frames sehr zuverlässig.

Allerdings sind einige Hauptframe-Navigationen auch ohne Website-Isolierung prozessübergreifend, was sich auf das Verhalten des Unload-Handlers auswirkt. Wenn Sie beispielsweise von old.example nach new.example gehen, indem Sie die URL in die Adressleiste eingeben, wird die new.example-Navigation in einem neuen Prozess ausgeführt. Die Unload-Handler für old.example und deren Subframes werden im Hintergrund im Prozess old.example ausgeführt, nachdem die Seite new.example angezeigt wurde. Die alten Unload-Handler werden beendet, wenn sie nicht innerhalb eines bestimmten Zeitlimits abgeschlossen werden. Da die Unload-Handler möglicherweise nicht vor dem Zeitlimit abgeschlossen werden, ist das Entladeverhalten weniger zuverlässig.

Mit der Website-Isolierung werden alle websiteübergreifenden Navigationen prozessübergreifend, sodass Dokumente von verschiedenen Websites nicht denselben Prozess teilen. Daher tritt die oben beschriebene Situation häufiger auf und Unload-Handler in <iframe>s haben oft die oben beschriebenen Hintergrund- und Zeitüberschreitungsverhalten.

Ein weiterer Unterschied, der sich aus der Website-Isolierung ergibt, ist die neue parallele Reihenfolge von Unload-Handlern: Ohne Website-Isolierung werden Unload-Handler Frames in einer strengen Top-down-Reihenfolge ausgeführt. Mit der Website-Isolierung werden Unload-Handler in verschiedenen Prozessen parallel ausgeführt.

Dies sind grundlegende Konsequenzen der Aktivierung der Website-Isolierung. Das Chrome-Team arbeitet daran, die Zuverlässigkeit von Unload-Handlern für gängige Anwendungsfälle zu verbessern, sofern möglich. Außerdem sind wir uns der Fehler bewusst, bei denen Subframe-Unload-Handler bestimmte Funktionen noch nicht nutzen können, und arbeiten bereits an deren Behebung.

Ein wichtiger Fall für Unload-Handler ist das Senden von Pings am Ende der Sitzung. Dies geschieht in der Regel so:

addEventListener('pagehide', () => {
  const image = new Image();
  img.src = '/end-of-session';
});

Ein besserer Ansatz, der angesichts dieser Änderung robuster ist, besteht darin, stattdessen navigator.sendBeacon zu verwenden:

addEventListener('pagehide', () => {
  navigator.sendBeacon('/end-of-session');
});

Wenn Sie mehr Kontrolle über die Anfrage benötigen, können Sie die Option keepalive der Fetch API verwenden:

addEventListener('pagehide', () => {
  fetch('/end-of-session', {keepalive: true});
});

Fazit

Die Website-Isolierung erschwert es nicht vertrauenswürdigen Websites, auf Informationen aus Ihren Konten auf anderen Websites zuzugreifen oder diese zu stehlen, indem jede Website in ihren eigenen Prozess isoliert wird. In diesem Zusammenhang versucht CORB, sensible Datenressourcen vom Rendererprozess fernzuhalten. Mit unseren Empfehlungen oben können Sie diese neuen Sicherheitsfunktionen optimal nutzen.

Wir danken Alex Moshchuk, Charlie Reis, Jason Miller, Nasko Oskov, Philip Walton, Shubhie Panicker und Thomas Steiner für das Lesen eines Entwurfs dieses Artikels und das Feedback.