Google Chrome
Google heeft gewaarschuwd voor een verandering in de aanpak van gemengde inhoud op pagina's geopend via HTTPS. Eerder, als er componenten op geopende pagina's waren met HTTPS geladen zonder codering (met behulp van het http: // -protocol), werd een speciale prompt weergegeven.
Nu werd voor de volgende versies van de browser besloten om het laden van deze bronnen te blokkeren standaard. Daarom wordt ervoor gezorgd dat de pagina's die worden geopend via "https: //" alleen bronnen bevatten die zijn geladen via een beveiligd communicatiekanaal.
Opgemerkt wordt dat momenteel Chrome-gebruikers meer dan 90% van de sites openen met HTTPS. De aanwezigheid van zonder versleuteling gedownloade inserts vormt een dreiging van inbreuk op de beveiliging door de wijziging van onveilige inhoud in aanwezigheid van controle over het communicatiekanaal (bijvoorbeeld bij verbinding via open Wi-Fi).
De gemengde inhoudindicator wordt erkend als ondoelmatig en misleidend, omdat het geen eenduidige beoordeling van de veiligheid van de pagina biedt.
nog, de gevaarlijkste soorten gemengde inhoud, zoals scripts en iframes, zijn al geblokkeerd standaard, maar afbeeldingen, geluidsbestanden en video's kunnen nog steeds worden gedownload via "http: //".
Door afbeeldingen te vervangen, kan de aanvaller cookietracking-acties vervangen, kwetsbaarheden in beeldprocessors proberen te misbruiken of een vervalsing plegen, waarbij de informatie in de afbeelding wordt vervangen.
De introductie van de blokkade is opgedeeld in verschillende fasen. In Chrome 79 (die is gepland voor 10 december), Er verschijnt een nieuwe instelling die het blokkeren van specifieke sites uitschakelt.
De opgegeven instellingen worden toegepast op gemengde inhoud die al is geblokkeerd, zoals scripts en iframes, en worden geactiveerd via het menu dat verschijnt wanneer u op het slotsymbool klikt, ter vervanging van de eerder voorgestelde indicator om het blokkeren te deactiveren.
Terwijl voor Chrome 80 (verwacht op 4 februari) er wordt een blokkeringsschema gebruikt voor audio- en videobestanden, wat automatische vervanging van http: // naar https: // inhoudt, waardoor het blijft werken als de probleembron ook beschikbaar is via HTTPS.
Afbeeldingen blijven ongewijzigd uploaden, maar in het geval van downloaden via http: // op https: // pagina's voor de hele pagina, zal een indicator van een onveilige verbinding worden geïnitieerd. Voor automatische vervanging door https of blokafbeeldingen kunnen site-ontwikkelaars bijgewerkte-onveilige-verzoeken-en-alle-inhoud-gemengde CSP-eigenschappen gebruiken.
De lancering van Chrome 81, gepland voor 17 maart, gebruikt AutoCorrectie van http: // tot https: // voor het downloaden van gemengde afbeeldingen.
Bovendien kondigde Google aan integratie in een van de volgende versies van de Chome-browser, een nieuw onderdeel van Wachtwoordcontrole, eerder ontwikkeld als een externe plug-in.
De integratie zal leiden tot het verschijnen in de fulltime wachtwoordbeheerder Chrome-tools om de betrouwbaarheid van de gebruikte wachtwoorden te analyseren door de gebruiker. Wanneer u een site probeert binnen te gaan, worden de gebruikersnaam en het wachtwoord vergeleken met de database met gecompromitteerde accounts met een waarschuwing in geval van problemen.
Validatie vindt plaats op een database die meer dan 4 miljard gecompromitteerde accounts omvat die worden gepresenteerd in lekken van gebruikersdatabases. Er wordt ook een waarschuwing weergegeven wanneer u probeert om triviale wachtwoorden te gebruiken, zoals "abc123" (Google-statistieken 23% van de Amerikanen gebruikt deze wachtwoorden), of wanneer ze hetzelfde wachtwoord op meerdere sites gebruiken.
Om de vertrouwelijkheid te behouden, worden bij toegang tot de externe API alleen de eerste twee bytes van de hash overgedragen van de verbinding vanaf de login en het wachtwoord (het Argon2-algoritme wordt gebruikt voor de hash). De volledige hash is versleuteld met een door de gebruiker gegenereerde sleutel.
De originele hashes in de Google-database worden ook extra versleuteld en alleen de eerste twee bytes van de hash blijven voor indexering over.
Om te voorkomen dat de inhoud van de gecompromitteerde accountdatabase wordt bepaald door opsomming met willekeurige prefixen, worden de geretourneerde gegevens versleuteld ten opzichte van de gegenereerde sleutel op basis van de geverifieerde login- en wachtwoordlink.
bron: https://security.googleblog.com