Chrome begynder at blokere HTTP-ressourcer på HTTPS-sider og tjekker styrken af ​​adgangskoder

Google advarede om at ændre tilgangen til behandling af blandet indhold på sider, der åbnes via HTTPS. Tidligere, hvis der var komponenter på sider åbnet via HTTPS, som blev indlæst fra uden kryptering (via http://-protokollen), blev der vist en særlig indikator. I fremtiden er det besluttet at blokere indlæsningen af ​​sådanne ressourcer som standard. Således vil sider, der åbnes via "https://", kun indeholde ressourcer, der er downloadet via en sikker kommunikationskanal.

Det bemærkes, at mere end 90 % af webstederne i øjeblikket åbnes af Chrome-brugere, der bruger HTTPS. Tilstedeværelsen af ​​indsatser indlæst uden kryptering skaber sikkerhedstrusler gennem ændring af ubeskyttet indhold, hvis der er kontrol over kommunikationskanalen (f.eks. når der oprettes forbindelse via åben Wi-Fi). Indikatoren for blandet indhold viste sig at være ineffektiv og vildledende for brugeren, da den ikke giver en klar vurdering af sidens sikkerhed.

I øjeblikket er de farligste typer blandet indhold, såsom scripts og iframes, allerede blokeret som standard, men billeder, lydfiler og videoer kan stadig downloades via http://. Gennem billedspoofing kan en angriber erstatte brugersporingscookies, forsøge at udnytte sårbarheder i billedprocessorer eller begå forfalskning ved at erstatte informationen i billedet.

Indførelsen af ​​blokeringen er opdelt i flere faser. Chrome 79, der er planlagt til den 10. december, vil have en ny indstilling, der giver dig mulighed for at deaktivere blokering for bestemte websteder. Denne indstilling vil blive anvendt på blandet indhold, der allerede er blokeret, såsom scripts og iframes, og vil blive kaldt op gennem menuen, der falder ned, når du klikker på låsesymbolet, og erstatter den tidligere foreslåede indikator for deaktivering af blokering.

Chrome begynder at blokere HTTP-ressourcer på HTTPS-sider og tjekker styrken af ​​adgangskoder

Chrome 80, som forventes den 4. februar, vil bruge et blødt blokeringsskema for lyd- og videofiler, hvilket indebærer automatisk udskiftning af http://-links med https://, hvilket vil bevare funktionaliteten, hvis den problematiske ressource også er tilgængelig via HTTPS . Billeder vil fortsætte med at indlæse uden ændringer, men hvis de downloades via http://, vil https://-siderne vise en usikker forbindelsesindikator for hele siden. For automatisk at skifte til https eller blokere billeder, vil webstedsudviklere være i stand til at bruge CSP-egenskaberne upgrade-insecure-requests og block-all-mixed-content. Chrome 81, der er planlagt til den 17. marts, vil automatisk rette http:// til https:// for blandede billeduploads.

Chrome begynder at blokere HTTP-ressourcer på HTTPS-sider og tjekker styrken af ​​adgangskoder

Desuden Google annonceret om integrationen i en af ​​de næste udgivelser af Chome-browseren af ​​den nye Password Checkup-komponent, tidligere udvikle sig som ekstern tilføjelse. Integration vil føre til fremkomsten i den almindelige Chrome-adgangskodemanager af værktøjer til at analysere pålideligheden af ​​de adgangskoder, der bruges af brugeren. Når du forsøger at logge ind på et hvilket som helst websted, vil dit login og din adgangskode blive tjekket mod en database med kompromitterede konti, med en advarsel, hvis der opdages problemer. Kontrollen udføres mod en database, der dækker mere end 4 milliarder kompromitterede konti, der dukkede op i lækkede brugerdatabaser. En advarsel vil også blive vist, hvis du forsøger at bruge trivielle adgangskoder såsom "abc123" (af statistik Google 23 % af amerikanerne bruger lignende adgangskoder), eller når de bruger den samme adgangskode på flere websteder.

For at bevare fortroligheden, når du får adgang til en ekstern API, overføres kun de første to bytes af hashen af ​​login og adgangskode (hash-algoritmen bruges Argon 2). Den fulde hash er krypteret med en nøgle genereret på brugerens side. De originale hashes i Google-databasen er også yderligere krypteret, og kun de første to bytes af hashen er tilbage til indeksering. Den endelige verifikation af hashes, der falder ind under det transmitterede to-byte præfiks, udføres på brugerens side ved hjælp af kryptografisk teknologi "blindhed", hvor ingen af ​​parterne kender indholdet af de data, der kontrolleres. For at beskytte mod, at indholdet af en database med kompromitterede konti bestemmes af brute force med en anmodning om vilkårlige præfikser, krypteres de transmitterede data i forbindelse med en nøgle, der er genereret på basis af en verificeret kombination af login og adgangskode.

Kilde: opennet.ru

Tilføj en kommentar