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 Abwehrlinie bietet, um den Erfolg solcher Angriffe zu verringern. Dabei wird sichergestellt, dass Seiten von verschiedenen Websites immer in verschiedene Prozesse gestellt werden, die jeweils in einer Sandbox ausgeführt werden. Dadurch werden die zulässigen Vorgänge eingeschränkt. Außerdem wird der Prozess daran gehindert, bestimmte Arten sensibler Daten von anderen Websites zu empfangen. 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 ergriffen hat, hilft die Website-Isolierung auch dann, wenn die Seite eines Angreifers einige der Regeln in ihrem eigenen Prozess bricht.

Die Website-Isolierung erschwert es nicht vertrauenswürdigen Websites, 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 aktuellen Meltdown- und Spectre-Seitenkanalangriffen.

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 des MIME-Typs überhaupt 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 von ihrer eigenen Quelle oder von anderen Quellen mit permissiven CORS-Headern wie Access-Control-Allow-Origin: * empfangen. Andererseits können Medienressourcen von jedem Ursprung stammen, auch ohne moderate CORS-Header.

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

  • die Ressource einen X-Content-Type-Options: nosniff-Header hat
  • CORS erlaubt nicht explizit 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 untersuchen, um festzustellen, 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 durch die CORB-Richtlinie blockiert werden, werden dem Prozess als leer angezeigt, obwohl die Anfrage weiterhin im Hintergrund ausgeführt wird. Infolgedessen hat eine schädliche Webseite Schwierigkeiten, websiteübergreifende Daten in ihren Prozess zu ziehen.

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

  • Antworten mit dem richtigen Content-Type-Header kennzeichnen. HTML-Ressourcen sollten beispielsweise 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 zu CORB für Webentwickler und in unserer ausführlichen CORB-Erklärung.

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 erkennen können, unabhängig davon, ob 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 ganzseitige Layout 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.

Nehmen wir als Beispiel eine Website mit dem Namen fluffykittens.example, die mit einem auf social-widget.example gehosteten Widget für soziale Netzwerke 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>

Die Breite des <iframe>-Widgets für soziale Netzwerke beträgt anfangs 123 Pixel. Dann ändert die FluffyKittens-Seite jedoch die Breite in 456 Pixel (ausgelöstes Layout) und sendet eine Nachricht an das Widget für soziale Netzwerke, das 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 Breitenwert wird protokolliert? Bevor die Website-Isolierung in Chrome aktiviert wurde, lautete die Antwort 456. Durch den Zugriff auf document.documentElement.clientWidth wird das Layout erzwungen, das vor der Aktivierung der Website-Isolierung in Chrome synchron war. Wenn die Website-Isolierung jedoch aktiviert ist, wird das Neulayout des plattformübergreifenden Social-Media-Widgets jetzt asynchron in einem separaten Prozess ausgeführt. Daher kann die Antwort jetzt auch 123 lauten, d.h. der alte width-Wert.

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 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.

Entlade-Handler können häufiger ein Zeitlimit erreichen

Wenn ein Frame gewechselt oder geschlossen wird, wird der unload-Handler für das alte Dokument sowie 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 Unload-Handler möglicherweise nicht vor dem Zeitlimit abgeschlossen werden, ist das Unload-Verhalten 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 wesentliche Konsequenzen, wenn Sie die Website-Isolierung aktivieren. Das Chrome-Team arbeitet daran, die Zuverlässigkeit von Unload-Handlern für gängige Anwendungsfälle nach Möglichkeit zu verbessern. Außerdem sind uns Fehler bekannt, bei denen Handler für das Entladen von Subframes bestimmte Funktionen noch nicht nutzen können, und arbeiten bereits an deren Behebung.

Ein wichtiger Anwendungsfall für Unload-Handler ist das Senden von Pings zum 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.