Google Chrome
Google har advaret om en ændret tilgang til håndtering af blandet indhold på sider åbnet via HTTPS. Tidligere hvis der var komponenter på åbne sider med HTTPS indlæst uden kryptering (ved hjælp af http: // -protokollen) blev en særlig prompt vist.
Nu blev det besluttet at blokere for indlæsningen af disse ressourcer til de næste versioner af browseren Standard. Derfor sikres det, at de sider, der åbnes via "https: //", kun indeholder ressourcer, der er indlæst via en sikker kommunikationskanal.
Det bemærkes, at Chrome-brugere i øjeblikket åbner mere end 90% af siderne, der bruger HTTPS. Tilstedeværelsen af indsatte downloads, der er downloadet uden kryptering, skaber en trussel om sikkerhedsbrud gennem modifikation af usikkert indhold i nærvær af kontrol over kommunikationskanalen (for eksempel ved tilslutning via åben Wi-Fi).
Indikatoren for blandet indhold anerkendes som ineffektiv og vildledende, da det ikke tilbyder en utvetydig vurdering af sidens sikkerhed.
Currently, de farligste typer blandet indhold, som f.eks. scripts og iframes, er allerede blokeret som standard, men billeder, lydfiler og videoer kan stadig downloades via “http: //”.
Ved at erstatte billeder kan angriberen erstatte cookiesporingshandlinger, forsøge at udnytte sårbarheder i billedbehandlere eller begå en forfalskning og erstatte de oplysninger, der vises i billedet.
Indførelsen af blokaden er opdelt i flere faser. I Chrome 79 (som er planlagt til 10. december), En ny indstilling vises, der deaktiverer blokering af bestemte websteder.
De specificerede indstillinger vil blive anvendt på blandet indhold, der allerede er blokeret, såsom scripts og iframes, og aktiveres via den menu, der vises, når du klikker på låsesymbolet og erstatter den tidligere foreslåede indikator for at deaktivere låsen.
Mens for Chrome 80 (forventes 4. februar) et låseskema vil blive brugt til lyd- og videofiler, som involverer automatisk udskiftning fra http: // til https: //, som holder den i funktion, hvis problemressourcen også er tilgængelig via HTTPS.
Billeder fortsætter med at uploade uændret, men i tilfælde af download via http: // på https: // sider for hele siden, startes en indikator for en usikker forbindelse. Til automatisk erstatning med https eller blokering af billeder vil webstedsudviklere være i stand til at bruge opdaterede-usikre anmodninger og blokere alt indhold-blandet CSP-egenskaber.
Lanceringen af Chrome 81, planlagt til 17. marts, bruger Autokorrektur fra http: // til https: // til download af blandede billeder.
Derudover annoncerede Google integration i en af de næste versioner af Chome-browseren, en ny komponent af Adgangskodekontrol, tidligere udviklet som et eksternt plugin.
Integrationen vil føre til optræden i fuldtidsadgangskodeadministratoren Chrome-værktøjer til at analysere pålideligheden af de anvendte adgangskoder af brugeren. Når du prøver at komme ind på et hvilket som helst sted, bliver brugernavnet og adgangskoden verificeret i databasen over kompromitterede konti med en advarsel i tilfælde af problemer.
Validering udføres på en database, der dækker mere end 4 milliarder kompromitterede konti der præsenteres i lækager af brugerdatabaser. En advarsel vises også, når du prøver at bruge trivielle adgangskoder som "abc123" (Google-statistik 23% af amerikanerne bruger disse adgangskoder), eller når de bruger den samme adgangskode på flere sider.
For at bevare fortrolighed overføres kun de første to byte af hashen fra forbindelsen fra login og adgangskode (Argon2-algoritmen bruges til hashen), når du får adgang til den eksterne API. Den fulde hash er krypteret med en brugergenereret nøgle.
De originale hashes i Google-databasen er også krypteret, og kun de første to bytes af hashen er tilbage til indeksering.
For at beskytte mod bestemmelse af indholdet af den kompromitterede kontodatabase ved at tælle med tilfældige præfikser er de returnerede data krypteret i forhold til den genererede nøgle baseret på det bekræftede login- og adgangskodelink.
kilde: https://security.googleblog.com