Veröffentlichung des Webbrowser Chrome 136 mit Isolierung des Stils besuchter Links

Google hat die Version 136 des Webbrowsers Chrome veröffentlicht. Gleichzeitig ist eine stabile Version des Open-Source-Projekts Chromium verfügbar, das die Grundlage für Chrome bildet. Der Chrome-Browser unterscheidet sich von Chromium durch die Verwendung von Google-Logos, ein Benachrichtigungssystem bei Abstürzen, Module zur Wiedergabe von kopiergeschütztem Video-Content (DRM), ein automatisches Update-System, die permanente Aktivierung von Sandbox-Isolierung, die Bereitstellung von Schlüsseln für die Google-API und die Übertragung von RLZ-Parametern bei der Suche. Für Benutzer, die mehr Zeit für Updates benötigen, gibt es auch einen separaten Extended Stable-Zweig, der über einen Zeitraum von 8 Wochen unterstützt wird. Die nächste Version Chrome 137 ist für den 27. Mai geplant.

Die wichtigsten Änderungen in Chrome 136:

• Einführung eines Schutzmechanismus gegen die Offenlegung von Informationen über zuvor besuchte Seiten, die durch die Verwendung des CSS-Pseudoklasse «:visited» entsteht. Diese ermöglicht es, das Erscheinungsbild von zuvor geöffneten Links anzupassen. Bis zur Version Chrome 136 führte das Klicken auf einen Link zu einer Änderung der Darstellung dieses Links auf allen Websites, die diesen Link zeigten, unabhängig davon, von welcher Website der Besuch initiiert wurde. Auf seiner eigenen Website konnte ein Angreifer feststellen, ob ein Benutzer zuvor die für ihn interessanten Links geöffnet hatte, indem er die Änderung des Erscheinungsbildes dieser Links analysierte. Beispielsweise wird in einer Liste von Links zu verschiedenen Seiten der Browser zuvor besuchte Seiten in einer anderen Farbe markieren, was darauf hindeutet, ob diese Links zuvor geöffnet wurden.

  Um Informationslecks über besuchte Links in Chrome zu verhindern, wurde die Isolation der Verarbeitung des Selektors „:visited“ in Bezug auf die betrachtete Website implementiert. Das bedeutet, dass Elemente jetzt nur dann mit „:visited“ gestylt werden, wenn sie zuvor von der aktuellen Website geöffnet wurden und im Zusammenhang mit dem aktuellen iFrame stehen. Die Isolation erfolgt durch Hashing des Stils besuchter Links unter Verwendung eines Schlüssels, der aus drei Komponenten besteht: dem Link, der übergeordneten Website und dem Host, der im iFrame verwendet wird.

  

  Wenn von der Website „A“ auf einen Link geklickt wurde, wird dieser Link künftig nur auf der Website „A“ hervorgehoben und bleibt auf der Angreiferseite unverändert. Eine Ausnahme gilt nur für iFrames, die von der Hauptwebsite (same-origin) geladen werden, sowie für Links zur aktuellen Website. Somit werden beim Öffnen der Website „A“ Links, die zur Website „A“ führen, hervorgehoben, selbst wenn die Zugriffe von einer anderen Website stammen, während andere Links nur dann hervorgehoben werden, wenn die Zugriffe von der Website „A“ erfolgen.

  

  Im Firefox wurde 2010 ein Schutz gegen solche Lecks eingeführt, aber es gab Methoden, um diese zu umgehen. Zum Beispiel wurde in Firefox 122 im Jahr 2024 die Möglichkeit entfernt, die Farben von Pixeln über Filter zu analysieren, die den Parameter currentColor verwenden, sowie durch Manipulationen mit dem canvas-Tag in SVG.

• In der Android-Version wird die Übertragung an Server Google von Telemetriedaten zu über den Browser heruntergeladenen APK-Paketen realisiert. Bisher beschränkt sich die Funktionalität auf die Übermittlung von Telemetriedaten, in Zukunft wird sie jedoch verwendet, um Warnungen auszugeben und den Download von schädlichen APK-Dateien zu blockieren. Die Überprüfung erfolgt nur, wenn der erweiterte Schutzmodus im Browser aktiviert ist (Safe Browsing > Erweiterter Schutz).
• Für das Remote-Debugging ist nun die Angabe eines separaten Datenverzeichnisses erforderlich, das beim Start über den Parameter „—user-data-dir“ festgelegt wird. Dieser sollte zusammen mit dem Parameter „—remote-debugging-pipe“ oder „—remote-debugging-port“ angegeben werden. Bei Verwendung des Standardverzeichnisses unter Windows, Linux und macOS wird das Remote-Debugging nicht mehr funktionieren. Diese Änderung wurde eingeführt, um bösartiger Software entgegenzuwirken, die Remote-Debugging verwendet, um Daten aus Google Chrome zu extrahieren. Bei Verwendung eines separaten Verzeichnisses wird ein anderer Verschlüsselungsschlüssel angewandt, der den Zugriff auf die Arbeitsdaten des Benutzers im Hauptverzeichnis verhindert. Die Änderung gilt nur für Chrome und nicht für Chromium.
• Das Design der Bildlaufleisten wurde auf den Plattformen Linux und Windows modernisiert. Bei Inaktivität wird die Bildlaufleiste ausgeblendet und erscheint nur bei erneuter Bewegung auf der Seite. Für die Steuerung des neuen Designs der Bildlaufleisten wurden die Einstellungen chrome://flags#fluent-overlay-scrollbars und chrome://flags#fluent-scrollbars angeboten.
• In der CSS-Funktion attr() wurde der Typ-Parameter «string» in «raw-string» umbenannt, gemäß der Entscheidung der Arbeitsgruppe, die die Entwicklung der CSS-Spezifikationen koordiniert. Diese Änderung soll Verwirrung vermeiden, die durch die Ähnlichkeit der Ausdrücke «attr(foo type())» und «attr(foo string)» entsteht.
• Im ProgressEvent-API, das zur Erstellung von Fortschrittsanzeigen verwendet wird, wurde in den Attributen «loaded» und «total» anstelle des Typs «unsigned long long» der Typ «double» verwendet, was dem Verhalten des HTML-Elements entspricht und es ermöglicht, nicht ganze Werte reflektierend anzuzeigen, wie etwa eine Änderung von 0 bis 1.
• Zur Escape von Strings, die in regulären Ausdrücken verwendet werden, wurde die statische Methode «RegExp.escape» vorgeschlagen. Strings, die mit RegExp.escape escaped wurden, können sicher als Muster im Konstruktor RegExp() verwendet werden.
• Die Website darf automatisch Passkey-Schlüssel basierend auf bereits für diese Website gespeicherten Anmeldedaten generieren. Die Erstellung des Passkeys erfolgt ohne die Anzeige eines separaten modalen Dialogs, wenn der Benutzer zuvor für die Website die Erstellung von Anmeldedaten bestätigt hat.
• Die CSS-Eigenschaft dynamic-range-limit wurde hinzugefügt, um die maximale Helligkeit von HDR-Inhalten zu begrenzen.
• In den API-Spekulationsregeln (<script type=»speculationrules»>) für die Konfiguration der vorab geladenen Ressourcen ist es nun möglich, ein optionales Feld „tag“ zur Nachverfolgung der Quelle anzugeben. Der Inhalt dieses Feldes wird über den HTTP-Header Sec-Speculation-Tags gesendet.
• WebRTC und die API MediaRecorder unterstützen nun zusätzlich zu den zuvor unterstützten Codecs VP8, H.264, VP9 und AV1 auch den Codec H265 (HEVC).
• Die Möglichkeiten des Performance-Analyse-Panels in den Webentwicklertools wurden erweitert. Berichte über Anfragen, die das alte HTTP/1.1-Protokoll verwenden, die Effizienz der Cache-Nutzung und die Optimierung durch die Eigenschaft font-display wurden hinzugefügt. Auf der Seite „Datenschutz und Sicherheit > Datenschutz > Drittanbieter-Cookies“ wurde die Möglichkeit zur Suche nach einzelnen Cookies hinzugefügt. Eine experimentelle Funktion zur Anzeige von Hinweisen auf Probleme mit DOM-Elementen und -Attributen wurde ebenfalls eingeführt.

Neben neuen Funktionen und Fehlerbehebungen wurden in der neuen Version 8 Sicherheitsanfälligkeiten beseitigt. Viele dieser Schwachstellen wurden durch automatisierte Tests mit den Werkzeugen AddressSanitizer, MemorySanitizer, Control Flow Integrity, LibFuzzer und AFL identifiziert. Kritische Probleme, die es ermöglichen würden, alle Schutzebenen des Browsers zu umgehen und Code außerhalb der Sandbox-Umgebung auszuführen, wurden nicht festgestellt. Im Rahmen des Programms zur Belohnung von Entdeckungen von Sicherheitsanfälligkeiten hat Google für die aktuelle Version 4 Belohnungen in Höhe von insgesamt 10.000 US-Dollar ausgezahlt (eine Belohnung von 5.000 US-Dollar, zwei Belohnungen von 2.000 US-Dollar und eine von 1.000 US-Dollar).

Quelle: opennet.ru