Google Chrome
Google ostrzega przed zmianą podejścia do obsługi mieszanych treści na stronach otwieranych przez HTTPS. Poprzednio, jeśli na otwartych stronach znajdują się komponenty z załadowanym HTTPS bez szyfrowania (używając protokołu http: //), został wyświetlony specjalny monit.
Teraz dla kolejnych wersji przeglądarki zdecydowano się zablokować ładowanie tych zasobów domyślna. W związku z tym zostanie zapewnione, że strony otwierane za pośrednictwem „https: //” zawierają tylko zasoby ładowane za pośrednictwem bezpiecznego kanału komunikacyjnego.
Obserwuje się, że obecnie użytkownicy Chrome otwierają ponad 90% witryn przy użyciu protokołu HTTPS. Obecność wkładek pobranych bez szyfrowania stwarza zagrożenie naruszenia bezpieczeństwa poprzez modyfikację niezabezpieczonych treści w obecności kontroli nad kanałem komunikacyjnym (na przykład podczas łączenia się przez otwarte Wi-Fi).
Wskaźnik zawartości mieszanej jest uznawany za nieskuteczny i wprowadzający w błąd, ponieważ nie zapewnia jednoznacznej oceny bezpieczeństwa strony.
Obecnie najniebezpieczniejsze typy treści mieszanych, takie jak skrypty i ramki iframe, są już zablokowane Domyślnie, ale obrazy, pliki dźwiękowe i wideo można nadal pobierać przez „http: //”.
Podpisując obrazy, atakujący może podmienić działania śledzące pliki cookie, spróbować wykorzystać luki w procesorach obrazów lub popełnić fałszerstwo, zastępując informacje przedstawione na obrazie.
Wprowadzenie blokady podzielone jest na kilka etapów. W Chrome 79 (zaplanowany na 10 grudnia), Pojawi się nowe ustawienie, które wyłączy blokowanie określonych witryn.
Określone ustawienia zostaną zastosowane do już zablokowanych treści mieszanych, takich jak skrypty i ramki iframe, i zostaną aktywowane za pośrednictwem menu wyświetlanego po kliknięciu symbolu kłódki, zastępując wcześniej proponowany wskaźnik dezaktywacji blokowania.
Podczas gdy w Chrome 80 (oczekiwana 4 lutego) dla plików audio i wideo zostanie zastosowany schemat blokowania, co wiąże się z automatyczną zamianą z http: // na https: //, dzięki czemu będzie działać, jeśli zasób powodujący problem jest również dostępny przez HTTPS.
Obrazy będą nadal przesyłane bez zmian, ale w przypadku pobierania przez http: // na stronach https: // dla całej strony, zostanie zainicjowany wskaźnik niezabezpieczonego połączenia. W celu automatycznego zastąpienia obrazami https lub blokowymi programiści witryn będą mogli używać właściwości CSP zaktualizowanych-niezabezpieczonych-żądań-i blokowych-mieszanych ze wszystkimi treściami.
Uruchomienie Chrome 81, zaplanowany na 17 marca, użyje Autokorekty od http: // do https: // do pobierania obrazów mieszanych.
Ponadto ogłosił Google integracja z jedną z kolejnych wersji przeglądarki Chome, nowy składnik Sprawdzanie hasła, wcześniej opracowany jako zewnętrzna wtyczka.
Integracja doprowadzi do pojawienia się w pełnoetatowym menedżerze haseł Narzędzia Chrome przeanalizować wiarygodność używanych haseł przez użytkownika. Przy próbie wejścia na jakąkolwiek witrynę nazwa użytkownika i hasło zostaną sprawdzone w bazie danych kont, które zostały przejęte, z ostrzeżeniem w przypadku problemów.
Walidacja odbywa się w bazie danych, która obejmuje ponad 4 miliardy kont, których bezpieczeństwo zostało naruszone które są prezentowane w wyciekach baz danych użytkowników. Ostrzeżenie zostanie również wyświetlone podczas próby użycia trywialnych haseł, takich jak „abc123” (w statystykach Google 23% Amerykanów używa tych haseł) lub gdy używają tego samego hasła w wielu witrynach.
Aby zachować poufność, podczas uzyskiwania dostępu do zewnętrznego API, tylko pierwsze dwa bajty skrótu są przesyłane z połączenia z loginu i hasła (do hasha używany jest algorytm Argon2). Pełny skrót jest szyfrowany za pomocą klucza wygenerowanego przez użytkownika.
Oryginalne skróty w bazie danych Google są również dodatkowo szyfrowane i do indeksowania pozostają tylko dwa pierwsze bajty skrótu.
Aby zabezpieczyć się przed określeniem zawartości bazy danych kont, które zostały naruszone, poprzez wyliczenie losowymi prefiksami, zwracane dane są szyfrowane względem wygenerowanego klucza na podstawie zweryfikowanego linku do loginu i hasła.
źródło: https://security.googleblog.com