Se dio a conocer una nueva técnica utilizada para poder identificar a una instancia de un navegador. El método se basa en las características del procesamiento de imágenes de Favicon con la ayuda de las cuales el sitio determina los íconos que se muestran en los marcadores, pestañas y otros elementos de la interfaz del navegador.

Los navegadores guardan las imágenes de Favicon en una caché separada, que no se superpone con otras cachés, es común a todos los modos de operación y no se borra con los limpiadores estándar de caché y de historial de navegación.

Esta función permite utilizar el identificador incluso cuando se trabaja en modo incógnito y dificulta su eliminación. La autenticación mediante el método propuesto tampoco se ve afectada por el uso de VPN y complementos de bloqueo de anuncios.

El método de identificación se basa en el hecho de que en el lado del servidor es posible determinar si el usuario ha abierto previamente la página analizando la información sobre la carga de Favicon si el navegador no solicitó la imagen de Favicon especificada en los parámetros de la página, luego, la página se cargó antes y la imagen se muestra desde el caché.

Dado que los navegadores permiten configurar su propio Favicon para cada página, es posible codificar información útil a través de un reenvío secuencial del usuario a varias páginas únicas.

Cuantos más redireccionamientos haya en la cadena, más identificadores se pueden determinar (el número de identificadores está determinado por la fórmula 2 ^ N, donde N es el número de redireccionamientos). Por ejemplo, 4 usuarios pueden abordar dos redireccionamientos, 3 – 8, 4 – 16, 10 – 1024, 24 – 16 millones, 32 – 4 mil millones.

La desventaja de este método son los grandes retrasos: cuanto mayor es la precisión, más tardan las redirecciones en abrir la página.

32 redirecciones generan identificadores para todos los usuarios de Internet, pero provocan un retraso de unos tres segundos. Para un millón de identificadores, el retraso es de aproximadamente un segundo y medio.

El método implica trabajar en dos modos: escritura y lectura:

• El modo de escritura genera y almacena un identificador para el usuario que accedió por primera vez al sitio.
• El modo de lectura lee un identificador almacenado previamente.

La elección del modo depende de la solicitud del archivo Favicon para la página principal del sitio: si se solicita la imagen, los datos no se almacenan en caché y se puede suponer que el usuario no ha accedido al sitio antes o al caché el contenido está desactualizado. Según los investigadores, al especificar el encabezado HTTP Cache-Control, es posible lograr el Favicon en la caché hasta por un año.

En modo lectura, al abrir un sitio, el usuario está encadenado a páginas predefinidas con sus Favicons y el servidor HTTP analiza qué Favicons se solicitan del servidor y que se muestran sin acceder al servidor desde la caché. La presencia de la solicitud se codifica como «0» y la ausencia como «1». Para que el identificador se conserve en futuras llamadas, se muestra un código de error 404 en respuesta a las solicitudes de Favicon, es decir, la próxima vez que abra el sitio, el navegador intentará cargar estos favicons nuevamente.

En el modo de escritura, en el bucle de redireccionamiento para páginas que codifican «1», se devuelve la respuesta correcta del Favicon, depositada en la caché del navegador (cuando se repite el ciclo, los datos del Favicon se devolverán desde la caché, sin acceder al servidor), y para páginas que codifican «0» – código de error 404 (si repite el ciclo de redireccionamiento, los datos de la página se volverán a solicitar).

El método funciona en Chrome, Safari, Edge y parcialmente en Firefox. En Firefox para Linux, el uso de Favicons como Supercookies se ve obstaculizado por una función que evita que el navegador almacene en caché el Favicon.

Curiosamente, los autores del método de autenticación notificaron a los desarrolladores de Firefox sobre esta función hace aproximadamente un año, señalando que había un error en el caché, pero sin mencionar su trabajo y que corregir el error conduciría a la posibilidad de identificación del usuario.

Fuente: https://www.cs.uic.edu

from Linux Adictos https://ift.tt/2ZaKJ4F
via IFTTT

Google dio a conocer hace poco el lanzamiento de un nuevo servicio llamado «OSV» (Open Source Vulnerabilities), que ofrece acceso a una base de datos de información sobre vulnerabilidades en software de código abierto.

El servicio proporciona una API que permite automatizar la formación de solicitudes para obtener información sobre vulnerabilidades, con referencia al estado del repositorio con el código. A las vulnerabilidades se les asignan identificadores OSV separados que complementan el CVE con información ampliada.

En particular, la base de datos OSV refleja el estado de la solución del problema, se indican las confirmaciones con la aparición y reparación de la vulnerabilidad, el rango de versiones vulnerables, los enlaces al repositorio del proyecto con el código y la notificación del problema.

Estamos muy contentos de lanzar OSV (Vulnerabilidades de código abierto), nuestro primer paso hacia la mejora de la clasificación de vulnerabilidades para desarrolladores y consumidores de software de código abierto. El objetivo de OSV es proporcionar datos precisos sobre dónde se introdujo una vulnerabilidad y dónde se solucionó, ayudando así a los consumidores de software de código abierto a identificar con precisión si se ven afectados y luego hacer las correcciones de seguridad lo más rápido posible. Hemos iniciado OSV con un conjunto de datos de vulnerabilidades fuzzing encontradas por el servicio OSS-Fuzz . El proyecto OSV evolucionó a partir de nuestros esfuerzos recientes para mejorar la gestión de vulnerabilidades en código abierto ( marco «Conocer, prevenir, reparar»).

La gestión de vulnerabilidades puede resultar dolorosa tanto para los consumidores como para los encargados del mantenimiento del software de código abierto, y en muchos casos implica un tedioso trabajo manual.

El propósito principal de crear OSV es simplificar el proceso de informar a los mantenedores de paquetes sobre las vulnerabilidades identificando con precisión las versiones y confirmaciones que se ven afectadas por el problema. Los datos presentes permiten a nivel de commits y tags rastrear la manifestación de la vulnerabilidad y analizar la susceptibilidad al problema de derivadas y dependencias.

Además de la búsqueda de vulnerabilidades, también debería automatizar la búsqueda de versiones afectadas. Para ello, el servicio se basa en procesos automatizados de análisis de impacto y bisección. Este último se usa para encontrar la confirmación que introdujo un error particular en el proyecto. 

Cualquiera que utilice una biblioteca de código abierto puede acceder a OSV a través de una API y consultar si una versión en particular se ve afectada por una vulnerabilidad encontrada. Se requiere una clave de API de la consola de API de Google para la consulta.

Para los consumidores de software de código abierto, a menudo es difícil asignar una vulnerabilidad como una entrada de Vulnerabilidades y Exposiciones Comunes (CVE) a las versiones de paquete que están usando. Esto se debe al hecho de que los esquemas de control de versiones de los estándares de vulnerabilidad existentes (como Common Platform Enumeration (CPE) ) no se corresponden bien con los esquemas de control de versiones de código abierto reales, que normalmente son versiones / etiquetas y hashes de confirmación. El resultado son vulnerabilidades pasadas por alto que afectan a los consumidores intermedios.

Por ejemplo, la API permite solicitar información sobre la presencia de vulnerabilidades por número de confirmación o versión del programa. Actualmente, la base de datos contiene cerca de 25 mil problemas identificados en el proceso de pruebas de fuzzing automatizado en el sistema OSS-Fuzz, que cubre el código de más de 380 proyectos de código abierto en C/C ++.

Estamos planeando trabajar con comunidades de código abierto para ampliar con datos de varios ecosistemas de lenguaje (por ejemplo, NPM, PyPI) y elaborar una canalización para que los mantenedores de paquetes envíen vulnerabilidades con un trabajo mínimo.

En el futuro, está previsto conectar fuentes adicionales de información sobre vulnerabilidades a la base de datos. Por ejemplo, se está trabajando para integrar información sobre vulnerabilidades en proyectos en el lenguaje Go, así como en los ecosistemas NPM y PyPl.

Finalmente si deseas conocer más al respecto, puedes consultar el siguiente enlace.

from Linux Adictos https://ift.tt/3cU1SaM
via IFTTT