Google over het veranderen van de aanpak voor het verwerken van gemengde inhoud op pagina's die zijn geopend via HTTPS. Als er voorheen componenten op pagina's stonden die via HTTPS waren geopend en die zonder codering (via het http://-protocol) werden geladen, werd een speciale indicator weergegeven. In de toekomst is besloten om het laden van dergelijke bronnen standaard te blokkeren. Pagina's die via "https://" worden geopend, bevatten dus gegarandeerd alleen bronnen die zijn gedownload via een beveiligd communicatiekanaal.
Opgemerkt wordt dat momenteel meer dan 90% van de sites door Chrome-gebruikers wordt geopend via HTTPS. De aanwezigheid van zonder codering geladen inserts creëert veiligheidsrisico's door wijziging van onbeschermde inhoud als er controle is over het communicatiekanaal (bijvoorbeeld bij verbinding via open Wi-Fi). De indicator voor gemengde inhoud bleek ineffectief en misleidend voor de gebruiker, omdat deze geen duidelijke beoordeling geeft van de veiligheid van de pagina.
Momenteel worden de gevaarlijkste soorten mixed content, zoals scripts en iframes, al standaard geblokkeerd, maar afbeeldingen, audiobestanden en video’s kunnen nog steeds worden gedownload via http://. Door middel van beeldspoofing kan een aanvaller gebruikerstrackingcookies vervangen, kwetsbaarheden in beeldprocessors proberen te misbruiken of vervalsing plegen door de informatie in de afbeelding te vervangen.
De introductie van de blokkering is verdeeld in verschillende fasen. Chrome 79, gepland voor 10 december, zal een nieuwe instelling bevatten waarmee je de blokkering voor specifieke sites kunt uitschakelen. Deze instelling wordt toegepast op gemengde inhoud die al is geblokkeerd, zoals scripts en iframes, en wordt opgeroepen via het menu dat naar beneden komt wanneer u op het slotsymbool klikt, ter vervanging van de eerder voorgestelde indicator voor het uitschakelen van blokkering.
Chrome 80, dat op 4 februari wordt verwacht, zal een zacht blokkeringsschema gebruiken voor audio- en videobestanden, wat automatische vervanging van http://-links door https:// inhoudt, waardoor de functionaliteit behouden blijft als de problematische bron ook toegankelijk is via HTTPS . Afbeeldingen blijven zonder wijzigingen laden, maar als ze worden gedownload via http://, geven de https://-pagina's voor de hele pagina een indicator voor een onveilige verbinding weer. Om automatisch over te schakelen naar https of afbeeldingen te blokkeren, kunnen site-ontwikkelaars de CSP-eigenschappen upgrade-insecure-requests en block-all-mixed-content gebruiken. Chrome 81, gepland voor 17 maart, corrigeert automatisch http:// naar https:// voor gemengde afbeeldingsuploads.
Daarnaast Google over de integratie in een van de volgende releases van de Chome-browser van de nieuwe component Wachtwoordcontrole, eerder als . Integratie zal ertoe leiden dat er in de reguliere Chrome-wachtwoordbeheerder tools verschijnen voor het analyseren van de betrouwbaarheid van de door de gebruiker gebruikte wachtwoorden. Wanneer u probeert in te loggen op een site, worden uw gebruikersnaam en wachtwoord gecontroleerd aan de hand van een database met gecompromitteerde accounts, waarbij er een waarschuwing wordt weergegeven als er problemen worden gedetecteerd. De controle wordt uitgevoerd op een database die meer dan 4 miljard gecompromitteerde accounts omvat die in gelekte gebruikersdatabases voorkomen. Er wordt ook een waarschuwing weergegeven als u triviale wachtwoorden probeert te gebruiken, zoals "abc123" (by Google 23% van de Amerikanen gebruikt vergelijkbare wachtwoorden), of wanneer hetzelfde wachtwoord op meerdere sites wordt gebruikt.
Om de vertrouwelijkheid te behouden, worden bij toegang tot een externe API alleen de eerste twee bytes van de hash van de login en het wachtwoord verzonden (het hash-algoritme wordt gebruikt ). De volledige hash wordt gecodeerd met een sleutel die aan de kant van de gebruiker wordt gegenereerd. De originele hashes in de Google-database worden ook extra gecodeerd en alleen de eerste twee bytes van de hash blijven over voor indexering. De definitieve verificatie van hashes die onder het verzonden voorvoegsel van twee bytes vallen, wordt aan de kant van de gebruiker uitgevoerd met behulp van cryptografische technologie ““, waarin geen van beide partijen de inhoud kent van de gegevens die worden gecontroleerd. Om te voorkomen dat de inhoud van een database met gecompromitteerde accounts door brute kracht wordt bepaald met een verzoek om willekeurige voorvoegsels, worden de verzonden gegevens gecodeerd in combinatie met een sleutel die wordt gegenereerd op basis van een geverifieerde combinatie van login en wachtwoord.
Bron: opennet.ru