Website-Isolierung für Webentwickler

Mathias Bynens

In Chrome 67 für Computer ist eine neue Funktion namens Website-Isolierung standardmäßig aktiviert. Dieses wird erklärt, worum es bei der Website-Isolierung geht, warum sie notwendig ist und warum Webentwickler sollten Sie sich dessen bewusst sein.

Was ist Website-Isolierung?

Das Internet ist unter anderem dafür gedacht, sich Katzenvideos anzusehen und Krypto-Wallets zu verwalten. Sie würden aber nicht wollen, dass fluffycats.example Zugriff auf Ihre wertvollen Kryptocoins hat! Glücklicherweise Websites können dank der Funktion Same-Origin im Browser in der Regel nicht auf die Daten der anderen zugreifen. Richtlinie. Schädliche Websites können diese Richtlinie dennoch umgehen, um andere Websites anzugreifen. Gelegentlich werden Sicherheitslücken im Browsercode gefunden, der die Same-Origin-Policy erzwingt. Die Das Chrome-Team hat sich zum Ziel gesetzt, solche Fehler so schnell wie möglich zu beheben.

Die Website-Isolierung ist eine Sicherheitsfunktion in Chrome, die eine zusätzliche Abwehrlinie darstellt. dass solche Angriffe weniger erfolgreich sein werden. Es stellt sicher, dass Seiten von verschiedenen Websites immer in verschiedene Prozesse aufgeteilt, die jeweils in einer Sandbox ausgeführt werden, die die zulässigen Aktionen des Prozesses einschränkt. Außerdem wird der Prozess daran gehindert, bestimmte Arten sensibler Daten von anderen Websites zu empfangen. Als Mit der Website-Isolierung ist es für schädliche Websites wesentlich schwieriger, spekulativen Seitenkanalangriffe wie Spectre, um Daten von anderen Websites zu stehlen. Wenn das Chrome-Team fertig ist, zusätzliche Maßnahmen ergriffen werden, hilft die Website-Isolierung auch, selbst wenn die Seite eines Angreifers einige der Regeln in einem eigenen Prozess.

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

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

Cross-Origin Read Blocking

Auch wenn alle websiteübergreifenden Seiten in separaten Prozessen platziert werden, können Seiten trotzdem legitime Anfragen einige websiteübergreifende Unterressourcen wie Bilder und JavaScript. Eine schädliche Webseite könnte <img>-Element, um eine JSON-Datei mit sensiblen Daten wie Ihrem Bankkonto 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 gelangt der Inhalt der JSON-Datei in den Arbeitsspeicher des Renderers Dabei stellt der Renderer fest, dass das Bildformat ungültig ist und nicht ein Bild. Der Angreifer könnte dann jedoch eine Sicherheitslücke wie Spectre ausnutzen, um diese Teil des Gedächtnisses.

Anstatt <img> zu verwenden, könnte der Angreifer auch <script> nutzen, um die sensiblen Daten zu speichern. Arbeitsspeicher:

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

Cross-Origin Read Blocking (CORB) ist eine neue Sicherheitsfunktion, die verhindert, balance.json darf je nach MIME-Typ nie in den Arbeitsspeicher des Rendererprozessspeichers gelangen.

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 Herkunft oder von anderen Quellen mit moderate CORS-Header wie Access-Control-Allow-Origin: * Medienressourcen können jedoch aus beliebigen auch ohne moderate CORS-Header.

CORB verhindert, dass der Renderer-Prozess eine ursprungsübergreifende Datenressource empfängt, d.h. HTML, XML oder JSON) verwenden, wenn:

  • Die Ressource hat einen X-Content-Type-Options: nosniff-Header
  • 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, CORB versucht, den Antworttext zu untersuchen, um festzustellen, ob es sich um HTML, XML oder JSON handelt. Dies ist Dies ist notwendig, da einige Webserver falsch konfiguriert sind und Bilder beispielsweise als text/html bereitstellen.

Datenressourcen, die durch die CORB-Richtlinie blockiert werden, werden dem Prozess als leer angezeigt, obwohl erfolgt die Anfrage weiterhin im Hintergrund. Infolgedessen hat eine schädliche Webseite Schwierigkeiten, Website-übergreifende Daten zum Datendiebstahl in den Prozess einschleusen.

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

  • Kennzeichnen Sie Antworten mit der richtigen Content-Type-Kopfzeile. HTML-Ressourcen sollten beispielsweise als text/html bereitgestellt, JSON-Ressourcen mit ein JSON-MIME-Typ und XML-Ressourcen mit einen XML-MIME-Typ).
  • Verwende den X-Content-Type-Options: nosniff-Header, um das Sniffing zu deaktivieren. Ohne diesen Header Chrome führt eine kurze Inhaltsanalyse durch, um zu überprüfen, ob der Typ korrekt ist. Antworten zulassen, um z. B. JavaScript-Dateien nicht zu blockieren, ist es besser, aktiv selbst das Richtige zu tun.

Weitere Informationen finden Sie in der CORB für Webentwickler oder ausführliche CORB-Erklärung.

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

Größtenteils ist die Website-Isolierung eine Browserfunktion im Hintergrund, die sich nicht direkt Webentwicklern zugänglich sind. Es gibt zum Beispiel keine neue, über das Web zugängliche API. Im Allgemeinen Seiten sollten 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 , die sich auf Ihre Website auswirken können. Wir halten eine Liste bekannter Probleme mit der Website-Isolierung, Im Folgenden werden die wichtigsten Punkte näher erläutert.

Das ganzseitige Layout ist nicht mehr synchron.

Mit der Website-Isolierung ist das synchrone Vollbildlayout nicht mehr garantiert, da die Frames der kann eine Seite über mehrere Prozesse verteilt sein. Dies kann sich auf Seiten auswirken, wenn sie annehmen, Layoutänderungen werden sofort für alle Frames auf der Seite übernommen.

Nehmen wir als Beispiel eine Website namens fluffykittens.example, die mit einem Widget für soziale Netzwerke, gehostet auf social-widget.example:

<!-- 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. Die FluffyKittens-Seite ändert die Breite auf 456 Pixel (ausgelöstes Layout) und sendet eine Nachricht an das Widget für soziale Netzwerke mit folgendem Code:

<!-- 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 empfängt, protokolliert es die Breite sein <html>-Stammelement.

Welcher Breitenwert wird protokolliert? Vor der Aktivierung der Website-Isolierung durch Chrome lautete die Antwort 456. Zugriff document.documentElement.clientWidth erzwingt das Layout, das vor Chrome synchron war. Website-Isolierung aktiviert. Wenn die Website-Isolierung jedoch aktiviert ist, Das Layout-Re-Layout erfolgt jetzt asynchron in einem separaten Prozess. Daher kann die Antwort jetzt auch 123, d.h. der alte width-Wert.

Wenn eine Seite die Größe eines ursprungsübergreifenden <iframe> ändert und dann eine postMessage an sie sendet, mit Website-Isolierung der Empfänger-Frame kennt ihre neue Größe beim Empfang der Nachricht möglicherweise noch nicht. Mehr Im Allgemeinen werden dadurch Seiten beschädigt, wenn davon auszugehen ist, dass eine Layoutänderung sofort auf alle Frames auf der Seite platzieren.

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

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

Wenn durch einen Frame gewechselt oder geschlossen wird, gilt das alte Dokument und alle darin eingebetteten Subframe-Dokumente führen alle ihren unload-Handler aus. Erfolgt die neue Navigation im selben Renderer-Prozess (z.B. für Navigation am selben Ursprung), können die unload-Handler des alten Dokuments und seiner Subframes für beliebig lange warten, bevor der Commit der neuen Navigation zugelassen wird.

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

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

Aber auch ohne Website-Isolierung sind einige Hauptframe-Navigationen prozessübergreifend, was Auswirkungen auf Unload-Handler-Verhalten. Wenn Sie beispielsweise von old.example nach new.example navigieren, die URL in die Adressleiste eingeben, wird die new.example-Navigation in einem neuen Prozess ausgeführt. Das Entladen Die Handler für old.example und die zugehörigen Subframes werden im Hintergrund im old.example-Prozess ausgeführt. nachdem die new.example-Seite angezeigt wird, und die alten Unload-Handler werden beendet, wenn sie die innerhalb einer bestimmten Zeit abgeschlossen werden. Da die Unload-Handler möglicherweise nicht vor dem Zeitlimit abgeschlossen werden, ist das Unload-Verhalten weniger zuverlässig.

Mit der Website-Isolierung werden alle websiteübergreifenden Navigationen prozessübergreifend, sodass Dokumente von verschiedene Websites haben keinen gemeinsamen Prozess. Daher trifft die oben genannte Situation auf mehr Fälle und Unload-Handler in <iframe>s haben oft das Hintergrund- und Zeitüberschreitungsverhalten beschrieben.

Ein weiterer Unterschied, der sich aus der Website-Isolierung ergibt, ist die neue parallele Sortierung der Unload-Handler: werden Unload-Handler ohne Website-Isolierung in einer strikten Top-down-Reihenfolge über Frames hinweg ausgeführt. Aber mit Website Isolation, Unload-Handler werden parallel über verschiedene Prozesse ausgeführt.

Dies sind wesentliche Folgen, wenn Sie die Website-Isolierung aktivieren. Das Chrome-Team arbeitet an Verbesserung der Zuverlässigkeit von Unload-Handlern für gängige Anwendungsfälle, wo möglich. Außerdem Es wurden Programmfehler gefunden, bei denen Handler für das Entladen von Subframes bestimmte Funktionen noch nicht nutzen können und an der Lösung arbeiten.

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

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

Ein besserer Ansatz, der angesichts dieser Änderung robuster ist, ist die Verwendung von navigator.sendBeacon stattdessen:

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 Informationen in Ihrem Konten auf anderen Websites zu verwalten, indem jede Website in einem eigenen Prozess isoliert wird. Dabei versucht CORB, um Ressourcen mit sensiblen Daten aus dem Renderer-Prozess zu entfernen. Mit den oben genannten Empfehlungen um diese neuen Sicherheitsfunktionen optimal zu nutzen.

Dank der Alex Moshchuk, Charlie Reis, Jason Miller, Nasko Oskow Philip Walton, Shubhie Panicker und Thomas Steiner dieses Artikels lesen und Feedback geben.