Google om att ändra tillvägagångssättet för att bearbeta blandat innehåll på sidor som öppnas via HTTPS. Tidigare, om det fanns komponenter på sidor öppnade via HTTPS som laddades från utan kryptering (via http://-protokollet), visades en speciell indikator. I framtiden har det beslutats att blockera laddningen av sådana resurser som standard. Således kommer sidor som öppnas via "https://" att garanteras endast innehålla resurser som laddats ner via en säker kommunikationskanal.
Det noteras att för närvarande öppnas mer än 90 % av webbplatserna av Chrome-användare som använder HTTPS. Förekomsten av inlägg som laddas utan kryptering skapar säkerhetshot genom modifiering av oskyddat innehåll om det finns kontroll över kommunikationskanalen (till exempel vid anslutning via öppen Wi-Fi). Indikatorn för blandat innehåll visade sig vara ineffektiv och vilseledande för användaren, eftersom den inte ger en tydlig bedömning av sidans säkerhet.
För närvarande är de farligaste typerna av blandat innehåll, som skript och iframes, redan blockerade som standard, men bilder, ljudfiler och videor kan fortfarande laddas ner via http://. Genom bildspoofing kan en angripare ersätta användarspårningscookies, försöka utnyttja sårbarheter i bildprocessorer eller begå förfalskning genom att ersätta informationen i bilden.
Införandet av blockeringen är uppdelad i flera steg. Chrome 79, planerad till den 10 december, kommer att ha en ny inställning som gör att du kan inaktivera blockering för specifika webbplatser. Den här inställningen kommer att tillämpas på blandat innehåll som redan är blockerat, såsom skript och iframes, och kommer att anropas via menyn som rullar ner när du klickar på låssymbolen, och ersätter den tidigare föreslagna indikatorn för att inaktivera blockering.
Chrome 80, som väntas den 4 februari, kommer att använda ett mjukt blockeringsschema för ljud- och videofiler, vilket innebär att http://-länkar automatiskt ersätts med https://, vilket kommer att bevara funktionaliteten om den problematiska resursen också är tillgänglig via HTTPS . Bilder kommer att fortsätta att laddas utan ändringar, men om de laddas ner via http://, kommer https://-sidorna att visa en osäker anslutningsindikator för hela sidan. För att automatiskt ändra till https eller blockera bilder kommer webbplatsutvecklare att kunna använda CSP-egenskaperna upgrade-insecure-requests och block-all-mixed-content. Chrome 81, planerad till 17 mars, kommer automatiskt att korrigera http:// till https:// för blandade bilduppladdningar.
Dessutom Google om integreringen av den nya lösenordskontrollkomponenten i en av nästa versioner av webbläsaren Chome, tidigare i formen . Integration kommer att leda till att det dyker upp verktyg i den vanliga lösenordshanteraren i Chrome för att analysera tillförlitligheten hos de lösenord som används av användaren. När du försöker logga in på en webbplats kontrolleras din inloggning och ditt lösenord mot en databas med inträngda konton, med en varning som visas om problem upptäcks. Kontrollen utförs mot en databas som omfattar mer än 4 miljarder inträngda konton som dök upp i läckta användardatabaser. En varning kommer också att visas om du försöker använda triviala lösenord som "abc123" (av Google 23 % av amerikanerna använder liknande lösenord), eller när de använder samma lösenord på flera webbplatser.
För att upprätthålla konfidentialitet, vid åtkomst till ett externt API, överförs endast de första två byten av hashen för inloggning och lösenord (hashalgoritmen används ). Den fullständiga hashen krypteras med en nyckel som genereras på användarens sida. De ursprungliga hasharna i Googles databas är också extra krypterade och endast de två första byten av hashen är kvar för indexering. Den slutliga verifieringen av hash som faller under det överförda två-byte prefixet utförs på användarens sida med hjälp av kryptografisk teknik "", där ingen av parterna känner till innehållet i de uppgifter som kontrolleras. För att skydda mot att innehållet i en databas med komprometterade konton bestäms av brute force med en begäran om godtyckliga prefix, krypteras den överförda datan i samband med en nyckel som genereras på basis av en verifierad kombination av inloggning och lösenord.
Källa: opennet.ru