Para aumentar a segurança de seus usuários, o Google Chrome começará a bloquear recursos HTTP nas páginas HTTPS nas próximas versões.
O Google alertou sobre uma mudança na abordagem de manipulação de conteúdo misto em páginas abertas por meio do HTTPS.
Anteriormente, se houvesse componentes em páginas abertas com HTTPS carregado sem criptografia (usando o protocolo http: //), um indicador especial era exibido.
Agora, para as próximas versões do navegador, foi decidido que o navegador irá bloquear o carregamento desses recursos por padrão.
Google Chrome começará a bloquear recursos HTTP nas páginas HTTPS nas próximas versões
Portanto, isso garantirá que as páginas abertas através de “https://” contenham apenas recursos carregados através de um canal de comunicação seguro.
Vale lembrar que os usuários do Chrome atualmente abrem mais de 90% dos sites usando HTTPS.
A presença de inserções baixadas sem criptografia cria uma ameaça de violação de segurança através da modificação de conteúdo não seguro na presença de controle sobre o canal de comunicação (por exemplo, quando conectado via Wi-Fi aberto).
O indicador de conteúdo misto é reconhecido como ineficaz e enganoso, pois não oferece uma avaliação inequívoca da segurança da página.
Atualmente, os tipos mais perigosos de conteúdo misto, como scripts e iframes, já estão bloqueados por padrão, mas imagens, arquivos de som e vídeos ainda podem ser baixados via “http://”.
Ao substituir as imagens, o invasor pode substituir as ações de rastreamento de cookies, tentar explorar vulnerabilidades nos processadores de imagens ou cometer uma falsificação, substituindo as informações apresentadas na imagem.
- Como instalar o driver para o controle do Xbox no Ubuntu
- Como instalar o NeoGeo Pocket Emulator no Linux via Snap
- Como instalar o jogo Space Station 14 no Linux via Flatpak
- Como habilitar o repositório Games no openSUSE
Cronograma da mudança
A introdução do bloqueio é dividida em várias etapas. No Chrome 79 (que está programado para 10 de dezembro), será exibida uma nova configuração que desabilitará o bloqueio de sites específicos.
As configurações especificadas serão aplicadas ao conteúdo misto já bloqueado, como scripts e iframes, e serão ativadas através do menu exibido quando você clicar no símbolo de bloqueio, substituindo o indicador proposto anteriormente para desativar o bloqueio.
No Chrome 80 (previsto para 4 de fevereiro), será usado um esquema de bloqueio para arquivos de áudio e vídeo, o que implica a substituição automática de http:// para https:// que o manterá funcionando, se o recurso do problema também estiver disponível no HTTPS.
As imagens continuarão carregando sem alterações, mas se baixadas via http:// nas páginas https:// da página inteira, um indicador de conexão não segura será iniciado. Para a substituição automática por imagens https ou bloco, os desenvolvedores do site poderão usar as propriedades CSP de solicitação insegura atualizada e o conteúdo misto de todos os blocos.
O lançamento do Chrome 81, programado para 17 de março, usará a AutoCorreção de http:// para https:// para downloads de imagens mistas.
Além disso, o Google anunciou a integração em uma das próximas versões do navegador Chome, um novo componente de Verificação de senha, desenvolvido anteriormente como um complemento externo.
A integração levará à aparição no gerenciador de senhas em tempo integral das ferramentas do Chrome para analisar a confiabilidade das senhas usadas pelo usuário. Quando você tenta entrar em qualquer site, o nome de usuário e a senha serão verificados no banco de dados de contas comprometidas com um aviso, em caso de problemas.
A validação é realizada em um banco de dados que abrange mais de 4 bilhões de contas comprometidas que são apresentadas em vazamentos no banco de dados do usuário.
Um aviso também será exibido ao tentar usar senhas triviais, como “abc123” (estatísticas do Google, 23% dos americanos usam essas senhas) ou quando eles usam a mesma senha em vários sites.
Para preservar a confidencialidade, ao acessar a API externa, apenas os dois primeiros bytes do hash são transferidos da conexão do login e da senha (o algoritmo Argon2 é usado para o hash). O hash completo é criptografado com uma chave gerada pelo usuário.
Os hashes originais no banco de dados do Google também são criptografados adicionalmente e apenas os dois primeiros bytes do hash permanecem para indexação.
Para proteger contra a determinação do conteúdo do banco de dados de contas comprometidas ao enumerar com prefixos aleatórios, os dados retornados são criptografados em relação à chave gerada com base no link de login e senha verificados.
O que está sendo falado no blog
No Post found.
Post Views: 389