Le prossime versioni di Google Chrome inizieranno a bloccare le risorse HTTP sulle pagine HTTPS

Google Chrome

Google Chrome

Google ha avvertito di un cambiamento nell'approccio alla gestione dei contenuti misti sulle pagine aperte tramite HTTPS. In precedenza, se c'erano componenti su pagine aperte con HTTPS caricato senza crittografia (utilizzando il protocollo http: //), è stato visualizzato un prompt speciale.

Ora, per le prossime versioni del browser, si è deciso di bloccare il caricamento di queste risorse predefinito. Pertanto, sarà garantito che le pagine aperte tramite "https: //" contengano solo risorse caricate tramite un canale di comunicazione protetto.

Si osserva che attualmente gli utenti di Chrome aprono più del 90% dei siti utilizzando HTTPS. La presenza di inserti scaricati senza crittografia crea una minaccia di violazione della sicurezza attraverso la modifica di contenuti non sicuri in presenza di controllo sul canale di comunicazione (ad esempio, quando ci si connette tramite Wi-Fi aperto).

L'indicatore di contenuto misto è riconosciuto come inefficace e fuorviante, in quanto non offre una valutazione univoca della sicurezza della pagina.

Attualmente, i tipi più pericolosi di contenuto misto, come script e iframe, sono già bloccati per impostazione predefinita, ma è ancora possibile scaricare immagini, file audio e video tramite "http: //".

Sostituendo le immagini, l'aggressore può sostituire le azioni di tracciamento dei cookie, provare a sfruttare le vulnerabilità nei processori di immagini o commettere un falso, sostituendo le informazioni presentate nell'immagine.

L'introduzione del blocco è suddivisa in più fasi. In Chrome 79 (previsto per il 10 dicembre), Apparirà una nuova impostazione che disabiliterà il blocco di siti specifici.

Le impostazioni specificate verranno applicate ai contenuti misti già bloccati, come script e iframe e verranno attivate tramite il menu che compare quando si fa clic sul simbolo del lucchetto, sostituendo l'indicatore precedentemente proposto per disattivare il blocco.

Mentre per Chrome 80 (previsto il 4 febbraio) uno schema di blocco verrà utilizzato per i file audio e video, che prevede la sostituzione automatica da http: // a https: // che lo manterrà funzionante se la risorsa problematica è disponibile anche tramite HTTPS.

Le immagini continueranno a essere caricate invariate, ma in caso di download tramite http: // su pagine https: // per l'intera pagina, verrà avviato un indicatore di una connessione non sicura. Per la sostituzione automatica con https o immagini di blocco, gli sviluppatori del sito potranno utilizzare le proprietà CSP di richieste non sicure aggiornate e di blocco di tutti i contenuti misti.

Il lancio di Chrome 81, prevista per il 17 marzo, utilizzerà la correzione automatica da http: // a https: // per il download di immagini miste.

google-password-checkup-estensione-chrome

Inoltre, ha annunciato Google integrazione in una delle prossime versioni del browser Chome, un nuovo componente di Controllo password, precedentemente sviluppato come plugin esterno.

L'integrazione porterà alla comparsa nel gestore di password a tempo pieno Strumenti di Chrome analizzare l'affidabilità delle password utilizzate dall'utente. Quando si tenta di accedere a qualsiasi sito, il nome utente e la password verranno verificati nel database degli account compromessi con un avviso in caso di problemi.

La convalida avviene su un database che copre oltre 4 miliardi di account compromessi che vengono presentati in perdite di database utente. Verrà visualizzato un avviso anche quando si tenta di utilizzare password banali come "abc123" (le statistiche di Google il 23% degli americani utilizza queste password) o quando utilizzano la stessa password su più siti.

Per preservare la riservatezza, quando si accede all'API esterna, solo i primi due byte dell'hash vengono trasferiti dalla connessione dal login e dalla password (per l'hash viene utilizzato l'algoritmo Argon2). L'hash completo viene crittografato con una chiave generata dall'utente.

Anche gli hash originali nel database di Google vengono crittografati e solo i primi due byte dell'hash rimangono per l'indicizzazione.

Per evitare di determinare il contenuto del database degli account compromessi enumerando con prefissi casuali, i dati restituiti vengono crittografati rispetto alla chiave generata in base al collegamento verificato e password.

fonte: https://security.googleblog.com


Lascia un tuo commento

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati con *

*

*

  1. Responsabile dei dati: Miguel Ángel Gatón
  2. Scopo dei dati: controllo SPAM, gestione commenti.
  3. Legittimazione: il tuo consenso
  4. Comunicazione dei dati: I dati non saranno oggetto di comunicazione a terzi se non per obbligo di legge.
  5. Archiviazione dati: database ospitato da Occentus Networks (UE)
  6. Diritti: in qualsiasi momento puoi limitare, recuperare ed eliminare le tue informazioni.