Google despre schimbarea abordării procesării conținutului mixt pe paginile deschise prin HTTPS. Anterior, dacă pe paginile deschise prin HTTPS existau componente care erau încărcate fără criptare (prin protocolul http://), era afișat un indicator special. În viitor, s-a decis blocarea în mod implicit a încărcării unor astfel de resurse. Astfel, paginile deschise prin „https://” vor fi garantate că vor conține doar resurse descărcate printr-un canal de comunicare securizat.
Este de remarcat că în prezent, peste 90% dintre site-uri sunt deschise de utilizatorii Chrome folosind HTTPS. Prezența inserțiilor încărcate fără criptare creează amenințări de securitate prin modificarea conținutului neprotejat dacă există control asupra canalului de comunicare (de exemplu, la conectarea prin Wi-Fi deschis). S-a constatat că indicatorul de conținut mixt este ineficient și înșelător pentru utilizator, deoarece nu oferă o evaluare clară a securității paginii.
În prezent, cele mai periculoase tipuri de conținut mixt, cum ar fi scripturile și cadrele iframe, sunt deja blocate în mod implicit, dar imaginile, fișierele audio și videoclipurile pot fi încă descărcate prin http://. Prin falsificarea imaginii, un atacator poate înlocui cookie-urile de urmărire a utilizatorului, poate încerca să exploateze vulnerabilitățile procesoarelor de imagine sau să comită falsuri prin înlocuirea informațiilor furnizate în imagine.
Introducerea blocării este împărțită în mai multe etape. Chrome 79, programat pentru 10 decembrie, va include o nouă setare care vă va permite să dezactivați blocarea pentru anumite site-uri. Această setare va fi aplicată conținutului mixt care este deja blocat, cum ar fi scripturile și cadrele iframe, și va fi apelată prin meniul care se derulează când dați clic pe simbolul de blocare, înlocuind indicatorul propus anterior pentru dezactivarea blocării.
Chrome 80, care este așteptat pe 4 februarie, va folosi o schemă de blocare soft pentru fișierele audio și video, implicând înlocuirea automată a link-urilor http:// cu https://, ceea ce va păstra funcționalitatea dacă resursa problematică este accesibilă și prin HTTPS . Imaginile vor continua să se încarce fără modificări, dar dacă sunt descărcate prin http://, paginile https:// vor afișa un indicator de conexiune nesigură pentru întreaga pagină. Pentru a schimba automat la https sau a bloca imaginile, dezvoltatorii site-ului vor putea folosi proprietățile CSP-ului-solicitari-upgrade-insecure-și bloc-tot-conținutul-mixt. Chrome 81, programat pentru 17 martie, va corecta automat http:// la https:// pentru încărcările de imagini mixte.
În plus, Google despre integrarea într-una dintre următoarele versiuni ale browserului Chome a noii componente Password Checkup, anterior în formă . Integrarea va duce la apariția în managerul obișnuit de parole Chrome a instrumentelor de analiză a fiabilității parolelor utilizate de utilizator. Când încercați să vă conectați la orice site, datele dvs. de conectare și parola vor fi verificate cu o bază de date de conturi compromise, cu un avertisment afișat dacă sunt detectate probleme. Verificarea este efectuată pe baza unei baze de date care acoperă peste 4 miliarde de conturi compromise care au apărut în bazele de date de utilizatori scurse. De asemenea, va fi afișat un avertisment dacă încercați să utilizați parole banale, cum ar fi „abc123” (prin Google 23% dintre americani folosesc parole similare) sau când folosesc aceeași parolă pe mai multe site-uri.
Pentru a menține confidențialitatea, la accesarea unui API extern, sunt transmisi doar primii doi octeți ai hash-ului de autentificare și a parolei (se folosește algoritmul de hashing ). Hash-ul complet este criptat cu o cheie generată din partea utilizatorului. Hashurile originale din baza de date Google sunt, de asemenea, criptate suplimentar și doar primii doi octeți ai hashului sunt lăsați pentru indexare. Verificarea finală a hashurilor care se încadrează sub prefixul de doi octeți transmis este efectuată de către utilizator folosind tehnologia criptografică "„, în care niciuna dintre părți nu cunoaște conținutul datelor care sunt verificate. Pentru a proteja împotriva determinării prin forță brută a conținutului unei baze de date de conturi compromise cu o solicitare de prefixe arbitrare, datele transmise sunt criptate în legătură cu o cheie generată pe baza unei combinații verificate de autentificare și parolă.
Sursa: opennet.ru