Chrome beginnt damit, HTTP-Ressourcen auf HTTPS-Seiten zu blockieren und die Stärke von Passwörtern zu überprüfen

Google warnte über die Änderung des Ansatzes zur Verarbeitung gemischter Inhalte auf Seiten, die über HTTPS geöffnet werden. Bisher wurde ein spezieller Hinweis angezeigt, wenn sich auf über HTTPS geöffneten Seiten Komponenten befanden, die unverschlüsselt (über das http://-Protokoll) geladen wurden. Für die Zukunft wurde beschlossen, das Laden solcher Ressourcen standardmäßig zu blockieren. Somit wird garantiert, dass Seiten, die über „https://“ geöffnet werden, nur Ressourcen enthalten, die über einen sicheren Kommunikationskanal heruntergeladen wurden.

Es wird darauf hingewiesen, dass derzeit mehr als 90 % der Websites von Chrome-Benutzern über HTTPS geöffnet werden. Das Vorhandensein von unverschlüsselt geladenen Einfügungen stellt Sicherheitsbedrohungen durch die Änderung ungeschützter Inhalte dar, wenn die Kontrolle über den Kommunikationskanal besteht (z. B. bei einer Verbindung über offenes WLAN). Der Mixed-Content-Indikator erwies sich als unwirksam und für den Nutzer irreführend, da er keine klare Einschätzung der Sicherheit der Seite liefert.

Derzeit sind die gefährlichsten Arten gemischter Inhalte wie Skripte und Iframes bereits standardmäßig blockiert, Bilder, Audiodateien und Videos können jedoch weiterhin über http:// heruntergeladen werden. Durch Bild-Spoofing kann ein Angreifer Cookies zur Benutzerverfolgung ersetzen, versuchen, Schwachstellen in Bildprozessoren auszunutzen, oder eine Fälschung begehen, indem er die im Bild bereitgestellten Informationen ersetzt.

Die Einführung der Sperrung gliedert sich in mehrere Stufen. Chrome 79, geplant für den 10. Dezember, wird eine neue Einstellung enthalten, mit der Sie die Blockierung für bestimmte Websites deaktivieren können. Diese Einstellung wird auf gemischte Inhalte angewendet, die bereits blockiert sind, wie z. B. Skripte und Iframes, und wird über das Dropdown-Menü aufgerufen, wenn Sie auf das Schlosssymbol klicken, und ersetzt den zuvor vorgeschlagenen Indikator zur Deaktivierung der Blockierung.

Chrome beginnt damit, HTTP-Ressourcen auf HTTPS-Seiten zu blockieren und die Stärke von Passwörtern zu überprüfen

Chrome 80, das für den 4. Februar erwartet wird, wird ein Soft-Blocking-Schema für Audio- und Videodateien verwenden, das eine automatische Ersetzung von http://-Links durch https:// impliziert, wodurch die Funktionalität erhalten bleibt, wenn auf die problematische Ressource auch über HTTPS zugegriffen werden kann . Bilder werden weiterhin ohne Änderungen geladen, aber wenn sie über http:// heruntergeladen werden, wird auf den https://-Seiten für die gesamte Seite ein Hinweis auf eine unsichere Verbindung angezeigt. Um automatisch zu https zu wechseln oder Bilder zu blockieren, können Website-Entwickler die CSP-Eigenschaften „upgrade-insecure-requests“ und „block-all-mixed-content“ verwenden. Chrome 81 ist für den 17. März geplant und korrigiert http:// automatisch zu https:// für gemischte Bild-Uploads.

Chrome beginnt damit, HTTP-Ressourcen auf HTTPS-Seiten zu blockieren und die Stärke von Passwörtern zu überprüfen

Darüber hinaus Google kündigte die über die Integration der neuen Password Checkup-Komponente in eine der nächsten Versionen des Chome-Browsers Entwicklung als externe Ergänzung. Durch die Integration werden im regulären Chrome-Passwort-Manager Tools zur Analyse der Zuverlässigkeit der vom Benutzer verwendeten Passwörter angezeigt. Wenn Sie versuchen, sich auf einer Website anzumelden, werden Ihre Anmeldedaten und Ihr Passwort mit einer Datenbank gefährdeter Konten abgeglichen. Bei Problemen wird eine Warnung angezeigt. Die Prüfung erfolgt anhand einer Datenbank, die mehr als 4 Milliarden kompromittierte Konten umfasst, die in durchgesickerten Benutzerdatenbanken aufgetaucht sind. Eine Warnung wird auch angezeigt, wenn Sie versuchen, triviale Passwörter wie „abc123“ (von) zu verwenden Statistik Google (23 % der Amerikaner verwenden ähnliche Passwörter) oder wenn dasselbe Passwort auf mehreren Websites verwendet wird.

Um die Vertraulichkeit zu wahren, werden beim Zugriff auf eine externe API nur die ersten beiden Bytes des Hashs von Login und Passwort übertragen (es wird der Hashing-Algorithmus verwendet). argonxnumx). Der vollständige Hash wird mit einem benutzerseitig generierten Schlüssel verschlüsselt. Auch die Original-Hashes in der Google-Datenbank werden zusätzlich verschlüsselt und es bleiben nur die ersten beiden Bytes des Hashes für die Indizierung übrig. Die endgültige Überprüfung der Hashes, die unter das übertragene Zwei-Byte-Präfix fallen, erfolgt auf der Benutzerseite mithilfe kryptografischer Technologie.Blindheit„, bei dem keine Partei den Inhalt der überprüften Daten kennt. Zum Schutz davor, dass der Inhalt einer Datenbank kompromittierter Konten mit der Anforderung willkürlicher Präfixe brutal ermittelt wird, werden die übertragenen Daten in Verbindung mit einem Schlüssel verschlüsselt, der auf Basis einer verifizierten Kombination aus Login und Passwort generiert wird.

Source: opennet.ru

Kommentar hinzufügen