Chrome inizierà a bloccare le risorse HTTP sulle pagine HTTPS e a verificare la sicurezza delle password

Google Ha avvertito sulla modifica dell'approccio all'elaborazione dei contenuti misti sulle pagine aperte tramite HTTPS. In precedenza, se su pagine aperte tramite HTTPS erano presenti componenti caricati senza crittografia (tramite il protocollo http://), veniva visualizzato un indicatore speciale. In futuro si è deciso di bloccare di default il caricamento di tali risorse. Pertanto, sarà garantito che le pagine aperte tramite “https://” contengano solo risorse scaricate tramite un canale di comunicazione sicuro.

Va osservato che attualmente oltre il 90% dei siti vengono aperti dagli utenti di Chrome utilizzando HTTPS. La presenza di inserti caricati senza crittografia crea minacce alla sicurezza attraverso la modifica di contenuti non protetti se si ha il controllo sul canale di comunicazione (ad esempio, quando ci si connette tramite Wi-Fi aperto). L’indicatore di contenuto misto è risultato inefficace e fuorviante per l’utente, in quanto non fornisce una valutazione chiara della sicurezza della pagina.

Attualmente i tipi più pericolosi di contenuti misti, come script e iframe, sono già bloccati per impostazione predefinita, ma è ancora possibile scaricare immagini, file audio e video tramite http://. Attraverso lo spoofing delle immagini, un utente malintenzionato può sostituire i cookie di tracciamento dell'utente, tentare di sfruttare le vulnerabilità nei processori di immagini o commettere contraffazioni sostituendo le informazioni fornite nell'immagine.

L'introduzione del blocco è suddivisa in più fasi. Chrome 79, previsto per il 10 dicembre, presenterà una nuova impostazione che consentirà di disattivare il blocco per siti specifici. Questa impostazione verrà applicata ai contenuti misti già bloccati, come script e iframe, e verrà richiamata tramite il menu che scende quando si clicca sul simbolo del lucchetto, sostituendo l'indicatore precedentemente proposto per la disattivazione del blocco.

Chrome 80, previsto per il 4 febbraio, utilizzerà uno schema di soft blocking per file audio e video, che implica la sostituzione automatica dei collegamenti http:// con https://, che ne preserverà la funzionalità se la risorsa problematica è accessibile anche tramite HTTPS . Le immagini continueranno a caricarsi senza modifiche, ma se scaricate tramite http://, le pagine https:// visualizzeranno un indicatore di connessione non sicura per l'intera pagina. Per passare automaticamente a https o bloccare le immagini, gli sviluppatori del sito potranno utilizzare le proprietà CSP upgrade-insecure-requests e block-all-mixed-content. Chrome 81, previsto per il 17 marzo, correggerà automaticamente http:// in https:// per i caricamenti di immagini miste.

Inoltre, Google ha annunciato il in precedenza sull'integrazione in una delle prossime versioni del browser Chome del nuovo componente Password Checkup sviluppando come aggiunta esterna. L'integrazione porterà alla comparsa nel normale gestore di password di Chrome di strumenti per analizzare l'affidabilità delle password utilizzate dall'utente. Quando provi ad accedere a qualsiasi sito, il tuo login e la tua password verranno confrontati con un database di account compromessi, con un avviso visualizzato se vengono rilevati problemi. Il controllo viene effettuato su un database che copre oltre 4 miliardi di account compromessi apparsi nei database degli utenti trapelati. Verrà visualizzato un avviso anche se si tenta di utilizzare password banali come "abc123" (by statistica Google (il 23% degli americani utilizza password simili) o quando si utilizza la stessa password su più siti.

Per mantenere la riservatezza, quando si accede ad un'API esterna, vengono trasmessi solo i primi due byte dell'hash di login e password (viene utilizzato l'algoritmo di hashing Argon2). L'hash completo viene crittografato con una chiave generata dal lato dell'utente. Anche gli hash originali nel database di Google vengono 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 trasmesso viene effettuata da parte dell’utente utilizzando la tecnologia crittografica”cecità“, in cui nessuna delle parti conosce il contenuto dei dati da controllare. Per evitare che il contenuto di un database di account compromessi venga determinato con la forza bruta con la richiesta di prefissi arbitrari, i dati trasmessi vengono crittografati in connessione con una chiave generata sulla base di una combinazione verificata di login e password.

Fonte: opennet.ru