Firma Google o zmianie podejścia do obsługi mieszanej zawartości na stronach otwieranych za pomocą HTTPS. Wcześniej na stronach otwieranych za pomocą HTTPS, które miały komponenty ładowane bez szyfrowania (protokół http://), pojawiał się specjalny wskaźnik. W przyszłości zdecydowano o domyślnym blokowaniu ładowania takich zasobów. W ten sposób strony otwierane za pomocą "https://" będą gwarantowanie zawierać jedynie zasoby ładowane za pomocą bezpiecznego kanału komunikacji.
Zauważono, że obecnie ponad 90% stron jest otwieranych przez użytkowników Chrome z użyciem HTTPS. Obecność wstawek ładowanych bez szyfrowania stwarza zagrożenia naruszenia bezpieczeństwa poprzez modyfikację nieszyfrowanej zawartości w przypadku kontroli nad kanałem komunikacji (na przykład przy łączeniu przez otwarte Wi-Fi). Wskaźnik mieszanej zawartości uznano za nieskuteczny i wprowadzający użytkownika w błąd, ponieważ nie daje jednoznacznej oceny bezpieczeństwa strony.
Obecnie najbardziej niebezpieczne rodzaje mieszanej zawartości, takie jak skrypty i iframe, są już domyślnie blokowane, ale obrazy, pliki dźwiękowe i wideo nadal mogą być ładowane przez http://. Poprzez podmianę obrazów atakujący może umieścić śledzące działania użytkownika Cookie, spróbować wykorzystać luki w obsłudze obrazów lub dokonać oszustwa, zastępując informacje przedstawione na obrazie.
Wprowadzenie blokady podzielone jest na kilka etapów. W Chrome 79, planowanej na 10 grudnia, pojawi się nowe ustawienie, które pozwoli na wyłączenie blokady dla konkretnych stron. Wskazane ustawienie będzie stosowane do już blokowanej mieszanej zawartości, takiej jak skrypty i iframe, i będzie wywoływane poprzez menu rozwijane po kliknięciu na symbol kłódki, zastępując wcześniej oferowany wskaźnik do wyłączenia blokady.
W Chrome 80, który ma być wydany 4 lutego, wprowadzona zostanie łagodna schemat blokowania plików dźwiękowych i wideo, co oznacza automatyczną zamianę linków http:// na https://, co pozwoli na zachowanie funkcjonalności, jeśli problematyczny zasób będzie dostępny również przez HTTPS. Obrazy będą ładowane bez zmian, ale w przypadku ładowania przez http:// na stronach https:// dla całej strony zacznie być wyświetlany wskaźnik niezabezpieczonego połączenia. Aby automatycznie przekształcać na https lub blokować obrazy, twórcy witryn będą mogli skorzystać z właściwości CSP upgrade-insecure-requests i block-all-mixed-content. W wersji Chrome 81, zaplanowanej na 17 marca, podczas mieszanej ładowania obrazów zostanie zastosowana automatyczna zamiana http:// na https://.
Ponadto, firma Google integruje w jednym z następnych wydań przeglądarki Chrome nowy komponent Password Checkup, który wcześniej w postaci . Integracja doprowadzi do pojawienia się w wbudowanym menedżerze haseł Chrome narzędzi do analizy bezpieczeństwa używanych przez użytkownika haseł. Przy próbie logowania na dowolnej stronie nastąpi sprawdzenie loginu i hasła w bazie skompromitowanych kont, a w przypadku wykrycia problemów zostanie wyświetlone ostrzeżenie. Weryfikacja odbywa się na podstawie bazy, która obejmuje ponad 4 miliardy skompromitowanych kont, które pojawiły się w wyciekach baz użytkowników. Ostrzeżenie zostanie wyświetlone również przy próbie użycia trywialnych haseł, takich jak „abc123” (według Google 23% Amerykanów używa podobnych haseł), lub przy używaniu tego samego hasła na wielu stronach.
Aby zachować poufność przy korzystaniu z zewnętrznego API, przesyłane są tylko pierwsze dwa bajty hasha z kombinacji loginu i hasła (do haszowania używany jest algorytm ). Pełny hash jest szyfrowany kluczem generowanym po stronie użytkownika. Oryginalne hashe w bazie Google są również dodatkowo szyfrowane, a do indeksacji pozostawiane są tylko pierwsze dwa bajty hasha. Ostateczne porównanie hashy, które mieszczą się w przesłanym dwubajtowym prefiksie, odbywa się po stronie użytkownika przy użyciu kryptograficznej techniki „«, w którym żadna ze stron nie zna treści kontrolowanych danych. Aby chronić przed identyfikacją zawartości bazy skompromitowanych kont poprzez próby zgadywania za pomocą zapytań z losowymi prefiksami, przekazywane dane są szyfrowane związku z kluczem wygenerowanym na podstawie zestawienia loginu i hasła.
Źródło: opennet.ru
