Tabnabbing e clickjacking: gli attacchi all'interfaccia che non vedi mai

Cosa fa davvero il tabnabbing

Una scheda può ricaricarsi da sola anche in background. Non è una vulnerabilità, è una funzione pensata apposta nel browser. Se sei su una pagina e aspetti la notifica di un'email, vuoi essere avvisato anche quando la scheda non è in primo piano. Il tabnabbing fa leva proprio su questo.

L'attacco funziona così. Apri una pagina apparentemente innocua, la lasci lì e passi a un'altra scheda. Lo script della prima pagina si accorge del cambio (con la Page Visibility API o un gestore di evento focus) e aspetta qualche minuto. Poi sostituisce titolo, favicon e HTML della pagina. Quello che era un articolo ora sembra una schermata di login di Google, Microsoft o GitHub.

Quando torni ti trovi davanti a una schermata di login dall'aria familiare in una scheda che hai aperto tu. Nella barra degli indirizzi l'URL è ancora quella della pagina originale, ma praticamente nessuno la controlla. Il form spedisce quello che digiti all'attaccante e poi ti reindirizza al Google vero, così al secondo tentativo pensi semplicemente che il primo sia andato storto.

Clickjacking: un pulsante, due identità

Il clickjacking è un altro trucco di interfaccia. L'attaccante carica una pagina legittima (per esempio una pagina per cambiare la password o un form «invia denaro») dentro un iframe invisibile e la copre con un'esca invitante, tipo «clicca per vincere un premio». L'utente crede di cliccare sull'esca, ma in realtà il clic finisce sul pulsante vero che sta sotto. Per il browser il clic è autorizzato, perché tecnicamente lo è.

Il caso da manuale: un pulsante Like di Facebook chiuso in un iframe e nascosto sotto un elemento di gioco. Le vittime mettono Mi piace, senza accorgersene, a una pagina che non hanno mai visto. La faccenda si fa più seria quando il pulsante sotto è il «Confirm» di una schermata di consenso OAuth o il «Send transaction» di un'app decentralizzata. Entrambi i casi sono già stati sfruttati sul campo più di una volta.

Qui chi deve difendersi sono i gestori dei siti. L'header X-Frame-Options e la direttiva frame-ancestors nella Content-Security-Policy impediscono ad altri siti di incorporare il sito fidato in un iframe. Le grandi piattaforme la questione l'hanno coperta bene. I siti che non impostano l'header restano attaccabili, e le piattaforme Web3 più recenti si portano dietro storicamente delle falle proprio su questo fronte.

Reverse tabnabbing via window.opener

Una tecnica parente si chiama reverse tabnabbing. Una scheda appena aperta, tramite window.opener, ha accesso alla pagina che l'ha aperta. Se un attaccante riesce a piazzare il suo link sul tuo sito, dalla scheda nuova può reindirizzare la pagina d'origine. Più tardi ci torni e finisci su un clone di phishing del sito su cui eri davvero.

La difesa è rel="noopener" su ogni link esterno, e i browser moderni ormai lo applicano automaticamente ai link che aprono nuove schede. Il vettore classico così si chiude, ma forum e siti con contenuti generati dagli utenti restano vulnerabili se renderizzano quei contenuti con poca attenzione.

Perché questi attacchi sopravvivono

Gli attacchi di interfaccia hanno tre tratti che li rendono longevi. Primo, sono per lo più piccole violazioni di convenzioni, non di regole tecniche. Riscrivere una scheda è una capacità legittima del browser, incorporare un iframe anche. Secondo, si poggiano su abitudini visive e di contesto che gli utenti non controllano da soli, perché non si rendono nemmeno conto di seguire delle convenzioni.

Terzo, costano poco. Un tabnabber è un file HTML con qualche decina di righe di JavaScript. Gli attaccanti mettono in piedi decine di varianti in parallelo, le abbinano a malvertising o abuso SEO, e non perdono niente quando una viene scoperta.

Cosa puoi fare oggi

Il grosso della mitigazione tocca a browser e gestori dei siti. Lato utente, bastano un paio di abitudini per coprire il resto.

1. 1

   Diffida dei login in schede inaspettate

   Se una scheda ti chiede all'improvviso un login che non ti aspettavi, chiudila. Riapri il servizio da un segnalibro.
2. 2

   Controlla l'URL prima di ogni form di login

   La barra degli indirizzi sopravvive al tabnabbing. Una sedicente pagina Gmail su un dominio sconosciuto si nota subito.
3. 3

   Tieni le sessioni corte

   Più a lungo le schede restano aperte, più occasioni hanno di riscriversi. Per i servizi sensibili, schede che restano per ore in background non sono una buona idea.
4. 4

   Le azioni critiche in una sessione isolata dedicata

   Quando concedi un consenso OAuth, firmi una transazione o colleghi degli account, fallo in una sessione dove non gira nient'altro in parallelo. Tutti i trucchi di interfaccia noti si neutralizzano, perché non c'è una seconda scheda da manipolarti accanto.