Chrome će početi blokirati HTTP resurse na HTTPS stranicama i provjeravati snagu lozinki

Google upozoren o promjeni pristupa obradi mješovitog sadržaja na stranicama otvorenim putem HTTPS-a. Ranije, ako su na stranicama otvorenim putem HTTPS-a postojale komponente koje su učitane bez enkripcije (preko http:// protokola), bio je prikazan poseban indikator. U budućnosti je odlučeno da se blokira učitavanje takvih resursa prema zadanim postavkama. Stoga će stranice otvorene putem “https://” zajamčeno sadržavati samo resurse preuzete putem sigurnog komunikacijskog kanala.

Napominje se da trenutno više od 90% stranica otvaraju korisnici Chromea koristeći HTTPS. Prisustvo umetaka učitanih bez enkripcije stvara sigurnosne prijetnje modifikacijom nezaštićenog sadržaja ako postoji kontrola nad komunikacijskim kanalom (na primjer, pri povezivanju putem otvorenog Wi-Fi-ja). Pokazalo se da je indikator mješovitog sadržaja neefikasan i obmanjujući korisnika, jer ne daje jasnu procjenu sigurnosti stranice.

Trenutno su najopasniji tipovi mješovitog sadržaja, kao što su skripte i iframeovi, već blokirani prema zadanim postavkama, ali slike, audio datoteke i video zapisi i dalje se mogu preuzeti putem http://. Putem lažiranja slika, napadač može zamijeniti kolačiće za praćenje korisnika, pokušati iskoristiti ranjivosti u procesorima slika ili počiniti krivotvorenje zamjenom informacija datih na slici.

Uvođenje blokade podijeljeno je u nekoliko faza. Chrome 79, najavljen za 10. decembar, imat će novu postavku koja će vam omogućiti da onemogućite blokiranje za određene web lokacije. Ova postavka će se primijeniti na mješoviti sadržaj koji je već blokiran, kao što su skripte i iframeovi, i biće pozvana kroz meni koji se spušta kada kliknete na simbol katanca, zamjenjujući prethodno predloženi indikator za onemogućavanje blokiranja.

Chrome će početi blokirati HTTP resurse na HTTPS stranicama i provjeravati snagu lozinki

Chrome 80, koji se očekuje 4. februara, koristit će šemu mekog blokiranja audio i video datoteka, što podrazumijeva automatsku zamjenu http:// linkova sa https://, što će sačuvati funkcionalnost ako je problematični resurs dostupan i preko HTTPS-a . Slike će se nastaviti učitavati bez promjena, ali ako se preuzmu putem http://, https:// stranice će prikazati indikator nesigurne veze za cijelu stranicu. Za automatsku promjenu na https ili blokiranje slika, programeri web mjesta će moći koristiti CSP svojstva upgrade-insecure-requests i block-all-mixed-content. Chrome 81, zakazan za 17. mart, će automatski ispraviti http:// u https:// za miješano otpremanje slika.

Chrome će početi blokirati HTTP resurse na HTTPS stranicama i provjeravati snagu lozinki

Pored toga, Google najavljeno o integraciji nove komponente Password Checkup u jedno od narednih izdanja pretraživača Chome razvija u obliku eksterni dodatak. Integracija će dovesti do pojave u redovnom Chrome menadžeru lozinki alata za analizu pouzdanosti lozinki koje koristi korisnik. Kada pokušate da se prijavite na bilo koju stranicu, vaša prijava i lozinka će biti provjereni u odnosu na bazu podataka kompromitovanih naloga, uz upozorenje ako se otkriju problemi. Provjera se vrši prema bazi podataka koja pokriva više od 4 milijarde kompromitovanih naloga koji su se pojavili u bazama podataka korisnika koji su procurili. Upozorenje će se također prikazati ako pokušate koristiti trivijalne lozinke kao što je "abc123" (od statistika Google 23% Amerikanaca koristi slične lozinke) ili kada koriste istu lozinku na više stranica.

Da bi se održala povjerljivost, prilikom pristupa vanjskom API-ju, prenose se samo prva dva bajta hash login i lozinke (koristi se algoritam heširanja Argon2). Potpuni hash je šifriran ključem koji se generira na strani korisnika. Originalni hešovi u Google bazi su također dodatno šifrirani i samo prva dva bajta heša ostaju za indeksiranje. Konačna provjera hashova koji potpadaju pod preneseni dvobajtni prefiks provodi se na strani korisnika korištenjem kriptografske tehnologije "zasljepljivanje“, u kojem nijedna strana ne zna sadržaj podataka koji se provjeravaju. Kako bi se zaštitio od toga da se sadržaj baze podataka kompromitovanih naloga utvrdi grubom silom sa zahtjevom za proizvoljnim prefiksima, prenijeti podaci se šifriraju u vezi sa ključem generiranim na osnovu provjerene kombinacije login-a i lozinke.

izvor: opennet.ru

Dodajte komentar