Google sul cambiamento dell'approccio al trattamento dei contenuti misti su pagine aperte tramite HTTPS. In precedenza, su pagine aperte tramite HTTPS, veniva visualizzato un indicatore speciale in presenza di componenti caricati senza crittografia (tramite il protocollo http://). In futuro, si è deciso di bloccare il caricamento di tali risorse per impostazione predefinita. Pertanto, le pagine aperte su "https://" conterranno garantitamente solo risorse caricate tramite canali di comunicazione protetti.
Si osserva che attualmente oltre il 90% dei siti è aperto dagli utenti Chrome utilizzando HTTPS. La presenza di inserimenti caricati senza crittografia crea minacce di violazione della sicurezza tramite la modifica dei contenuti non protetti in presenza di controllo sul canale di comunicazione (ad esempio, durante la connessione tramite Wi-Fi aperti). L'indicatore di contenuti misti è stato riconosciuto come inefficace e fuorviante per l'utente, poiché non fornisce una valutazione chiara della sicurezza della pagina.
Attualmente, i tipi di contenuti misti più pericolosi, come script e iframe, vengono già bloccati di default, ma immagini, file audio e video possono ancora essere caricati tramite http://. Sostituendo le immagini, un attaccante può inserire cookie per tracciare le azioni dell'utente, tentare di sfruttare vulnerabilità nei gestori delle immagini o falsificare informazioni sostituendo quelle mostrate nell'immagine.
L'introduzione del blocco è suddivisa in più fasi. In Chrome 79, previsto per il 10 dicembre, verrà introdotta una nuova impostazione che consentirà di disattivare il blocco per siti specifici. Tale impostazione sarà applicata ai contenuti misti già bloccati, come script e iframe, e potrà essere attivata tramite il menu a discesa cliccando sull'icona del lucchetto, sostituendo l'indicatore precedentemente proposto per disattivare il blocco.
Nel Chrome 80, previsto per il 4 febbraio, verrà applicato un sistema di blocco morbido per i file audio e video, che comporta la sostituzione automatica dei link da http:// a https://, permettendo di mantenere la funzionalità se la risorsa problematica è disponibile anche via HTTPS. Le immagini continueranno a caricarsi senza modifiche, ma nel caso di caricamenti tramite http:// su pagine https://, verrà visualizzato un indicatore di connessione non sicura per l'intera pagina. Per la sostituzione automatica su https o il blocco delle immagini, i sviluppatori web potranno usare le proprietà CSP upgrade-insecure-requests e block-all-mixed-content. Nella versione 81 di Chrome, prevista per il 17 marzo, verrà applicata automaticamente la sostituzione di http:// con https:// durante il caricamento misto delle immagini.
Inoltre, Google integra in uno dei prossimi rilasci del browser Chrome un nuovo componente Password Checkup, precedentemente in forma di . L'integrazione porterà all'aggiunta nel gestore password di Chrome di strumenti per analizzare l'affidabilità delle password utilizzate dall'utente. Durante il tentativo di accesso a qualsiasi sito, verrà eseguita una verifica del login e della password contro un database di account compromessi, con un avviso in caso di problemi rilevati. La verifica avviene su un database che copre oltre 4 miliardi di account compromessi apparsi nelle perdite di dati degli utenti. Verrà visualizzato un avviso anche quando si tenterà di utilizzare password triviali, come «abc123» (Google rileva che il 23% degli americani utilizza password simili), o quando si utilizza la stessa password su più siti. Google 23% degli americani utilizzano password simili), o quando si utilizza la stessa password su più siti.
Per mantenere la riservatezza, durante l'interazione con API esterne vengono inviati solo i primi due byte dell'hash della combinazione di login e password (l'algoritmo di hashing utilizzato è ). L'hash completo è crittografato con una chiave generata dal lato dell'utente. Gli hash originali nel database di Google sono ulteriormente crittografati e solo i primi due byte dell'hash vengono lasciati per l'indicizzazione. La verifica finale degli hash che rientrano nel prefisso di due byte fornito avviene lato utente utilizzando la tecnica crittografica ««, in cui nessuna delle parti conosce il contenuto dei dati verificati. Per proteggere contro la determinazione del contenuto del database di account compromessi attraverso tentativi casuali di prefissi, i dati restituiti sono crittografati in associazione con una chiave generata sulla base della coppia di credenziali di accesso verificata.
Fonte: opennet.ru
