Chrome comezará a bloquear os recursos HTTP nas páxinas HTTPS e a comprobar a solidez dos contrasinais

Google avisou sobre o cambio do enfoque para procesar contido mixto nas páxinas abertas mediante HTTPS. Anteriormente, se había compoñentes en páxinas abertas mediante HTTPS que se cargaban sen cifrar (a través do protocolo http://), mostrábase un indicador especial. No futuro, decidiuse bloquear a carga destes recursos por defecto. Así, as páxinas abertas a través de "https://" garantiranse que só conteñen recursos descargados a través dunha canle de comunicación segura.

Nótase que actualmente máis do 90% dos sitios son abertos por usuarios de Chrome mediante HTTPS. A presenza de insercións cargadas sen cifrado crea ameazas de seguridade mediante a modificación do contido non protexido se hai control sobre a canle de comunicación (por exemplo, cando se conecta a través dunha wifi aberta). O indicador de contido mixto resultou ineficaz e enganoso para o usuario, xa que non ofrece unha valoración clara da seguridade da páxina.

Actualmente, os tipos máis perigosos de contido mixto, como scripts e iframes, xa están bloqueados por defecto, pero aínda se poden descargar imaxes, ficheiros de audio e vídeos a través de http://. Mediante a suplantación de imaxes, un atacante pode substituír as cookies de seguimento do usuario, tentar explotar vulnerabilidades dos procesadores de imaxes ou cometer falsificación substituíndo a información proporcionada na imaxe.

A introdución do bloqueo divídese en varias etapas. Chrome 79, programado para o 10 de decembro, contará cunha nova configuración que che permitirá desactivar o bloqueo de sitios específicos. Esta configuración aplicarase ao contido mixto que xa está bloqueado, como scripts e iframes, e chamarase a través do menú que se desprega ao facer clic no símbolo do bloqueo, substituíndo o indicador proposto anteriormente para desactivar o bloqueo.

Chrome comezará a bloquear os recursos HTTP nas páxinas HTTPS e a comprobar a solidez dos contrasinais

Chrome 80, que se espera o 4 de febreiro, utilizará un esquema de bloqueo suave para ficheiros de audio e vídeo, o que implica a substitución automática das ligazóns http:// por https://, o que conservará a funcionalidade se o recurso problemático tamén é accesible a través de HTTPS. . As imaxes seguirán cargándose sen cambios, pero se se descargan a través de http://, as páxinas https:// mostrarán un indicador de conexión insegura para toda a páxina. Para cambiar automaticamente a https ou bloquear imaxes, os desenvolvedores do sitio poderán usar as propiedades de CSP upgrade-insecure-requests e block-all-mixed-content. Chrome 81, programado para o 17 de marzo, corrixirá automaticamente http:// a https:// para cargas de imaxes mixtas.

Chrome comezará a bloquear os recursos HTTP nas páxinas HTTPS e a comprobar a solidez dos contrasinais

Ademais, Google anunciou sobre a integración nunha das próximas versións do navegador Chome do novo compoñente Contrasinal Checkup, anteriormente desenvolvendo na forma adición externa. A integración levará á aparición no xestor de contrasinais de Chrome habitual de ferramentas para analizar a fiabilidade dos contrasinais utilizados polo usuario. Cando tente iniciar sesión en calquera sitio, o seu inicio de sesión e contrasinal comprobaranse cunha base de datos de contas comprometidas, e aparecerá un aviso se se detectan problemas. A comprobación realízase contra unha base de datos que abarca máis de 4 millóns de contas comprometidas que apareceron en bases de datos de usuarios filtradas. Tamén se mostrará un aviso se intentas usar contrasinais triviais como "abc123" (por estatísticas Google o 23% dos estadounidenses usa contrasinais similares) ou cando usa o mesmo contrasinal en varios sitios.

Para manter a confidencialidade, ao acceder a unha API externa só se transmiten os dous primeiros bytes do hash do inicio de sesión e do contrasinal (utilízase o algoritmo de hash Argón 2). O hash completo está cifrado cunha clave xerada no lado do usuario. Os hash orixinais da base de datos de Google tamén están cifrados e só quedan os dous primeiros bytes do hash para indexar. A verificación final dos hash que se atopan baixo o prefixo de dous bytes transmitido realízase por parte do usuario mediante tecnoloxía criptográfica "cegueira“, no que ningunha das partes coñece o contido dos datos que se están a comprobar. Para protexerse contra a determinación do contido dunha base de datos de contas comprometidas mediante a forza bruta cunha solicitude de prefixos arbitrarios, os datos transmitidos cífranse en conexión cunha clave xerada a partir dunha combinación verificada de inicio de sesión e contrasinal.

Fonte: opennet.ru

Engadir un comentario