{"id":141439,"date":"2025-08-24T11:11:56","date_gmt":"2025-08-24T09:11:59","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/ataka-na-brauzernye-dopolneniya-s-menedzherami-parolej-ispolzuyushhaya-klikdzheking"},"modified":"2026-01-24T17:56:45","modified_gmt":"2026-01-24T15:56:45","slug":"ataka-na-brauzernye-dopolneniya-s-menedzherami-parolej-ispolzuyushhaya-klikdzheking","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/ataka-na-brauzernye-dopolneniya-s-menedzherami-parolej-ispolzuyushhaya-klikdzheking","title":{"rendered":"Ataque a las extensiones del navegador con administradores de contrase\u00f1as, utilizando clickjacking","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
En la conferencia DEF CON 33 se present\u00f3 un m\u00e9todo de ataque a las extensiones de navegador que sustituyen sus elementos de interfaz en la p\u00e1gina visualizada. La aplicaci\u00f3n de este ataque a las extensiones con administradores de contrase\u00f1as puede dar lugar a una filtraci\u00f3n de la informaci\u00f3n almacenada en los administradores de contrase\u00f1as, como par\u00e1metros de autenticaci\u00f3n, datos de tarjetas de cr\u00e9dito, informaci\u00f3n personal y contrase\u00f1as de un solo uso para la autenticaci\u00f3n de dos factores. El problema afecta a todos los administradores de contrase\u00f1as probados, incluidos 1Password, Bitwarden, LastPass, KeePassXC-Browser, NordPass, ProtonPass y Keeper. <\/p>\n
El m\u00e9todo de ataque se basa en que las extensiones del navegador insertan un di\u00e1logo que solicita la autocompleci\u00f3n de contrase\u00f1as directamente en la p\u00e1gina mostrada, integrando sus elementos en el DOM (Modelo de Objetos del Documento) de dicha p\u00e1gina. Si el atacante tiene la capacidad de ejecutar su c\u00f3digo JavaScript en la p\u00e1gina, por ejemplo, explotando una vulnerabilidad XSS en el sitio, puede manipular todos los elementos en el DOM, incluidas las extensiones del navegador insertadas. <\/p>\n
Entre otras cosas, existe la posibilidad de hacer que el di\u00e1logo de confirmaci\u00f3n sea transparente y alinear espacialmente el bot\u00f3n en este di\u00e1logo con el bot\u00f3n de un di\u00e1logo falso, creado por el atacante y que incita al usuario a hacer clic. Di\u00e1logos enga\u00f1osos como solicitudes ficticias de permisos para trabajar con Cookies, banners publicitarios o formularios con captcha pueden ser utilizados como tales. Al colocar el di\u00e1logo falso debajo del di\u00e1logo transparente del administrador de contrase\u00f1as y alinear las ubicaciones de los botones en la pantalla, se puede lograr que el clic del usuario caiga en el bot\u00f3n de confirmaci\u00f3n para completar los par\u00e1metros de autenticaci\u00f3n en el di\u00e1logo del administrador de contrase\u00f1as, aunque el usuario crea que ha hecho clic, por ejemplo, en el bot\u00f3n de cerrar la ventana de la publicidad.
<\/center> <\/p>\n
El ataque se resume en los siguientes pasos: <\/p>\n
\n
Crear un elemento intrusivo en la p\u00e1gina que incentive a hacer clic.\n
A\u00f1adir un formulario web a la p\u00e1gina para iniciar sesi\u00f3n o completar datos personales.\n
Establecer transparencia para formularios web (\u00abopacity: 0.001\u00bb en CSS).\n
Utilizar el m\u00e9todo focus() para establecer el foco de entrada en un campo del formulario, lo que activar\u00e1 el di\u00e1logo de autocompleci\u00f3n del administrador de contrase\u00f1as.\n
Buscar el di\u00e1logo del administrador de contrase\u00f1as que ha aparecido en el DOM y establecer la transparencia para \u00e9l.\n
Esperando que el usuario haga clic en un elemento visible y persistente en la p\u00e1gina, que mediante la combinaci\u00f3n adecuada de elementos visibles e invisibles llevar\u00e1 a presionar el bot\u00f3n en un di\u00e1logo transparente y a completar los campos del gestor de contrase\u00f1as.\n
Extracci\u00f3n de datos de un formulario web completado y env\u00edo de estos al servidor del atacante. <\/ul>\n
Dado que el autocompletado de los par\u00e1metros de autenticaci\u00f3n en el gestor de contrase\u00f1as se activa solo para los sitios en los que se han guardado esos par\u00e1metros, para llevar a cabo el ataque es necesario tener la capacidad de ejecutar su propio c\u00f3digo JavaScript en el sitio atacado o en un subdominio. As\u00ed, para ejecutar el ataque, se debe obtener un subdominio en el mismo dominio que el sitio atacado o encontrar una vulnerabilidad XSS en el sitio que permita inyectar su c\u00f3digo en el contenido presentado al usuario. <\/p>\n
Se observa que muchos usuarios utilizan un solo gestor de contrase\u00f1as tanto para almacenar los par\u00e1metros de inicio de sesi\u00f3n como para generar contrase\u00f1as de un solo uso para la autenticaci\u00f3n en dos pasos, lo que permite emplear el m\u00e9todo de ataque considerado al autocompletar las contrase\u00f1as de un solo uso. Como ejemplo, se demuestra un ataque en el sitio issuetracker.google.com, que presenta una vulnerabilidad XSS. Para obtener los par\u00e1metros de inicio de sesi\u00f3n y el c\u00f3digo para la autenticaci\u00f3n de dos factores, basta con enviar al usuario un enlace que explote la vulnerabilidad XSS y lograr tres clics mediante la sustituci\u00f3n de solicitudes persistentes ficticias (autorizaci\u00f3n para procesar Cookies, autorizaci\u00f3n para la personalizaci\u00f3n y aceptaci\u00f3n de la pol\u00edtica de privacidad).
![\"Ataque](\"\/wp-content\/uploads\/2025\/08\/9df2f88789928b98278bb49ac8522c38.png\")
<\/center> <\/p>\n