Website-Isolierung für Webentwickler

Mathias Bynens

Chrome 67 für Computer enthält eine neue Funktion namens Website-Isolierung, die standardmäßig aktiviert ist. In diesem Artikel erfahren Sie, was Website-Isolation ist, warum sie erforderlich ist und warum Webentwickler sie kennen sollten.

Was ist die Website-Isolierung?

Das Internet eignet sich unter anderem zum Ansehen von Katzenvideos und zum Verwalten von Krypto-Wallets. Sie möchten aber nicht, dass fluffycats.example Zugriff auf Ihre wertvollen Kryptowährungen hat. Glücklicherweise können Websites dank der Richtlinie zur gleichen Herkunft in der Regel nicht auf die Daten anderer Websites im Browser zugreifen. Trotzdem versuchen bösartige Websites möglicherweise, diese Richtlinie zu umgehen, um andere Websites anzugreifen. Gelegentlich werden auch Sicherheitslücken im Browsercode gefunden, mit dem die Same-Origin-Policy erzwungen wird. Das Chrome-Team arbeitet daran, solche Fehler so schnell wie möglich zu beheben.

Die Website-Isolierung ist eine Sicherheitsfunktion in Chrome, die eine zusätzliche Verteidigungslinie bietet, um die Wahrscheinlichkeit solcher Angriffe zu verringern. So wird sichergestellt, dass Seiten verschiedener Websites immer in unterschiedliche Prozesse verschoben werden, die jeweils in einer Sandbox ausgeführt werden, die die zulässigen Aktionen des Prozesses einschränkt. Außerdem wird verhindert, dass der Prozess bestimmte Arten sensibler Daten von anderen Websites empfängt. Daher ist es mit der Website-Isolation für eine schädliche Website viel schwieriger, mithilfe von spekulativen Seitenkanalangriffen wie Spectre Daten von anderen Websites zu stehlen. Sobald das Chrome-Team weitere Maßnahmen implementiert hat, hilft die Website-Isolierung auch dann, wenn die Seite eines Angreifers einige der Regeln in seinem eigenen Prozess bricht.

Mit der Website-Isolierung wird es für nicht vertrauenswürdige Websites schwieriger, auf Daten in Ihren Konten auf anderen Websites zuzugreifen oder diese zu stehlen. Sie bietet zusätzlichen Schutz vor verschiedenen Arten von Sicherheitslücken, z. B. vor den jüngsten Seitenkanalangriffen von Meltdown und Spectre.

Weitere Informationen zur Site Isolation finden Sie in unserem Artikel im Google Security Blog.

Cross-Origin Read Blocking

Auch wenn alle websiteübergreifenden Seiten in separate Prozesse verschoben werden, können Seiten weiterhin 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 Bankguthaben zu laden:

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

Ohne Site Isolation würde der Inhalt der JSON-Datei in den Arbeitsspeicher des Rendering-Prozesses gelangen. Dort erkennt der Renderer, dass es sich nicht um ein gültiges Bildformat handelt, und rendert kein Bild. Der Angreifer könnte jedoch eine Sicherheitslücke wie Spectre ausnutzen, um diesen Speicherbereich 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 aufgrund seines MIME-Typs in den Speicher des Renderer-Prozesses 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 von ihrer eigenen Quelle oder von anderen Quellen mit permissiven CORS-Headern wie Access-Control-Allow-Origin: * empfangen. Medienressourcen können dagegen von jeder Quelle eingebunden werden, auch ohne CORS-Header mit permissiven Zugriffsrechten.

CORB verhindert, dass der Rendererprozess eine datenübergreifende Datenressource (d.h. HTML, XML oder JSON) empfängt, wenn:

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

Wenn für die datenübergreifende Datenressource der X-Content-Type-Options: nosniff-Header nicht festgelegt ist, versucht CORB, den Antworttext zu sniffen, um zu ermitteln, ob es sich um HTML, XML oder JSON handelt. Das ist notwendig, weil einige Webserver falsch konfiguriert sind und Bilder beispielsweise als text/html ausliefern.

Datenressourcen, die von der CORB-Richtlinie blockiert werden, werden dem Prozess als leer angezeigt, obwohl die Anfrage weiterhin im Hintergrund erfolgt. Daher ist es für eine schädliche Webseite schwierig, websiteübergreifende Daten in den Prozess einzubinden, um sie zu stehlen.

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

  • Antworten mit dem richtigen Content-Type-Header kennzeichnen. Beispielsweise sollten HTML-Ressourcen als text/html, JSON-Ressourcen mit einem JSON-MIME-Typ und XML-Ressourcen mit einem XML-MIME-Typ bereitgestellt werden.
  • Verwenden Sie den Header X-Content-Type-Options: nosniff, um das Auswerten zu deaktivieren. Ohne diese Kopfzeile führt Chrome zwar eine schnelle Inhaltsanalyse durch, um zu prüfen, ob der Typ korrekt ist, aber da bei dieser Methode eher zu viele Antworten zugelassen werden, um Dinge wie JavaScript-Dateien zu blockieren, sollten Sie die richtige Entscheidung lieber selbst treffen.

Weitere Informationen finden Sie im Artikel CORB für Webentwickler oder in der ausführlichen CORB-Erläuterung.

Warum sollten Webentwickler die Website-Isolierung beachten?

Die Website-Isolierung ist größtenteils eine Browserfunktion, die Webentwicklern nicht direkt zur Verfügung steht. Es gibt beispielsweise keine neue webbasierte API, die Sie lernen müssen. Im Allgemeinen sollten Webseiten keinen Unterschied feststellen können, wenn sie mit oder ohne Website-Isolierung ausgeführt werden.

Es gibt jedoch einige Ausnahmen von dieser Regel. Die Aktivierung der Website-Isolierung hat einige subtile Nebenwirkungen, die sich auf Ihre Website auswirken können. Wir führen eine Liste der bekannten Probleme mit Site Isolation. Im Folgenden gehen wir auf die wichtigsten ein.

Das Layout für die volle Seite ist nicht mehr synchron

Bei der Website-Isolierung ist das Layout der gesamten Seite nicht mehr synchron, da die Frames einer Seite jetzt auf mehrere Prozesse verteilt werden können. Das kann sich auf Seiten auswirken, wenn davon ausgegangen wird, dass eine Layoutänderung sofort auf alle Frames auf der Seite angewendet wird.

Angenommen, eine Website namens fluffykittens.example kommuniziert mit einem Social-Media-Widget, das auf social-widget.example gehostet wird:

<!-- 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 hat das <iframe>-Widget eine Breite von 123 Pixeln. Auf der Seite „FluffyKittens“ ändert sich die Breite jedoch zu 456 Pixeln (Layout wird ausgelöst) und es wird eine Nachricht an das Social-Media-Widget gesendet, das den folgenden Code enthält:

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

Jedes Mal, wenn das Social-Media-Widget eine Nachricht über die postMessage API empfängt, wird die Breite des Stammelements <html> protokolliert.

Welcher Wert für die Breite wird protokolliert? Bevor die Website-Isolierung in Chrome aktiviert wurde, lautete die Antwort 456. Wenn Sie auf document.documentElement.clientWidth zugreifen, wird das Layout erzwungen, das vor der Aktivierung der Website-Isolierung in Chrome synchron war. Wenn die Website-Isolierung jedoch aktiviert ist, wird das neu layoutete soziale Widget mit Ursprungsübergang jetzt asynchron in einem separaten Prozess ausgeführt. Daher kann die Antwort jetzt auch 123 sein, also der alte Wert von width.

Wenn eine Seite die Größe eines <iframe> zwischen verschiedenen Ursprüngen ändert und dann eine postMessage an ihn sendet, kennt der empfangende Frame bei der Site Isolation möglicherweise noch nicht seine neue Größe, wenn er die Nachricht empfängt. Im Allgemeinen kann dies zu Fehlern auf Seiten führen, wenn davon ausgegangen wird, dass sich eine Layoutänderung sofort auf alle Frames auf der Seite auswirkt.

In diesem Beispiel wäre eine robustere Lösung, die width im übergeordneten Frame festzulegen und diese Änderung im <iframe> zu erkennen, indem auf ein resize-Ereignis gewartet wird.

Bei Entlade-Handlern kommt es möglicherweise häufiger zu Zeitüberschreitungen.

Wenn ein Frame gewechselt oder geschlossen wird, wird der unload-Handler sowohl für das alte Dokument als auch für alle darin eingebetteten Unterframe-Dokumente ausgeführt. Wenn die neue Navigation im selben Rendering-Prozess erfolgt (z.B. bei einer Navigation mit demselben Ursprung), können die unload-Handler des alten Dokuments und seiner Unterframes beliebig lange ausgeführt werden, bevor die neue Navigation ausgeführt wird.

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

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

Aber auch ohne Site Isolation sind einige Hauptframe-Navigationen prozessübergreifend, was sich auf das Verhalten des Entlade-Handlers auswirkt. Wenn Sie beispielsweise von old.example zu new.example wechseln, indem Sie die URL in die Adressleiste eingeben, wird die Navigation zu new.example in einem neuen Prozess ausgeführt. Die Entlade-Handler für old.example und seine Unterframes werden im old.example-Prozess im Hintergrund ausgeführt, nachdem die new.example-Seite angezeigt wurde. Die alten Entlade-Handler werden beendet, wenn sie nicht innerhalb eines bestimmten Zeitlimits abgeschlossen werden. Da die Entlade-Handler möglicherweise nicht vor Ablauf des Zeitlimits abgeschlossen sind, ist das Entladeverhalten weniger zuverlässig.

Bei der Website-Isolierung werden alle websiteübergreifenden Navigationen zu prozessübergreifenden Navigationen, sodass Dokumente verschiedener Websites keinen gemeinsamen Prozess nutzen. Daher tritt die oben beschriebene Situation in mehr Fällen auf und die Entlade-Handler in <iframe>s haben häufig das oben beschriebene Verhalten im Hintergrund und bei Zeitüberschreitung.

Ein weiterer Unterschied, der sich aus der Website-Isolierung ergibt, ist die neue parallele Sortierung der Entlade-Handler: Ohne Website-Isolierung werden Entlade-Handler in einer strikten Top-Down-Reihenfolge über Frames hinweg ausgeführt. Bei der Website-Isolierung werden die Entlade-Handler jedoch parallel in verschiedenen Prozessen ausgeführt.

Dies sind grundlegende Folgen der Aktivierung der Website-Isolation. Das Chrome-Team arbeitet daran, die Zuverlässigkeit von Unload-Handlern für gängige Anwendungsfälle nach Möglichkeit zu verbessern. Uns sind auch Fehler bekannt, bei denen bestimmte Funktionen von Subframe-Entlade-Handlern noch nicht genutzt werden können. Wir arbeiten daran, diese zu beheben.

Ein wichtiger Fall für Entlade-Handler ist das Senden von Pings am Ende der Sitzung. Das 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

Durch die Website-Isolierung wird es für nicht vertrauenswürdige Websites schwieriger, auf Ihre Konten auf anderen Websites zuzugreifen oder diese zu stehlen. Dazu wird jede Website in einem eigenen Prozess ausgeführt. Dabei versucht CORB, sensible Datenressourcen aus dem Rendering-Prozess herauszuhalten. Mit unseren Empfehlungen oben können Sie diese neuen Sicherheitsfunktionen optimal nutzen.

Vielen Dank an Alex Moshchuk, Charlie Reis, Jason Miller, Nasko Oskov, Philip Walton, Shubhi Panicker und Thomas Steiner, die eine Entwurfsversion dieses Artikels gelesen und Feedback gegeben haben.