Google Chrome

Google ha advertido sobre un cambio en el enfoque para manejar contenido mixto en páginas abiertas a través de HTTPS. Anteriormente, si había componentes en páginas abiertas con HTTPS cargadas sin encriptación (usando el protocolo http://), se mostraba un indicador especial.

Ahora, para las próximas versiones del navegador, se decidió bloquear la carga de dichos recursos por defecto. Por lo tanto, se garantizará que las páginas abiertas mediante “https: //” contengan solo recursos cargados a través de un canal de comunicación seguro.

Se observa que actualmente los usuarios de Chrome abren más del 90% de los sitios usando HTTPS. La presencia de insertos descargados sin cifrado crea una amenaza de violación de seguridad a través de la modificación de contenido inseguro en presencia de control sobre el canal de comunicación (por ejemplo, cuando se conecta a través de Wi-Fi abierto).

El indicador de contenido mixto se reconoce como ineficaz y engañoso, ya que no ofrece una evaluación inequívoca de la seguridad de la página.

Actualmente, los tipos más peligrosos de contenido mixto, como scripts e iframes, ya están bloqueados de forma predeterminada, pero las imágenes, los archivos de sonido y los videos aún se pueden descargar a través de “http://”.

Mediante la sustitución de imágenes, el atacante puede sustituir las acciones de seguimiento de la cookie, tratar de explotar vulnerabilidades en los procesadores de imágenes o cometer una falsificación, reemplazando la información presentada en la imagen.

La introducción del bloqueo se divide en varias etapas. En Chrome 79 (que esta programado para el 10 de diciembre), aparecerá una nueva configuración que desactivará el bloqueo de sitios específicos.

La configuración especificada se aplicará al contenido mixto ya bloqueado, como scripts e iframes y se activará a través del menú que aparece cuando hace clic en el símbolo de bloqueo, reemplazando el indicador propuesto anteriormente para desactivar el bloqueo.

Mientras que para Chrome 80 (que se espera para el 4 de febrero) se utilizará un esquema de bloqueo para archivos de audio y video, lo que implica el reemplazo automático de http:// a https:// que lo mantendrá funcionando si el recurso problemático también está disponible a través de HTTPS.

Las imágenes continuarán cargándose sin cambios, pero en caso de descargarse a través de http:// en las páginas https:// para toda la página, se iniciará un indicador de una conexión insegura. Para el reemplazo automático con https o imágenes de bloque, los desarrolladores del sitio podrán usar las propiedades CSP actualizadas-inseguras-solicitudes y bloquear-todo-contenido-mixto.

El lanzamiento de Chrome 81, programado para el 17 de marzo, usará Autocorrección de http: // a https: // para descargas de imágenes mixtas.

Además, Google anunció la integración en una de las próximas versiones del navegador Chome, un nuevo componente de Password Checkup, desarrollado previamente como un complemento externo.

La integración dará lugar a la aparición en el administrador de contraseñas de tiempo completo de las herramientas de Chrome para analizar la fiabilidad de las contraseñas utilizadas por el usuario. Cuando intente ingresar a cualquier sitio, el nombre de usuario y la contraseña se verificarán en la base de datos de cuentas comprometidas con una advertencia en caso de problemas.

La validación se lleva a cabo en una base de datos que cubre más de 4 mil millones de cuentas comprometidas que se presentan en filtraciones de bases de datos de usuarios. También se mostrará una advertencia al intentar usar contraseñas triviales como “abc123” ( estadísticas Google 23% de los estadounidenses usan estas contraseñas), o cuando usan la misma contraseña en varios sitios.

Para preservar la confidencialidad, al acceder a la API externa, solo se transfieren los dos primeros bytes del hash desde la conexión desde el inicio de sesión y la contraseña (el algoritmo Argon2 se usa para el hash ). El hash completo se cifra con una clave generada por el usuario.

Los hashes originales en la base de datos de Google también se cifran adicionalmente y solo quedan los dos primeros bytes del hash para la indexación.

Para protegerse contra la determinación del contenido de la base de datos de cuentas comprometidas al enumerar con prefijos aleatorios, los datos devueltos se cifran en relación con la clave generada en función del enlace verificado de inicio de sesión y contraseña.

Fuente: https://security.googleblog.com