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

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

Primijećeno je da trenutno više od 90% web stranica otvaraju korisnici Chromea koristeći HTTPS. Prisutnost umetaka učitanih bez enkripcije stvara sigurnosne prijetnje modificiranjem nezaštićenog sadržaja ako postoji kontrola nad komunikacijskim kanalom (na primjer, pri povezivanju putem otvorenog Wi-Fi-ja). Indikator mješovitog sadržaja pokazao se neučinkovitim i zavaravajućim za korisnika jer ne daje jasnu procjenu sigurnosti stranice.

Trenutačno su najopasnije vrste mješovitog sadržaja, poput skripti i iframeova, već blokirane prema zadanim postavkama, ali slike, audiodatoteke i videozapisi još uvijek se mogu preuzeti putem http://. Putem krivotvorenja slike, napadač može zamijeniti kolačiće za praćenje korisnika, pokušati iskoristiti ranjivosti u procesorima slike ili počiniti krivotvorinu zamjenom informacija navedenih na slici.

Uvođenje blokade podijeljeno je u nekoliko faza. Chrome 79, predviđen za 10. prosinca, sadržavat će novu postavku koja će vam omogućiti da onemogućite blokiranje za određene stranice. Ova će se postavka primijeniti na mješoviti sadržaj koji je već blokiran, kao što su skripte i iframeovi, a bit će pozvana kroz izbornik koji pada kada kliknete na simbol lokota, zamjenjujući prethodno predloženi indikator za onemogućavanje blokiranja.

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

Chrome 80, koji se očekuje 4. veljače, koristit će shemu mekog blokiranja za audio i video datoteke, što podrazumijeva automatsku zamjenu poveznica http:// s https://, što će sačuvati funkcionalnost ako je problematičnom resursu također moguće pristupiti putem 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 moći će koristiti CSP svojstva upgrade-insecure-requests i block-all-mixed-content. Chrome 81, zakazan za 17. ožujka, automatski će ispraviti http:// u https:// za mješovite prijenose slika.

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

Osim toga, Google najavio o integraciji nove komponente Password Checkup u jedno od sljedećih izdanja preglednika Chome, prethodno razvijanje u obliku vanjski dodatak. Integracija će dovesti do pojave alata za analizu pouzdanosti lozinki koje koristi korisnik u redovitom Chrome upravitelju zaporki. Kada se pokušate prijaviti na bilo koje mjesto, vaša prijava i lozinka provjerit će se u bazi podataka kompromitiranih računa, s upozorenjem prikazanim ako se otkriju problemi. Provjera se provodi prema bazi podataka koja pokriva više od 4 milijarde kompromitiranih računa koji su se pojavili u procurjelim bazama podataka korisnika. Također će se prikazati upozorenje ako pokušate koristiti trivijalne lozinke kao što je "abc123" (od statistika Google 23% Amerikanaca koristi slične lozinke) ili kada koristi istu zaporku na više stranica.

Kako bi se održala povjerljivost, kada se pristupa vanjskom API-ju, prenose se samo prva dva bajta hasha za prijavu i lozinku (koristi se algoritam raspršivanja Argon 2). Cijeli hash je šifriran ključem koji se generira na strani korisnika. Izvorni hashovi u Google bazi također su dodatno kriptirani te su samo prva dva bajta hash-a ostavljena za indeksiranje. Konačna provjera hasheva koji potpadaju pod preneseni dvobajtni prefiks obavlja se na strani korisnika pomoću kriptografske tehnologije “sljepoća“, u kojem niti jedna strana ne zna sadržaj podataka koji se provjeravaju. Kako bi se zaštitio od utvrđivanja sadržaja baze podataka kompromitiranih računa brutalnom silom sa zahtjevom za proizvoljnim prefiksima, preneseni podaci su šifrirani u vezi s ključem generiranim na temelju provjerene kombinacije imena i lozinke.

Izvor: opennet.ru

Dodajte komentar