A empresa Google sobre a mudança de abordagem para o tratamento de conteúdo misto em páginas acessadas por HTTPS. Anteriormente, quando havia componentes em páginas HTTPS carregados sem criptografia (via http://), um indicador especial era exibido. No futuro, foi decidido bloquear o carregamento de tais recursos por padrão. Assim, páginas abertas em "https://" conterão garantidamente apenas recursos carregados através de um canal de comunicação seguro.
Observa-se que atualmente mais de 90% dos sites são acessados pelos usuários do Chrome usando HTTPS. A presença de elementos carregados sem criptografia cria riscos de violação de segurança através da modificação de conteúdo não seguro quando há controle sobre o canal de comunicação (por exemplo, quando se conecta a redes Wi-Fi abertas). O indicador de conteúdo misto é considerado ineficaz e enganoso para o usuário, pois não fornece uma avaliação clara da segurança da página.
Atualmente, os tipos de conteúdo misto mais perigosos, como scripts e iframes, já são bloqueados por padrão, mas imagens, arquivos de áudio e vídeos ainda podem ser carregados via http://. Através da substituição de imagens, um atacante pode inserir Cookies de rastreamento das ações do usuário, tentar explorar vulnerabilidades em processadores de imagem ou realizar fraudes substituindo as informações apresentadas na imagem.
A introdução do bloqueio é dividida em várias etapas. No Chrome 79, programado para 10 de dezembro, haverá uma nova configuração que permitirá desabilitar o bloqueio para sites específicos. A configuração mencionada se aplicará ao conteúdo misto já bloqueado, como scripts e iframes, e poderá ser acessada através do menu que aparece ao clicar no ícone do cadeado, substituindo o indicador anteriormente oferecido para desabilitar o bloqueio.
No Chrome 80, que será lançado em 4 de fevereiro, será aplicada uma leve esquema de bloqueio para arquivos de áudio e vídeo, implicando a substituição automática nos links http:// para https://, o que permitirá manter a funcionalidade, caso o recurso problemático também esteja disponível via HTTPS. As imagens continuarão a ser carregadas sem alterações, mas, ao carregar via http:// nas páginas https://, um indicador de conexão não segura será exibido em toda a página. Para a substituição automática para https ou bloqueio de imagens, os desenvolvedores de sites poderão usar as propriedades CSP upgrade-insecure-requests e block-all-mixed-content. No lançamento do Chrome 81, programado para 17 de março, a substituição automática de http:// para https:// será aplicada ao carregar imagens de forma mista.
Além disso, a empresa Google está integrando, em uma das próximas versões do navegador Chrome, um novo componente chamado Password Checkup, que anteriormente na forma de . A integração levará à inclusão de ferramentas no gerenciador de senhas padrão do Chrome para analisar a robustez das senhas usadas pelo usuário. Ao tentar fazer login em qualquer site, uma verificação do nome de usuário e da senha será realizada em uma base de dados de contas comprometidas, com um aviso sendo emitido caso problemas sejam encontrados. A verificação é realizada em uma base que abrange mais de 4 bilhões de contas comprometidas que apareceram em vazamentos de dados de usuários. Um aviso também será emitido ao tentar usar senhas triviais, como 'abc123' (segundo Google, 23% dos americanos usam senhas semelhantes), ou ao usar a mesma senha em vários sites.
Para preservar a privacidade ao acessar uma API externa, apenas os primeiros dois bytes do hash da combinação de nome de usuário e senha são enviados (sendo que o algoritmo usado para hashing é ). O hash completo é criptografado com uma chave gerada do lado do usuário. Os hashes originais na base de dados do Google também são criptografados adicionalmente e apenas os primeiros dois bytes do hash são deixados para indexação. A verificação final dos hashes que correspondem ao prefixo de dois bytes enviado é realizada do lado do usuário usando a técnica criptográfica de«, em que nenhuma das partes conhece o conteúdo dos dados verificados. Para proteger contra a determinação do conteúdo da base de contas comprometidas por meio da exploração de solicitações com prefixos arbitários, os dados fornecidos são criptografados com base em uma chave gerada a partir da combinação de login e senha verificada.
Fonte: opennet.ru
