Google Chrome
Google har advart om en endring i tilnærmingen til håndtering av blandet innhold på sider som er åpnet via HTTPS. Tidligere, hvis det var komponenter på åpne sider med HTTPS lastet inn uten kryptering (ved hjelp av http: // protokollen) ble en spesiell ledetekst vist.
Nå, for de neste versjonene av nettleseren, ble det besluttet å blokkere innlastingen av disse ressursene misligholde. Derfor vil det sikres at sidene som åpnes via "https: //" bare inneholder ressurser lastet gjennom en sikker kommunikasjonskanal.
Det observeres at Chrome-brukere for tiden åpner mer enn 90% av nettstedene som bruker HTTPS. Tilstedeværelsen av innlegg som er lastet ned uten kryptering, skaper en trussel om sikkerhetsbrudd gjennom modifisering av usikkert innhold i nærvær av kontroll over kommunikasjonskanalen (for eksempel når du kobler til via åpent Wi-Fi).
Indikatoren for blandet innhold er anerkjent som ineffektiv og villedende, siden det ikke gir en utvetydig vurdering av sikkerheten på siden.
Tiden, de farligste typene av blandet innhold, som skript og iframes, er allerede blokkert som standard, men bilder, lydfiler og videoer kan fortsatt lastes ned via “http: //”.
Ved å erstatte bilder, kan angriperen erstatte sporingshandlinger for informasjonskapsler, prøve å utnytte sårbarheter i bildebehandlere eller begå en forfalskning, og erstatte informasjonen som presenteres i bildet.
Innføringen av blokaden er delt inn i flere trinn. I Chrome 79 (som er planlagt til 10. desember), En ny innstilling vises som vil deaktivere blokkering av bestemte nettsteder.
De angitte innstillingene vil bli brukt på blandet innhold som allerede er blokkert, for eksempel skript og iframes, og vil bli aktivert gjennom menyen som vises når du klikker på låsesymbolet, og erstatter den tidligere foreslåtte indikatoren for å deaktivere låsen.
Mens for Chrome 80 (forventes 4. februar) et låseskjema vil bli brukt for lyd- og videofiler, som innebærer automatisk erstatning fra http: // til https: // som vil holde den i orden hvis problemressursen også er tilgjengelig via HTTPS.
Bilder vil fortsette å lastes opp uendret, men i tilfelle nedlasting via http: // på https: // sider for hele siden, vil en indikator for en usikker forbindelse startes. For automatisk erstatning med https eller blokkering av bilder, vil nettstedsutviklere kunne bruke oppdaterte-usikre forespørsler-og blokker alt innhold-blandet CSP-egenskaper.
Lanseringen av Chrome 81, planlagt til 17. mars, vil bruke autokorrigering fra http: // til https: // for nedlastede bilder.
I tillegg kunngjorde Google integrering i en av de neste versjonene av Chome-nettleseren, en ny komponent av Passordkontroll, tidligere utviklet som et eksternt plugin.
Integrasjonen vil føre til utseendet i heltidspassordbehandling Chrome-verktøy for å analysere påliteligheten til passordene som brukes av brukeren. Når du prøver å gå inn på et hvilket som helst nettsted, blir brukernavnet og passordet bekreftet mot databasen med kompromitterte kontoer med en advarsel i tilfelle problemer.
Validering skjer i en database som dekker mer enn 4 milliarder kompromitterte kontoer som presenteres i lekkasjer av brukerdatabaser. En advarsel vises også når du prøver å bruke trivielle passord som "abc123" (Google-statistikk 23% av amerikanerne bruker disse passordene), eller når de bruker det samme passordet på flere nettsteder.
For å bevare konfidensialiteten, når du får tilgang til det eksterne API-et, blir bare de to første bytene av hasjen overført fra forbindelsen fra pålogging og passord (Argon2-algoritmen brukes til hasjen). Full hash er kryptert med en brukergenerert nøkkel.
De originale hasjene i Google-databasen er også kryptert, og bare de to første bytene av hasjen gjenstår for indeksering.
For å beskytte mot å bestemme innholdet i den kompromitterte kontodatabasen ved å oppregne med tilfeldige prefikser, blir de returnerte dataene kryptert i forhold til den genererte nøkkelen basert på den bekreftede koblingen for pålogging og passord.
Fuente: https://security.googleblog.com