Google om Àndringar i hanteringen av blandat innehÄll pÄ sidor som öppnas via HTTPS. Tidigare visades en speciell indikator om det pÄ sidor som öppnas med HTTPS fanns komponenter som laddades utan kryptering (via http://). I framtiden kommer det att beslutas att blockera sÄdana resurser som standard. DÀrmed kommer sidor som öppnas via 'https://' garanterat att endast innehÄlla resurser som laddats via en sÀker kommunikationskanal.
Det noteras att för nÀrvarande öppnas mer Àn 90 % av webbplatser av Chrome-anvÀndare med hjÀlp av HTTPS. Förekomsten av inslag som laddas utan kryptering skapar sÀkerhetshot genom att modifiera oskyddat innehÄll nÀr kanalens kommunikation kontrolleras (till exempel vid anslutning via öppna Wi-Fi). Indikatorn för blandat innehÄll anses vara ineffektiv och vilseledande, eftersom den inte ger en entydig bedömning av sidans sÀkerhet.
För nÀrvarande blockeras de farligaste formerna av blandat innehÄll, sÄsom skript och iframe, redan som standard, men bilder, ljudfiler och videor kan fortfarande laddas via http://. Genom att byta ut bilder kan en angripare infoga spÄrande cookies för anvÀndarens aktivitet, försöka utnyttja sÄrbarheter i bildhanterare eller bedra genom att ersÀtta informationen som visas i bilden.
Införandet av blockeringen Àr uppdelat pÄ flera faser. I Chrome 79, planerad den 10 december, kommer det att finnas en ny instÀllning som gör det möjligt att inaktivera blockeringen för specifika webbplatser. Den angivna instÀllningen kommer att tillÀmpas pÄ redan blockerad blandat innehÄll, sÄsom skript och iframe, och kan nÄs via menyn som dyker upp nÀr man klickar pÄ lÄssymbolen, vilket ersÀtter den tidigare föreslagna indikatorn för att inaktivera blockeringen.
I Chrome 80, som förvÀntas den 4 februari, kommer en mjuk blockering av ljud- och videofiler att tillÀmpas, vilket innebÀr en automatisk ersÀttning av lÀnkar frÄn http:// till https://, vilket gör att funktionaliteten bibehÄlls om den problematiska resursen ocksÄ Àr tillgÀnglig via HTTPS. Bilder kommer att fortsÀtta laddas utan förÀndringar, men om de laddas via http:// pÄ https:// sidor kommer en indikator för osÀker anslutning att visas för hela sidan. För automatisk ersÀttning till https eller blockering av bilder kan webbplatsutvecklare anvÀnda CSP-egenskaperna upgrade-insecure-requests och block-all-mixed-content. I Chrome 81, planerad till den 17 mars, kommer automatisk ersÀttning frÄn http:// till https:// att tillÀmpas vid blandad bildladdning.
Dessutom har företaget Google i form av . Integreringen kommer att leda till att standardlösenordshanteraren i Chrome fÄr verktyg för att analysera sÀkerheten hos de lösenord som anvÀndaren anvÀnder. Vid inloggningsförsök pÄ vilken webbplats som helst kommer en kontroll av anvÀndarnamn och lösenord att utföras mot databasen med komprometterade konton, med en varning som visas om problem upptÀcks. Kontrollningen görs mot en databas som omfattar mer Àn 4 miljarder komprometterade konton som förekommit i lÀckor av anvÀndardata. En varning kommer Àven att visas vid försök att anvÀnda triviala lösenord, sÄsom "abc123" (enligt Google anvÀnder 23% av amerikanerna sÄdana lösenord), eller vid anvÀndning av samma lösenord pÄ flera webbplatser. För att bevara sekretessen vid anvÀndning av ett externt API överförs endast de första tvÄ byte av hash frÄn kombinationen av anvÀndarnamn och lösenord (hash-algoritmen
Argon2 blindning», dÀr ingen av parterna kÀnner till innehÄllet i de kontrollerade uppgifterna. För att skydda mot identifiering av innehÄllet i databasen med komprometterade konton genom att pröva godtyckliga prefixar, krypteras de levererade uppgifterna kopplade till en nyckel som genererats baserat pÄ den kontrollerade kombinationen av anvÀndarnamn och lösenord.
KĂ€lla: opennet.ru
