En ciberseguridad soberana ↑ Esta crónica forma parte de la sección Seguridad Digital, continuando nuestra investigación sobre exploits, vulnerabilidades sistémicas y contramedidas de confianza cero basadas en hardware.

¿Qué es el clickjacking de extensiones basado en el DOM?

DOM-based extension clickjacking secuestra una extensión del navegador (gestor de contraseñas o wallet) abusando del Document Object Model. Una página engañosa enlaza iframes invisibles, Shadow DOM y una llamada maliciosa a focus() para provocar el autocompletado en un formulario invisible. La extensión «cree» que está en el campo correcto y vierte secretos allí — credenciales, códigos TOTP/HOTP, passkeys, incluso claves privadas. Porque estos secretos tocan el DOM, pueden ser exfiltrados de forma silenciosa.

¿Qué nivel de peligrosidad tiene?

Este vector no es menor: explota la propia lógica del autocompletado y opera sin que el usuario lo note. El atacante no se limita a superponer un elemento; fuerza a la extensión a rellenar un formulario falso como si nada, haciendo la exfiltración indetectable a simple vista.

Flujo típico del ataque

1. Preparación — la página maliciosa incrusta un iframe invisible y un Shadow DOM que oculta el contexto real; los campos se hacen no visibles (opacity:0, pointer-events:none).
2. Cebo — la víctima hace clic en un elemento inocuo; redirecciones y un focus() malicioso redirigen el evento a un campo controlado por el atacante.
3. Exfiltración — la extensión cree que interactúa con un campo legítimo e inyecta automáticamente credenciales, TOTP, passkeys o claves privadas en el DOM falso; los datos se exfiltran al instante.

Este mecanismo engaña las señales visuales, elude protecciones clásicas (X-Frame-Options, Content-Security-Policy, frame-ancestors) y convierte el autocompletado en un canal de exfiltración invisible. Los overlays tipo Browser-in-the-Browser (BITB) y la manipulación del Shadow DOM aumentan aún más el riesgo, haciendo phishable las passkeys sincronizadas y las credenciales.

Historia del Clickjacking (2002–2025)

El clickjacking se ha convertido en el parásito persistente de la web moderna. El término surgió a principios de los 2000, cuando Jeremiah Grossman y Robert Hansen describieron un escenario engañoso: inducir al usuario a hacer clic en algo que en realidad no podía ver. Una ilusión óptica aplicada al código, pronto se convirtió en una técnica de ataque de referencia (OWASP).

• 2002–2008: Aparición del “UI redressing”: capas HTML + iframes transparentes atrapando al usuario (Archivo Hansen).
• 2009: Facebook cae víctima del Likejacking (OWASP).
• 2010: Surge el Cursorjacking — desplazar el puntero para manipular clics (OWASP).
• 2012–2015: Explotación vía iframes, anuncios online y malvertising (MITRE CVE) (Infosec).
• 2016–2019: El tapjacking se extiende en móviles Android (Android Security Bulletin).
• 2020–2024: Auge del “clickjacking híbrido” combinando XSS y phishing (OWASP WSTG).
• 2025: En DEF CON 33, Marek Tóth presenta un nuevo nivel: Clickjacking de Extensiones DOM. Esta vez no solo los sitios web, sino también las extensiones del navegador (gestores de contraseñas, billeteras cripto) inyectan formularios invisibles, habilitando la exfiltración sigilosa de secretos.

En DEF CON 33, Tóth reveló públicamente el clickjacking de extensiones DOM, marcando un cambio estructural: de un truco visual a una debilidad sistémica en gestores de contraseñas y wallets cripto.

Vulnerabilidades de Gestores de Contraseñas & divulgación CVE (instantánea — 2 oct. 2025)

Actualización: 2 de octubre de 2025 Tras la divulgación en DEF CON 33 por Marek Tóth, varios proveedores publicaron correcciones o mitigaciones, pero la velocidad de respuesta varía considerablemente. La nueva columna indica el tiempo estimado entre la presentación (8 de agosto de 2025) y la publicación de un parche/mitigación.

Divulgación CVE y Respuestas de Proveedores (Ago–Sep 2025)

El descubrimiento de Marek Tóth en DEF CON 33 no podía permanecer oculto: las vulnerabilidades de clickjacking extensiones DOM están recibiendo actualmente identificadores oficiales CVE.
Sin embargo, como suele ocurrir en los procesos de vulnerability disclosure, el avance es lento. Varias fallas fueron reportadas ya en primavera de 2025, pero a mediados de agosto algunos proveedores aún no habían publicado correcciones públicas.

Respuestas de proveedores y cronología de parches:

• Bitwarden — reaccionó rápidamente con el parche v2025.8.0 (agosto 2025), mitigando fugas de credenciales y TOTP.
• Dashlane — lanzó una corrección (v6.2531.1, inicios de agosto 2025), confirmada en notas oficiales.
• RoboForm — desplegó parches en julio–agosto 2025 en versiones Windows y macOS.
• NordPass y ProtonPass — anunciaron actualizaciones oficiales en agosto 2025, mitigando parcialmente la exfiltración vía DOM.
• Keeper — reconoció el impacto, pero sigue en estado “en revisión” sin parche confirmado.
• 1Password, LastPass, Enpass, iCloud Passwords, LogMeOnce — permanecen sin parche a inicios de septiembre 2025, dejando usuarios expuestos.

El problema no es solo el retraso en los parches, sino también la manera en que algunos proveedores minimizaron el fallo. Según informes de seguridad, ciertos editores inicialmente catalogaron la vulnerabilidad como “informativa”, restándole gravedad.
En otras palabras: reconocieron la fuga, pero la relegaron a una “caja gris” hasta que la presión mediática y comunitaria los obligó a actuar.

Tecnologías de Corrección Utilizadas

Desde la divulgación pública del clickjacking extensiones DOM en DEF CON 33, los proveedores se apresuraron a lanzar parches. Sin embargo, estas correcciones siguen siendo desiguales, limitadas en su mayoría a ajustes de interfaz o comprobaciones condicionales. Ningún proveedor ha re-ingenierizado aún el motor de inyección en sí.

🔍 Antes de profundizar en los métodos de corrección, aquí tienes una vista general de las principales tecnologías desplegadas por los proveedores para mitigar el clickjacking de extensiones DOM. La infografía muestra el espectro: desde parches cosméticos hasta soluciones soberanas Zero-DOM.

Objetivo

Esta sección explica cómo intentaron los proveedores corregir la falla, distingue entre parches cosméticos y correcciones estructurales, y destaca las aproximaciones soberanas Zero-DOM en hardware.

Métodos de Corrección Observados (agosto 2025)

📉 Límites Observados

• Los parches no modificaron el motor de inyección, solo sus disparadores de activación.
• Ningún proveedor introdujo separación estructural entre interfaz y flujo de secretos.
• Cualquier gestor aún atado al DOM permanece expuesto estructuralmente a variantes de clickjacking.

Tecnologías de Corrección frente al Clickjacking de Extensiones DOM — Análisis Técnico y Doctrinal

📌 Observación

El clickjacking extensiones DOM no es un simple bug, sino un defecto de diseño: inyectar secretos en un DOM manipulable sin separación estructural ni verificación contextual.

⚠️ Lo que las correcciones actuales no abordan

• Ningún proveedor ha reconstruido su motor de inyección.
• Las correcciones se limitan a desactivar autocompletado, filtrar subdominios o detectar elementos invisibles.
• Ninguno ha integrado una arquitectura Zero-DOM que garantice inviolabilidad por diseño.

🧠 Lo que requeriría una corrección estructural

• Eliminar toda dependencia del DOM para la inyección de secretos.
• Aislar el motor de inyección fuera del navegador.
• Usar autenticación hardware (NFC, PGP, biometría).
• Registrar cada inyección en un diario auditable.
• Prohibir interacción con elementos invisibles o encapsulados.

📊 Tipología de correcciones

🧪 Pruebas doctrinales para verificar parches

Para comprobar si la corrección de un proveedor es realmente estructural, los investigadores de seguridad pueden:

• Inyectar un campo invisible (opacity:0) dentro de un iframe.
• Simular un Shadow DOM encapsulado.
• Verificar si la extensión aún inyecta secretos.
• Comprobar si la inyección queda registrada o bloqueada.

📜 Ausencia de estándar industrial

Actualmente, no existe ningún estándar oficial (NIST, OWASP, ISO) que regule:

• La lógica de inyección en extensiones,
• La separación entre interfaz y flujo de secretos,
• La trazabilidad de acciones de autocompletado.

Riesgos Sistémicos y Vectores de Explotación

El clickjacking extensiones DOM no es un fallo aislado, sino una vulnerabilidad sistémica. Cuando una extensión del navegador se derrumba, las consecuencias no se limitan a una contraseña filtrada. En cambio, socava todo el modelo de confianza digital, provocando brechas en cascada a través de capas de autenticación e infraestructuras.

Escenarios críticos:

• Acceso persistente — Un TOTP clonado basta para registrar un “dispositivo de confianza” y mantener acceso incluso tras un restablecimiento completo de la cuenta.
• Reutilización de passkeys — La exfiltración de una llave de acceso actúa como un token maestro, reutilizable fuera de cualquier perímetro de control. El “Zero Trust” se convierte en ilusión.
• Compromiso SSO — Una extensión atrapada en una empresa conduce a la fuga de tokens OAuth/SAML, comprometiendo todo el sistema de TI.
• Brecha en la cadena de suministro — Extensiones mal reguladas crean una superficie de ataque estructural a nivel de navegador.
• Sifoneo de criptoactivos — Billeteras como MetaMask, Phantom o TrustWallet inyectan claves en el DOM; frases semilla y claves privadas son drenadas tan fácilmente como credenciales.

Exposición Regional e Impacto Lingüístico — Mundo Anglófono

No todas las regiones comparten el mismo nivel de riesgo frente al clickjacking extensiones DOM y a los ataques Browser-in-the-Browser (BITB). La esfera anglófona —debido a la alta adopción de gestores de contraseñas y billeteras cripto— representa una base de usuarios significativamente más expuesta. Por tanto, las contramedidas soberanas Zero-DOM son críticas para proteger a esta región digitalmente dependiente.

🌍 Exposición estimada — Región Anglófona (ago 2025)

Fuentes: ICLS (hablantes de inglés), Security.org (uso de gestores en EE.UU.), DataReportal (estadísticas digitales UK).

Extensiones de Billeteras Cripto Expuestas

Los gestores de contraseñas no son las únicas víctimas del clickjacking extensiones DOM.
Las billeteras cripto más utilizadas — MetaMask, Phantom, TrustWallet — dependen del mismo mecanismo de inyección DOM para mostrar o firmar transacciones.
En consecuencia, una superposición bien colocada o un iframe invisible engañan al usuario, haciéndole creer que aprueba una transacción legítima, cuando en realidad está autorizando una transferencia maliciosa o exponiendo su frase semilla.

Implicación directa: A diferencia de credenciales robadas o TOTP clonados, estas fugas afectan a activos financieros inmediatos. Miles de millones de dólares en valor líquido dependen de tales extensiones.
Por tanto, el DOM se convierte no solo en un vector de compromiso de identidad, sino también en un canal de exfiltración monetaria.

Sandbox Fallida y Browser-in-the-Browser (BITB)

Los navegadores presentan su sandbox como una fortaleza inexpugnable.
Sin embargo, los ataques de clickjacking extensiones DOM y Browser-in-the-Browser (BITB) demuestran lo contrario.
Una simple superposición y un marco de autenticación falso pueden engañar al usuario, haciéndole creer que interactúa con Google, Microsoft o su banco, cuando en realidad está entregando secretos a una página fraudulenta.
Incluso las directivas frame-ancestors y algunas políticas CSP fallan en prevenir estas ilusiones de interfaz.

Aquí es donde las tecnologías soberanas cambian la ecuación.
Con EviBITB (IRDR), Freemindtronic integra en PassCypher HSM PGP un motor de detección y destrucción de iframes maliciosos, neutralizando intentos BITB en tiempo real.
Activable con un solo clic, funciona en modo manual, semiautomático o automático, totalmente serverless y sin base de datos, garantizando defensa instantánea (explicación · guía detallada).

La piedra angular sigue siendo la Sandbox URL.
Cada identificador o clave criptográfica se vincula a una URL de referencia almacenada de forma segura en el HSM cifrado.
Cuando una página solicita autocompletado, la URL activa se compara con la referencia. Si no coincide, no se inyecta ningún dato.
Así, incluso si un iframe logra evadir la detección, la Sandbox URL bloquea los intentos de exfiltración.

Esta barrera de doble capa también se extiende al uso en escritorio.
Mediante el emparejamiento seguro NFC entre un smartphone Android y la aplicación Freemindtronic con PassCypher NFC HSM, los usuarios se benefician de protección anti-BITB en escritorio.
Los secretos permanecen cifrados dentro del HSM NFC y solo se descifran en memoria RAM durante unos milisegundos, lo justo para el autocompletado — nunca persisten en el DOM.

Señales Estratégicas desde DEF CON 33

En los pasillos electrificados de DEF CON 33, no solo parpadean insignias: también lo hacen nuestras certezas.
Entre una cerveza tibia y un frenético CTF, las conversaciones convergen en un punto común: el navegador ya no es una zona de confianza.
En consecuencia, el clickjacking extensiones DOM no se trata como una clase de bug, sino como un fallo estructural que afecta por igual a gestores de contraseñas, passkeys y billeteras cripto.

• El DOM se convierte en un campo minado: ya no aloja solo “XSS básicos”; ahora porta primitivas de identidad — gestores, passkeys y wallets — haciendo del secuestro de autocompletado vía Shadow DOM un riesgo de primer orden.
• La promesa de “resistencia al phishing” se tambalea: ver una passkey ser phished en vivo equivale a ver a Neo apuñalado por un script kiddie — dramático, pero trivial una vez que la interfaz es subvertida.
• Lentitud industrial: algunos proveedores publican parches en 48h; otros se pierden en comités y notas de prensa. Mientras tanto, millones siguen expuestos a flaws de seguridad en extensiones y overlays invisibles.
• Zero Trust reforzado: cualquier secreto que toque el DOM debe considerarse ya comprometido — desde credenciales hasta TOTP y passkeys.
• Retorno del hardware soberano: a medida que las ilusiones cloud se desmoronan, la atención se dirige a contramedidas Zero-DOM offline: PassCypher NFC HSM, PassCypher HSM PGP y SeedNFC para respaldo cifrado de claves cripto. Zero DOM, cero ilusión de interfaz.

Contramedidas Soberanas (Zero DOM)

Los parches de proveedores pueden tranquilizar a corto plazo, sin embargo, no resuelven el problema de fondo: el DOM sigue siendo un colador.
La única respuesta duradera es eliminar los secretos de su alcance.
Este principio, conocido como Zero DOM, dicta que ningún dato sensible debe residir, transitar ni depender del navegador.
En otras palabras, el clickjacking extensiones DOM se neutraliza no con remiendos, sino con soberanía arquitectónica.

En este paradigma, los secretos (credenciales, TOTP, passkeys, claves privadas) se preservan en HSMs hardware offline.
El acceso solo es posible mediante activación física (NFC, HID, emparejamiento seguro) y deja una huella efímera en RAM.
Esto elimina por completo la exposición al DOM.

A diferencia de los gestores cloud o passkeys FIDO, estas soluciones no aplican parches reactivos: eliminan la superficie de ataque por diseño.
Es la esencia del enfoque soberano-por-diseño: arquitectura descentralizada, sin servidor central y sin base de datos a filtrar.

PassCypher HSM PGP — Tecnología Zero-DOM patentada & gestión soberana de claves anti-phishing

Mucho antes de la revelación del DOM extension clickjacking en DEF CON 33, Freemindtronic tomó una decisión diferente. Desde 2015 nuestro I+D aplica un principio fundacional: nunca usar el DOM para transportar secretos. Esa doctrina Zero-Trust dio lugar a la arquitectura Zero-DOM patentada de PassCypher HSM PGP, que mantiene credenciales, TOTP/HOTP, passkeys y claves criptográficas confinadas en contenedores hardware HSM — nunca inyectadas en un entorno manipulable del navegador.

Un avance único en gestores de contraseñas

• Zero-DOM nativo — ningún dato sensible toca el navegador.
• HSM-PGP integrado — contenedores cifrados AES-256-CBC con segmentación de claves patentada.
• Autonomía soberana — cero servidor, cero base de datos central, cero dependencia cloud.

Protección BITB reforzada (EviBITB)

Desde 2020, PassCypher HSM PGP incorpora EviBITB, una tecnología que neutraliza en tiempo real ataques Browser-in-the-Browser: destruye iframes maliciosos, detecta overlays fraudulentos y valida el contexto UI de forma serverless, sin base de datos y anónima. EviBITB puede funcionar en modo manual, semiautomático o totalmente automático para minimizar el riesgo BITB y el secuestro invisible del DOM.

¿Por qué resiste ataques al nivel DEF CON 33?

Porque nada transita por el DOM, no existe contraseña maestra que pueda extraerse, y los contenedores permanecen cifrados en todo momento. El descifrado ocurre únicamente en RAM volátil, durante el instante necesario para ensamblar los segmentos de clave; una vez completado el autocompletado, todo se borra inmediatamente sin dejar rastro explotable.

Características clave

• Autofill blindado — un clic basta, pero siempre vía sandbox de URL; nunca en claro dentro del navegador.
• EviBITB integrado — neutraliza iframes y overlays en tiempo real (manual / semiauto / automático), completamente serverless.
• Herramientas criptográficas integradas — generación y gestión de claves AES-256 segmentadas y claves PGP sin dependencias externas.
• Compatibilidad universal — funciona con cualquier sitio mediante software + extensión de navegador, sin plugins adicionales.
• Arquitectura soberana — cero servidor, cero base central, cero DOM: resiliencia por diseño donde los gestores cloud fallan.

Implementación inmediata

Sin configuración compleja: instala la extensión PassCypher HSM PGP desde la Chrome Web Store o Edge Add-ons, activa la opción BITB y obtén protección Zero-DOM soberana al instante.

PassCypher NFC HSM — Gestor Soberano sin Contraseñas

Los gestores de contraseñas basados en software caen en la trampa de un simple iframe.
Sin embargo, PassCypher NFC HSM sigue un camino diferente: nunca permite que tus credenciales y contraseñas transiten por el DOM.
El nano-HSM las mantiene cifradas offline y solo las libera por un instante efímero en memoria volátil — lo justo para autenticar.

Funcionamiento en el lado del usuario:

• Secretos intocables — el NFC HSM cifra y almacena credenciales que nunca aparecen ni se filtran.
• TOTP/HOTP — la app Android PassCypher NFC HSM o el PassCypher HSM PGP en escritorio los generan y muestran al instante bajo demanda.
• Entrada manual — el usuario introduce un PIN o TOTP directamente en el campo de login en un ordenador o teléfono NFC Android. La app muestra el código generado por el módulo NFC HSM. El mismo proceso aplica a credenciales, passkeys y otros secretos.
• Autocompletado sin contacto — el usuario presenta el módulo NFC HSM a un smartphone o PC, que ejecuta el autofill de forma transparente, incluso emparejado con PassCypher HSM PGP.
• Autofill en escritorio — con PassCypher HSM PGP en Windows o macOS, un clic sobre el campo de login completa usuario y contraseña, con validación opcional.
• Anti-BITB distribuido — el emparejamiento seguro NFC ↔ Android ↔ navegador (Win/Mac/Linux) activa EviBITB para destruir iframes maliciosos en tiempo real.
• Modo HID BLE — un emulador de teclado Bluetooth HID inyecta credenciales fuera del DOM, bloqueando tanto ataques DOM como keyloggers.

SeedNFC + HID Bluetooth — Inyección Segura de Wallets

Las extensiones de navegador para billeteras cripto viven en el DOM — y los atacantes explotan esa debilidad.
Con SeedNFC HSM, la lógica se invierte: el enclave nunca libera claves privadas ni frases semilla.
Cuando los usuarios inicializan o restauran una wallet (web o escritorio), el sistema realiza la entrada mediante una emulación HID Bluetooth — como un teclado hardware — sin portapapeles, sin DOM y sin dejar rastros de claves privadas, públicas o credenciales de hot wallets.

Flujo operativo (anti-DOM, anti-portapapeles):

• Custodia — el SeedNFC HSM cifra y almacena la semilla/clave privada (nunca la exporta, nunca la revela).
• Activación física — el módulo NFC HSM autoriza la operación cuando el usuario lo presenta de forma contactless a través de la app Freemindtronic (smartphone Android NFC).
• Inyección HID BLE — el sistema “teclea” la semilla (o fragmento/format requerido) directamente en el campo de la wallet, fuera del DOM y fuera del portapapeles, resistiendo incluso keyloggers de software.
• Protección BITB — los usuarios pueden activar EviBITB (motor anti-BITB destruye iframes) dentro de la app, neutralizando overlays y redirecciones maliciosas en la configuración o recuperación.
• Efimeridad — la RAM volátil mantiene temporalmente los datos durante la entrada HID, para borrarlos al instante.

Casos de uso típicos:

• Onboarding o recuperación de wallets (MetaMask, Phantom, etc.) sin exponer nunca la clave privada al navegador ni al DOM. El HSM mantiene el secreto cifrado y lo descifra solo en RAM, el tiempo mínimo necesario.
• Operaciones sensibles en escritorio (air-gap lógico), con validación física por el usuario: presentar el módulo NFC HSM bajo un smartphone NFC Android para autorizar, sin teclado ni DOM.
• Backup seguro multi-activo: un HSM hardware offline almacena frases semilla, claves maestras y privadas, permitiendo reutilización sin copiar, exportar ni exponer. La activación siempre ocurre por medios físicos, soberanos y auditables.

Escenarios de Explotación y Rutas de Mitigación

Las revelaciones de DEF CON 33 no son el final del juego, sino una advertencia.
Lo que sigue puede resultar aún más corrosivo:

• Phishing impulsado por IA + secuestro del DOM — mañana ya no serán kits de phishing caseros, sino LLMs generando superposiciones DOM en tiempo real, virtualmente indistinguibles de portales legítimos de banca o nube.
  Estos ataques de clickjacking potenciados por IA convertirán el robo de credenciales vía Shadow DOM en un arma a escala.
• Tapjacking móvil híbrido — la pantalla táctil se convierte en un campo minado: aplicaciones apiladas, permisos invisibles y gestos en segundo plano secuestrados para validar transacciones o exfiltrar OTPs.
  Esto representa la evolución del tapjacking de phishing hacia un compromiso sistémico en entornos móviles.
• HSM preparado para la era post-cuántica — la próxima línea de defensa no será un parche del navegador, sino HSMs resistentes a la computación cuántica, capaces de soportar los algoritmos de Shor o Grover.
  Soluciones como PassCypher HSM PGP y SeedNFC, ya concebidas como anclajes soberanos Zero-DOM post-cloud, encarnan este cambio de paradigma.

Síntesis Estratégica

El clickjacking extensiones DOM revela una verdad contundente: los navegadores y las extensiones no son entornos de confianza.
Los parches llegan en oleadas fragmentadas, la exposición de usuarios alcanza decenas de millones y los marcos regulatorios permanecen en un eterno desfase.

¿El único camino soberano? Una estricta gobernanza del software, combinada con salvaguardas hardware offline fuera del DOM (PassCypher NFC HSM / PassCypher HSM PGP), donde los secretos permanecen cifrados, offline e intocables por técnicas de redressing.

La Vía Soberana:

• Gobernanza estricta de software y extensiones
• Seguridad de identidad respaldada en hardware (PassCypher NFC HSM / HSM PGP)
• Secretos cifrados, fuera del DOM, fuera de la nube, redress-proof

Glosario

DOM (Document Object Model)

Representación en memoria de la estructura HTML/JS de una página web; permite a scripts y extensiones acceder y modificar elementos de la página.

Shadow DOM

Subárbol DOM encapsulado usado para aislar componentes (web components); puede ocultar elementos al resto del documento.

Clickjacking (secuestro de clics)

Técnica de «UI redressing» que engaña al usuario para que haga clic en elementos ocultos o superpuestos.

DOM-Based Extension Clickjacking

Variante donde una página maliciosa combina iframes invisibles, Shadow DOM y redirecciones (focus()) para forzar a una extensión a inyectar secretos en un formulario falso.

Autofill / Autorrelleno

Mecanismo de gestores/extensiones que inserta automáticamente credenciales, códigos OTP o passkeys en campos web.

Passkey

Credencial de autenticación WebAuthn (basada en clave pública). Las passkeys almacenadas en el dispositivo son más resistentes al phishing; las sincronizadas en la nube son más vulnerables.

WebAuthn / FIDO

Estándar de autenticación con clave pública (FIDO2) para inicios de sesión sin contraseña; la seguridad depende del modelo de almacenamiento (sincronizado vs device-bound).

TOTP / HOTP

Códigos de un solo uso generados por algoritmo temporal (TOTP) o por contador (HOTP) para autenticación de dos factores.

HSM (Hardware Security Module)

Módulo hardware seguro para generar, almacenar y usar claves criptográficas sin exponerlas en claro fuera de la enclave.

PGP (Pretty Good Privacy)

Estándar de cifrado híbrido con claves públicas/privadas; aquí usado para proteger contenedores cifrados AES-256-CBC.

AES-256 CBC

Algoritmo de cifrado simétrico (modo CBC) con clave de 256 bits — usado para cifrar contenedores de secretos.

Claves segmentadas

Fragmentación de claves en segmentos para aumentar la resistencia y permitir el ensamblaje seguro en RAM efímera.

RAM efímera

Memoria volátil donde los secretos se descifran brevemente para autofill y se borran inmediatamente — sin persistencia en disco ni en el DOM.

NFC (Near Field Communication)

Tecnología sin contacto para activar físicamente un HSM y autorizar la liberación local de un secreto.

HID-BLE (Bluetooth Low Energy HID)

Emulación de teclado por BLE para inyectar datos directamente en un campo sin pasar por el DOM ni el portapapeles.

Sandbox URL

Mecanismo que vincula cada secreto a una URL esperada almacenada en el HSM; si la URL activa no coincide, el autofill se bloquea.

Browser-in-the-Browser (BITB)

Ataque por imitación de una ventana de navegador dentro de un iframe — engaña al usuario simulando un sitio o cuadro de autenticación.

EviBITB

Motor anti-BITB serverless que detecta y destruye iframes/overlays maliciosos en tiempo real y valida el contexto UI de forma anónima.

SeedNFC

Solución HSM para custodia de seed phrases/ claves privadas; realiza la inyección fuera del DOM vía HID/NFC.

Iframe

Marco HTML que incorpora otra página; los iframes invisibles (opacity:0, pointer-events:none) son comunes en ataques de UI redressing.

focus()

Llamada JavaScript que sitúa el foco en un campo. Abusada para redirigir eventos de usuario a inputs controlados por el atacante.

Overlay

Capa visual que oculta la interfaz real y puede engañar al usuario sobre el origen de una acción.

Exfiltración

Extracción no autorizada de datos sensibles del objetivo (credenciales, TOTP, passkeys, claves privadas).

Phishable

Describe un mecanismo (p. ej. passkeys sincronizadas) susceptible de ser comprometido por falsificación de interfaz o overlays — por tanto vulnerable al phishing.

Content-Security-Policy (CSP)

Política web que controla orígenes de recursos; útil pero insuficiente por sí sola frente a variantes avanzadas de clickjacking.

X-Frame-Options / frame-ancestors

Cabeceras HTTP / directivas CSP destinadas a limitar la inclusión en iframes; pueden ser eludidas en escenarios de ataque complejos.

Keylogging

Captura maliciosa de pulsaciones de teclado; mitigada por inyecciones HID seguras (sin teclado software ni portapapeles).

Nota: este glosario unifica el vocabulario técnico de la crónica. Para definiciones normativas y referencias, consulte OWASP, NIST y los estándares FIDO/WebAuthn.