Google über die Änderung des Ansatzes zur Verarbeitung von gemischtem Inhalt auf Seiten, die über HTTPS geöffnet werden. Früher wurde bei Vorhandensein von Komponenten auf Seiten, die über HTTPS geöffnet werden und von unverschlüsselter Quelle (über http://) geladen wurden, ein spezieller Indikator angezeigt. In Zukunft wurde beschlossen, das Laden solcher Ressourcen standardmäßig zu blockieren. Somit werden Seiten, die über "https://" geöffnet werden, garantiert nur Ressourcen enthalten, die über einen sicheren Kommunikationskanal geladen wurden.
Es wird festgestellt, dass derzeit über 90 % der Websites von Chrome-Nutzern mit HTTPS geöffnet werden. Das Vorhandensein von unverschlüsselten Einfügungen schafft Sicherheitsrisiken durch die Modifikation von unsicherem Inhalt bei Kontrolle über den Kommunikationskanal (z. B. bei der Verbindung über offenes WLAN). Der Indikator für gemischten Inhalt wurde als ineffektiv und irreführend anerkannt, da er keine eindeutige Bewertung der Sicherheit der Seite bietet.
Derzeit werden die gefährlichsten Arten von gemischten Inhalten, wie Skripte und iframes, standardmäßig blockiert, jedoch können Bilder, Audiodateien und Videos weiterhin über http:// geladen werden. Durch das Ersetzen von Bildern kann ein Angreifer Tracking-Cookies einfügen, Schwachstellen in Bildverarbeitern ausnutzen oder manipulative Tricks anwenden, indem er die auf dem Bild dargestellten Informationen ersetzt.
Die Einführung der Blockierung erfolgt in mehreren Phasen. In Chrome 79, das für den 10. Dezember geplant ist, wird eine neue Einstellung verfügbar sein, die das Deaktivieren der Blockierung für bestimmte Websites ermöglicht. Diese Einstellung wird für bereits blockierte gemischte Inhalte wie Skripte und iframes angewendet und kann über das Menü aufgerufen werden, das beim Klicken auf das Schloss-Symbol angezeigt wird und den zuvor angebotenen Indikator zum Deaktivieren der Blockierung ersetzt.
In Chrome 80, which is expected on February 4, a gentle blocking scheme for audio and video files will be implemented, involving the automatic replacement of links from http:// to https://, which will maintain functionality if the problematic resource is also available via HTTPS. Images will continue to load unchanged, but if loading occurs via http:// on https:// pages, an indicator of an insecure connection will be displayed for the entire page. For automatic replacement to https or blocking images, developers can use CSP properties such as upgrade-insecure-requests and block-all-mixed-content. In Chrome 81, scheduled for March 17, automatic replacement from http:// to https:// will be applied during mixed image loading.
Furthermore, Google is integrating a new component called Password Checkup into one of the upcoming versions of the Chrome browser, which was previously in Form von . Die Integration wird im standardmäßigen Passwort-Manager von Chrome Funktionen zur Analyse der Sicherheit der vom Benutzer verwendeten Passwörter beinhalten. Bei einem Login-Versuch auf einer Website wird der Benutzername und das Passwort gegen eine Datenbank mit kompromittierten Konten überprüft und es wird eine Warnung ausgegeben, falls Probleme festgestellt werden. Die Überprüfung erfolgt anhand einer Datenbank, die über 4 Milliarden kompromittierte Konten umfasst, die in Datenlecks aufgetaucht sind. Eine Warnung wird auch ausgegeben, wenn triviale Passwörter verwendet werden, wie „abc123“ (laut Google nutzen 23 % der Amerikaner solche Passwörter), oder wenn dasselbe Passwort auf mehreren Websites verwendet wird. Google 23% американцев используют подобные пароли), или при использовании одного и того же пароля на нескольких сайтах.
Um die Privatsphäre zu wahren, werden beim Zugriff auf eine externe API nur die ersten zwei Bytes des Hashes aus der Kombination von Benutzername und Passwort übermittelt (zum Hashen wird der Algorithmus ). Der vollständige Hash wird mit einem auf der Nutzerseite generierten Schlüssel verschlüsselt. Die ursprünglichen Hashes in der Google-Datenbank werden zudem verschlüsselt und es werden nur die ersten zwei Bytes des Hashes zur Indizierung hinterlegt. Die endgültige Überprüfung von Hashes, die unter dem übergebenen zwei Byte langen Präfix fallen, erfolgt auf der Nutzerseite mithilfe der kryptografischen Technik „«, bei der keine der beiden Seiten den Inhalt der überprüften Daten kennt. Um zu verhindern, dass der Inhalt der Datenbank mit kompromittierten Konten durch das Testen willkürlicher Präfixe ermittelt wird, werden die zurückgegebenen Daten in Abhängigkeit von einem Schlüssel verschlüsselt, der auf der überprüften Kombination aus Benutzername und Passwort basiert.
Quelle: opennet.ru
