En ciberseguretat sobirana ↑ Aquesta crònica s’inscriu dins l’apartat Digital Security, en la continuïtat de les investigacions realitzades sobre exploits i contramesures de maquinari zero trust.

Què és el Clickjacking d’extensions basat en DOM?

El Clickjacking d’extensions basat en DOM és una variant del clickjacking en què l’atacant manipula el Document Object Model (DOM) del navegador per segrestar la capa de confiança de les extensions. A diferència del clickjacking clàssic, no es limita a superposar una pàgina trampa: utilitza iframes invisibles i crides focus() per forçar les extensions a injectar credencials, codis TOTP o passkeys en un formulari ocult. El resultat: els secrets són exfiltrats directament del DOM sense que l’usuari se n’adoni.

Història del Clickjacking (2002–2025)

El clickjacking és com un paràsit tossut del web modern. El terme apareix a inicis dels anys 2000, quan Jeremiah Grossman i Robert Hansen descriuen un escenari enganyós: empènyer un internauta a fer clic en alguna cosa que en realitat no veu. Una il·lusió òptica aplicada al codi, que ràpidament es va convertir en una tècnica d’atac imprescindible (OWASP).

• 2002–2008 : emergència del “UI redressing”: capes HTML + iframes transparents atrapant l’usuari (Hansen Archive).
• 2009 : Facebook víctima del Likejacking (OWASP).
• 2010 : aparició del Cursorjacking: desplaçament del punter per enganyar el clic (OWASP).
• 2012–2015 : explotació mitjançant iframes, publicitat i malvertising (MITRE CVE) (Infosec)
• 2016–2019 : el tapjacking s’estén en mòbil (Android Security Bulletin).
• 2020–2024 : auge del “hybrid clickjacking” que barreja XSS i phishing (OWASP WSTG).
• 2025 : al DEF CON 33, Marek Tóth revela un nou nivell: clickjacking extensions DOM (DEF CON Archive). Ja no són només els llocs web, sinó les extensions del navegador (gestors de contrasenyes, carteres) les que injecten formularis invisibles.

Avui, la història del clickjacking fa un tomb: ja no és només una farsa gràfica, sinó una falla estructural dels navegadors i de les seves extensions. Els gestors testats — 1Password, Bitwarden, iCloud Keychain, LastPass — apareixen vulnerables (Bitwarden Release Notes).

Al DEF CON 33, es va revelar públicament el clickjacking d’extensions DOM, marcant un canvi estructural: de l’engany visual a una debilitat sistèmica que afecta els gestors de contrasenyes i les carteres de criptomonedes.

Clickjacking extensions DOM — Anatomia de l’atac

El clickjacking extensions DOM no és una variant trivial: desvia la lògica mateixa dels gestors d’autofill. Aquí, l’atacant no es limita a recobrir un botó amb una iframe; força l’extensió a omplir un formulari fals com si fos legítim.

Desplegament típic d’un atac:

1. Preparació — La pàgina trampa carrega una iframe invisible i un Shadow DOM que oculta el context real.
2. Esquer — L’usuari fa clic en un element aparentment innocu; una crida focus() redirigeix l’esdeveniment cap al camp invisible controlat per l’atacant.
3. Exfiltració — L’extensió creu interactuar amb un camp legítim i injecta identificadors, TOTP, passkeys i fins i tot claus privades directament dins del fals DOM.

Aquesta mecànica distorsiona els senyals visuals, esquiva les defenses clàssiques (X-Frame-Options, CSP, frame-ancestors) i transforma l’autofill en un canal d’exfiltració invisible. A diferència del clickjacking “tradicional”, l’usuari no fa clic en un lloc de tercers: és la seva pròpia extensió la que queda atrapada per la seva confiança en el DOM.

Gestors de contrasenyes vulnerables

Segons les proves en viu realitzades per Marek Tóth al DEF CON 33, la majoria de gestors de contrasenyes continuen exposats estructuralment al clickjacking d’extensions DOM.

Dels 11 gestors avaluats, 10 filtren credencials, 9 filtren codis TOTP i 8 exposen passkeys.

En resum: fins i tot el gestor més popular pot convertir-se en un colador si delega els secrets al DOM.

• Encara vulnerables: 1Password, LastPass, iCloud Passwords, LogMeOnce
• Ja corregits: Bitwarden, Dashlane, NordPass, ProtonPass, RoboForm, Enpass, Keeper (correcció parcial)
• Correccions en curs: Bitwarden, Enpass, iCloud Passwords
• Classificats com “informatius” (sense patch previst): 1Password, LastPass

Taula d’estat (actualitzada el 27 d’agost de 2025)

Divulgació CVE i resposta dels editors (agost–setembre 2025)

El descobriment de Marek Tóth a DEF CON 33 no va poder quedar ocult: les vulnerabilitats de clickjacking extensions DOM ja estan rebent referències CVE oficials. Com passa sovint en la divulgació de vulnerabilitats, el procés és lent. Diverses falles van ser notificades a la primavera de 2025, però a mitjans d’agost, alguns editors encara no havien publicat cap correcció oficial.

Respostes dels editors i cronologia de correccions:

• Bitwarden — va reaccionar ràpidament amb el patch v2025.8.0 (agost 2025), mitigant la fuga de TOTP i credencials.
• Dashlane — va publicar una correcció (v6.2531.1, a principis d’agost 2025), confirmada en les notes oficials.
• RoboForm — va desplegar correccions entre juliol i agost 2025 per a Windows i macOS.
• NordPass i ProtonPass — van anunciar actualitzacions oficials a l’agost 2025, mitigant parcialment l’exfiltració via DOM.
• Keeper — va reconèixer l’impacte però continua en estat “en revisió”, sense patch confirmat.
• 1Password, LastPass, Enpass, iCloud Passwords, LogMeOnce — encara sense correcció a principis de setembre 2025, deixant exposats milions d’usuaris.

El problema no és només el retard en les correccions, sinó també la manera com alguns editors han minimitzat la gravetat.
Segons les divulgacions de seguretat, alguns proveïdors van etiquetar inicialment la vulnerabilitat com a “informativa”, reduint-ne la importància.
En altres paraules: la fuga era reconeguda, però es va relegar a una zona grisa fins que la pressió mediàtica i comunitària va forçar una resposta.

Tecnologies de correcció utilitzades

Després de la divulgació pública del Clickjacking d’extensions DOM al DEF CON 33, els editors van reaccionar ràpidament amb pegats. Tot i això, aquestes correccions són desiguals i es limiten sobretot a ajustos d’interfície o comprovacions condicionals. Cap editor ha redissenyat encara el motor d’injecció.

Abans d’analitzar els mètodes concrets, observem una visió general de les tecnologies de correcció aplicades pels editors. Aquesta imatge resumeix els enfocaments més comuns i les seves limitacions.

Objectiu

Aquesta secció explica com els editors han intentat corregir la falla, distingint entre pegats cosmètics i correccions estructurals, i destacant els enfocaments sobirans Zero DOM.

Mètodes de correcció observats (agost 2025)

📉 Límits observats

• Els pegats no han modificat el motor d’injecció, només els seus desencadenants.
• Cap editor ha introduït una separació estructural entre la interfície i els fluxos de secrets.
• Qualsevol gestor que encara depengui del DOM continua exposat estructuralment a variants de clickjacking.

Anàlisi tècnica i doctrinal de les tecnologies de correcció

Tot i que els pegats desplegats mostren una resposta ràpida, el seu abast és reactiu i incomplet.

• Limitacions estructurals — Les CSP i X-Frame-Options poden ser esquivades amb iframes invisibles o Shadow DOM encapsulat.
• Persistència del risc — L’autofill continua depenent del DOM, i per tant exposa credencials i TOTP.
• Doctrina Zero Trust — La dependència en pegats incrementals no garanteix una protecció sobirana ni duradora.

Comparativa de les tecnologies de correcció

Riscos sistèmics i vectors d’explotació

El clickjacking extensions DOM no és un bug aïllat: és una bretxa sistèmica. Quan una extensió cedeix, no és només una contrasenya la que es filtra — és tot un model de confiança digital que implosiona.

Escenaris crítics:

• Accés persistent — Un TOTP clonat és suficient per registrar un dispositiu “de confiança” i mantenir el control, fins i tot després de la reinicialització del compte.
• Repetició de passkeys — L’exfiltració d’una passkey equival a un token mestre reutilitzable fora de control. El Zero Trust esdevé un mite.
• Compromís SSO — Una extensió atrapada dins l’empresa = fuga de tokens OAuth/SAML, comprometent tot el SI.
• Cadena de subministrament — Les extensions, mal regulades, esdevenen una superfície d’atac estructural per als navegadors.
• Crypto-actius — Els wallets (MetaMask, Phantom, TrustWallet) reutilitzen el DOM per injectar claus: seed phrases i claus privades aspirades com si fossin credencials.

Impacte per a empreses i administracions (NIS2 / RGPD)

Compromís SSO, vectors d’exfiltració monetària i cadena de subministrament: prioritats de mitigació Zero DOM.

Exposició Regional i Impacte Lingüístic — Espai Catalanoparlant

L’exposició al Clickjacking d’extensions DOM i al Browser-in-the-Browser (BITB) no és homogènia. A l’espai catalanoparlant — Andorra, Catalunya, País Valencià, Illes Balears i la Catalunya Nord — l’ús intensiu de gestors de contrasenyes i carteres cripto es combina amb una dependència creixent dels navegadors. El resultat: una superfície d’atac tangible que requereix contramesures Zero-DOM sobiranes.

🌍 Exposició estimada — Espai Catalanoparlant (Agost 2025)

Fonts: Idescat (Catalunya), Generalitat Valenciana, Govern Balear, Estadística Andorra, Observatori de la Llengua.

Extensions de wallets cripto exposades

Els gestors de contrasenyes no són els únics que cauen al parany del clickjacking extensions DOM.
Els wallets cripto més estesos — MetaMask, Phantom, TrustWallet — es basen en el mateix principi d’injecció DOM per mostrar o signar transaccions.
Resultat: un overlay ben col·locat, una iframe invisible, i l’usuari creu validar una operació legítima… quan en realitat està signant una transferència maliciosa o revelant la seva seed phrase.

Implicació directa: a diferència de les credencials o TOTP, les filtracions aquí afecten actius financers immediats. Milers de milions de dòlars en liquiditat depenen d’aquestes extensions. El DOM es converteix així no només en un risc d’identitat, sinó també en un vector d’exfiltració monetària.

Sandbox vulnerable & Browser-in-the-Browser (BITB)

⮞ Il·lusions d’interfície: el sandbox no protegeix

Els navegadors sovint presenten el seu sandbox com una muralla inexpugnable, però a la pràctica, els atacs de clickjacking d’extensions DOM i Browser-in-the-Browser (BITB) demostren el contrari. Un simple overlay i un fals quadre d’autenticació poden convèncer l’usuari que interactua amb Google, Microsoft o el seu banc, mentre en realitat lliura les seves credencials a una pàgina fraudulenta. Ni frame-ancestors ni certes polítiques CSP aconsegueixen aturar aquestes il·lusions d’interfície.

És aquí on les tecnologies sobiranes canvien les regles del joc. Amb EviBITB (IRDR), Freemindtronic integra dins PassCypher HSM PGP un motor de detecció i destrucció d’iframes de redirecció, capaç de neutralitzar en temps real els intents de BITB. Activable amb un clic, disponible en mode manual, semi-automàtic o automàtic, funciona sense servidor, sense base de dades i actua de forma instantània. (guia tècnica · explicació pràctica)

La clau de volta és el Sandbox URL. Cada identificador o clau està vinculat a una URL de referència emmagatzemada dins del HSM xifrat. Quan una pàgina intenta un autoemplenament, la URL activa es compara amb la del HSM. Si no coincideixen, no s’injecta cap dada. Així, fins i tot si un iframe esquivés la detecció, el Sandbox URL bloqueja l’exfiltració.

⮞ Protecció estesa: de navegador a escriptori

Aquesta doble barrera s’estén també als usos en ordinador, gràcies a l’aparellament segur NFC entre un telèfon Android amb NFC i l’aplicació Freemindtronic que integra el gestor de contrasenyes sobirà PassCypher NFC HSM. En aquest context, l’usuari es beneficia de la protecció anti-BITB (EviBITB) en entorns d’escriptori: els secrets romanen xifrats dins del contenidor HSM PGP o del NFC HSM i només es desxifren durant uns mil·lisegons en memòria volàtil (RAM), just el temps necessari per a l’autoemplenament segur — sense transitar ni residir mai en el DOM.

En canvi, amb PassCypher HSM PGP en ordinador, l’usuari simplement fa clic en un botó integrat al camp d’identificació per activar l’autoemplenament. El secret es desxifra localment des del contenidor xifrat, també en RAM, però sense intervenció NFC i sense passar pel DOM.

Senyal estratègic DEF CON 33

Als passadissos carregats d’energia del DEF CON 33, no només parpellegen els badges: també ho fan les nostres certeses.
Entre una cervesa tèbia i un CTF frenètic, les converses convergeixen: el navegador ha deixat de ser una zona de confiança.

• El DOM esdevé un camp de mines: ja no només allotja XSS bàsic, sinó les mateixes claus d’identitat — gestors, passkeys, wallets cripto.
• La promesa «phishing-resistant» vacil·la: veure una passkey ser pescada en directe és com veure en Neo caure davant d’un script-kiddie.
• Lentitud industrial: alguns publiquen pegats en 48h, altres es perden en comitès i comunicats. Resultat: milions d’usuaris resten exposats.
• Doctrina Zero Trust reforçada: tot secret que toqui el DOM s’ha de considerar ja compromès.
• Tornada al maquinari sobirà: davant d’un núvol que s’esquerda, les mirades es giren cap a solucions fora del DOM:
  PassCypher NFC HSM, PassCypher HSM PGP, SeedNFC per a la custòdia de claus cripto. Zero DOM, zero il·lusió.

Contramesures sobiranes (Zero DOM)

Els pegats correctius dels editors poden tranquil·litzar en el moment… però no canvien res del problema de fons: el DOM continua sent un colador.
L’única defensa duradora és retirar els secrets del seu abast.
Això és el que anomenem el principi Zero DOM: cap dada sensible no ha de residir, transitar o dependre del navegador.

En aquest paradigma, els secrets (identificadors, TOTP, passkeys, claus privades) es conserven dins HSM de maquinari fora de línia.
L’accés només és possible mitjançant activació física (NFC, HID, aparellament segur) i deixa únicament una empremta efímera a la RAM.

A diferència dels gestors en núvol o de les passkeys FIDO, aquestes solucions no apliquen pegats a posteriori: eliminen la superfície d’atac des de la concepció.
És el nucli de l’enfocament sovereign-by-design: arquitectura descentralitzada, sense servidor central, sense base de dades a escurar.

Implementació pràctica Zero DOM

• HSM fora de línia + activació física (NFC/HID)
• Autofill via URL sandbox i canals RAM efímers
• Anti-BITB (EviBITB) per a navegació segura

PassCypher HSM PGP — Tecnologia Zero-DOM Patentada des del 2015

Molt abans de l’exposició del Clickjacking d’extensions DOM al DEF CON 33, Freemindtronic ja havia triat un altre camí. Des del 2015, la nostra R&D va establir un principi fundacional: mai utilitzar el DOM per transportar secrets. Aquesta doctrina de Zero Trust va donar lloc a una arquitectura Zero-DOM patentada en PassCypher, garantint que credencials, TOTP/HOTP, contrasenyes i claus criptogràfiques romanguin confinades en un HSM de maquinari — mai injectades en un entorn manipulable.

⚡ Un Avanç Únic en Gestors de Contrasenyes

• Zero DOM natiu — cap dada sensible toca mai el navegador.
• HSM PGP integrat — xifrat AES-256 CBC + segmentació de claus patentada.
• Autonomia sobirana — sense servidor, sense base de dades, sense dependència del núvol.

🛡 Protecció BITB Reforçada

Des del 2020, PassCypher HSM PGP inclou — fins i tot en la seva versió gratuïta — la tecnologia
EviBITB.
Aquesta innovació neutralitza en temps real els atacs de Browser-in-the-Browser (BITB): destrueix iframes maliciosos, detecta superposicions fraudulentes i valida contextos sense servidor, sense base de dades i de manera completament anònima.
Descobreix com funciona EviBITB en detall.

⚙ Implementació Immediata

L’usuari no ha de configurar res: només cal instal·lar l’extensió PassCypher HSM PGP des del
Chrome Web Store
o Edge Add-ons,
activar l’opció BITB i gaudir de la protecció sobirana Zero-DOM de manera instantània — mentre la competència encara corre darrere del problema.

PassCypher NFC HSM — Gestor de contrasenyes passwordless sobirà amb HSM NFC

Quan els gestors de contrasenyes tradicionals cauen en la trampa d’un simple iframe, PassCypher NFC HSM obre una via sobirana: els vostres identificadors, contrasenyes, claus privades no passen mai pel DOM.
Romanen xifrats dins d’un nano-HSM fora de línia, i només apareixen un instant en memòria volàtil (RAM) — el temps estrictament necessari per a l’autenticació.

Aquí, res no queda exposat al DOM: no existeix cap contrasenya mestra a extreure, perquè la seguretat es basa en claus segmentades dins l’HSM. Els contenidors romanen sempre xifrats, i el desxifrat només s’executa en RAM per muntar els segments necessaris.
Un cop completat l’autoemplenament segur, tot desapareix sense deixar cap rastre explotable.

🔧 Funcionament per a l’usuari:

• Secrets intocables — emmagatzemats i xifrats al NFC HSM, mai visibles ni extrets.
• TOTP/HOTP — generats i mostrats sota demanda via l’app Android PassCypher NFC HSM o des de l’ordinador amb PassCypher HSM PGP.
• Entrada manual — l’usuari introdueix el seu PIN o login al camp previst, en mòbil o escriptori, visualitzat des de l’app PassCypher (Freemindtronic) i generat pel mòdul NFC HSM.
• Entrada automàtica sense contacte — l’usuari no tecleja res: només cal presentar el mòdul NFC HSM al telèfon o ordinador. Funciona també quan l’app PassCypher NFC HSM està aparellada amb PassCypher HSM PGP.
• Entrada automàtica en ordinador — amb PassCypher HSM PGP en Windows o macOS, l’usuari fa clic en un botó integrat als camps d’identificació per autoemplenar amb validació automàtica el login, contrasenya.
• Anti-BITB distribuït — mitjançant aparellament segur NFC ↔ Android ↔ navegador (Win/Mac/Linux), els iframes maliciosos són destruïts en temps real (EviBITB).
• Mode HID BLE — injecció directa fora del DOM via teclat Bluetooth emulat, que neutralitza els keyloggers i altres atacs d’intercepció.

PassCypher HSM PGP — Gestió sobirana de claus

En un món on els gestors clàssics cauen davant d’un simple iframe fantasma, PassCypher HSM PGP refusa jugar aquesta partida.

La seva regla? zero servidor, zero base de dades, zero DOM.

Els vostres secrets — identificadors, contrasenyes, passkeys, claus SSH/PGP, TOTP/HOTP — viuen dins de contenidors xifrats AES-256 CBC PGP, protegits per un sistema de claus segmentades patentades, dissenyat per resistir fins i tot a l’era quàntica.

Per què resisteix davant d’atacs com els de DEF CON 33?
Perquè aquí res no passa pel DOM, cap master password és interceptable i, sobretot: els contenidors romanen sempre xifrats.
El desxiframent només es produeix en memòria volàtil RAM, el temps d’assemblar els segments de claus necessaris.
Un cop completat l’emplenament automàtic, tot desapareix sense deixar cap rastre explotable.

Funcionalitats clau:

• Autoemplenament blindat — un sol clic, però via URL sandbox, mai en clar al navegador.
• EviBITB integrat — destructors d’iframes i overlays maliciosos, activables en mode manual, semi-automàtic o automàtic, 100 % fora de servidor.
• Eines criptogràfiques integrades — generació i gestió de claus segmentades AES-256 i claus PGP sense dependències externes.
• Compatibilitat universal — funciona amb qualsevol web via software + extensió de navegador; sense actualitzacions forçades ni connectors exòtics.
• Arquitectura sobirana — sense servidor, sense base de dades, sense contrasenya mestra, 100 % anonimitzada — inatacable by design allà on el núvol falla.

Resultat: mentre un gestor clàssic és víctima d’un overlay o d’un Browser-in-the-Browser,
PassCypher HSM PGP continua hermètic.
Cap calaix obert en clar, cap DOM a manipular: només una custòdia material sobirana que desmunta phishing, keylogging i clickjacking extensions DOM.

SeedNFC + HID Bluetooth — Injecció segura dels wallets

Les extensions de wallets depenen del DOM… i és just aquí on se les atrapa.
Amb SeedNFC HSM, la lògica s’inverteix: les claus privades i les seed phrases no surten mai de l’enclavament segur.

Quan cal inicialitzar o restaurar un wallet (web o escriptori), l’entrada es fa mitjançant una emulació HID Bluetooth — com si fos un teclat físic — sense portar al porta-retalls, sense passar pel DOM, i sense deixar rastre. Això inclou tant claus privades i públiques com credencials i contrasenyes de hot wallets.

Flux operatiu (anti-DOM, anti-clipboard):

• Custòdia — la seed/clau privada queda xifrada dins del SeedNFC HSM (mai exportada, mai visible).
• Activació física: l’ús del sistema sense contacte mitjançant el NFC HSM autoritza l’operació des de l’aplicació Freemindtronic (telèfon Android amb NFC).
• Injecció HID BLE — la seed (o fragment/format requerit) és teclejada directament al camp del wallet, fora del DOM i fora del porta-retalls (resistent a keyloggers de software).
• Protecció BITB — en un wallet web, l’EviBITB (anti-Browser-in-the-Browser) pot ser activat des de l’app, neutralitzant overlays i redireccions fraudulentes.
• Efimeritat — les dades transiten únicament en RAM volàtil el temps estrictament necessari de l’escriptura HID, i després desapareixen.

Casos d’ús típics:

• Onboarding o recuperació de wallets (MetaMask, Phantom, etc.) sense exposar mai la clau privada al navegador ni al DOM. El secret roman xifrat dins del HSM i només es desxifra en RAM, el temps estrictament necessari per a l’operació.
• Operacions crítiques en ordinador (air-gap lògic), amb validació física per part de l’usuari: presenta el mòdul NFC HSM sota el telèfon Android NFC per autoritzar l’acció, sense interacció amb el teclat i sense exposició al DOM.
• Custòdia sobirana multi-actius: frases seed, claus màster i claus privades conservades en HSM fora de línia, reutilitzables sense còpia, sense exportació ni captura, activables només per acció física traçable.

Escenaris d’explotació i vies de mitigació

Les revelacions del DEF CON 33 no són un final de partida, sinó un avís.
El que arriba podria ser encara més corrosiu:

• Phishing impulsat per IA + desviament DOM — Demà ja no serà un kit de phishing improvisat en un garatge, sinó LLM generant en temps real overlays DOM indetectables, capaços d’imitar qualsevol portal bancari o núvol corporatiu.
• Tapjacking mòbil híbrid — La pantalla tàctil es converteix en un camp de mines: superposició d’apps, autoritzacions invisibles i, en segon pla, els gestos de l’usuari són desviats per validar transaccions o exfiltrar OTP.
• HSM preparats per al post-quàntic — HSM preparats per al post-quàntic — La propera línia de defensa no serà un simple pedaç de navegador, sinó uns HSM resistents al càlcul quàntic, capaços d’absorbir les futures capacitats de Shor o Grover. Solucions com PassCypher HSM PGP i SeedNFC en seguretat quàntica ja encarnen aquest fonament material zero-DOM, pensat per a l’era post-núvol..

Síntesi estratègica

El DOM-Based Extension Clickjacking revela una veritat incòmoda: els navegadors i les extensions no són entorns de confiança.
Els pedaços arriben de manera dispersa, l’exposició d’usuaris es compta en desenes de milions, i els marcs regulatoris sempre corren darrere l’amenaça.

L’única sortida sobirana? Una governança estricta del programari, acompanyada d’una còpia de seguretat fora del DOM (PassCypher NFC HSM / HSM PGP), on els secrets romanen xifrats, fora de línia i intocables pel redressing.

La via sobirana:

• Governança estricta dels programes i extensions
• còpia de seguretat de les identitats (PassCypher NFC HSM / HSM PGP)
• Secrets xifrats, fora del DOM, fora del núvol, redress-proof