Il phishing, spesso associato alle "email truffaldine", si è evoluto notevolmente negli ultimi anni. Oggi, molte delle minacce più sofisticate si presentano direttamente nel front-end delle applicazioni web, sotto forma di UI spoofing o manipolazione dell'interfaccia. Gli aggressori possono utilizzare tecniche in JavaScript e CSS per indurre gli utenti a rivelare informazioni sensibili, cliccare su pulsanti invisibili o credere di interagire con elementi autentici quando in realtà sono contraffatti.
In questo articolo scoprermo cos'è l'UI spoofing e come si collega al phishing. Analizzeremo poi le tecniche per simulare attacchi in JavaScript e CSS. Esploreremo infine le strategie per riconoscere e prevenire questi attacchi nel front-end.
Cos'è l'UI Spoofing e cosa ha a che vedere con il phishing
L'UI spoofing è un sottoinsieme degli attacchi phishing che manipola l'aspetto dell'interfaccia utente per falsificare elementi autentici. Obiettivo? Ingannare l'utente. Esempi classici sono: finte finestre di login sovrapposte all'interfaccia, bottoni di logout o autorizzazione invisibili o spostati, campi di input clonati che raccolgono credenziali e mascheramento della barra degli indirizzi su mobile.
Questi attacchi non richiedono exploit a livello di backend, sfruttano però HTML, CSS e JavaScript e spesso sono ospitati su domini che sembrano legittimi.
Simulare un attacco UI Spoofing
Simulare questi attacchi può aiutare a testare l'efficacia delle difese. Di seguito mostriamo alcuni esempi comuni.
Una finta finestra di login:
<div id="overlay-login" style="position:fixed;top:0;left:0;width:100%;height:100%;background:white;z-index:9999">
<h2>Sessione scaduta</h2>
<form>
<input type="text" placeholder="Username"><br>
<input type="password" placeholder="Password"><br>
<button>Accedi</button>
</form>
</div>Con z-index:9999
position:fixed
copre completamente l'applicazione reale
Clic hijacking su bottoni trasparenti:
<a href="https://attacker.com/submit" style="
position:absolute;
top:200px;left:200px;
width:100px;height:50px;
opacity:0;
z-index:9999;">
</a>Sovrappone un link invisibile su un pulsante reale "rubando" i clic dell'utente.
Spoof dei componenti di sistema
Alcuni attacchi usano del CSS mimetico per replicare l'aspetto di finestre di sistema (e.g. avvisi di sistema iOS o Android):
.fake-alert {
position: fixed;
bottom: 0;
width: 100%;
background: #fff;
padding: 15px;
box-shadow: 0 -2px 10px rgba(0,0,0,0.1);
font-family: -apple-system, sans-serif;
}Simulano notifiche che sembrano native ma sono falsi elementi DOM.
Come riconoscere l'UI Spoofing
Per l'nalisi del DOM runtime controlla dinamicamente: elementi con z-index troppo alti, con opacity: 0 o visibility: hidden ma pointer-events: auto ed elementi position: fixed che coprono grandi aree. Ecco un esempio in JavaScript:
<script>
document.querySelectorAll('*').forEach(el => {
const style = window.getComputedStyle(el);
if (
parseInt(style.zIndex) > 1000 &&
(style.opacity === '0' || style.visibility === 'hidden') &&
style.pointerEvents === 'auto'
) {
console.warn('Possibile spoofing:', el);
}
});
</script>I test automatizzati di sicurezza prevedono l'uso di strumenti come ZAP (OWASP) o Puppeteer che possono rilevare comportamenti sospetti. L'analisi dei click prevede poi di registrare click in aree non visibili o tracciarne le coordinate. Ciò può aiutare a capire se c'è un pulsante nascosto sopra l'interfaccia.
Come difendersi dal phishing
La CSP (Content Security Policy) richiede di bloccare l'inserimento di script o iframe esterni. Usa quindi direttive come:
Content-Security-Policy: default-src 'self'; script-src 'self'Il Frame Busting / X-Frame-Options previene invece attacchi di clickjacking esterno:
X-Frame-Options: DENYL'UI defensive design suggerisce poi di non mostrare finestre modali su fullscreen, usare CAPTCHA su azioni critichee e disegnare componenti di sistema in modo che non siano facilmente clonabili.
Mai fidarsi dei dati lato client. Anche se un form viene presentato in modo corretto, le azioni critiche devono essere validate su backend. È inoltre buona norma usare token unici per azioni di modifica dei dati. Se un utente è ingannato nel cliccare, l'azione non va comunque a buon fine se il token non è corretto. Si ricordi infine che un utente ben informato può riconoscere schemi sospetti o URL poco affidabili. L'educazione è ancora una delle prime difese.
Caso reale: spoof su login banking
Nel 2022 un attacco a un'app bancaria replicava perfettamente la finestra di login della piattaforma. Gli utenti venivano rediretti da un QR code falso. La pagina usava CSS identico all'app ufficiale e un form in POST verso un server fraudolento. L'interfaccia era indistinguibile da quella reale. Solo analisi approfondite nel DOM hanno mostrato che i file JavaScript e CSS provenivano da CDN diverse.
Tool Consigliati
- ZAP Proxy
- DevTools > Accessibility
- JS Detox
- Puppeteer / Playwright
Conclusione: i rischi del phishing via front-end
Il phishing via front-end — in particolare tramite UI spoofing — rappresenta oggi una minaccia reale e sottovalutata. A differenza del phishing tradizionale, che si affida a comunicazioni esterne come email o messaggi SMS, questo tipo di attacco si insinua silenziosamente all'interno dell'interfaccia che l'utente percepisce come sicura. Il front-end, pur essendo visibile e apparentemente controllato dagli sviluppatori, può diventare terreno fertile per trappole che risultano difficili da riconoscere, persino da occhi esperti.
Queste tecniche sfruttano le potenzialità di CSS, l'HTML semantico, e le dinamiche JavaScript per mascherare vere e proprie insidie: bottoni invisibili che deviano clic, finestre di login falsificate che sembrano identiche a quelle reali, notifiche contraffatte che richiamano l'estetica dei sistemi operativi. La cosa più pericolosa è che il codice può risultare perfettamente lecito e non essere rilevato dai classici antivirus o WAF (Web Application Firewall).
Difendersi richiede una strategia multilivello, che inizia dallo sviluppo e continua nel monitoraggio post-deploy. È fondamentale:
- progettare UI che siano difficili da imitare, evitando troppa somiglianza con componenti di sistema;
- implementare policy restrittive come CSP e X-Frame-Options;
- ispezionare regolarmente il DOM alla ricerca di elementi sospetti;
- integrare strumenti di analisi dinamica e test automatici;
- educare gli utenti rendendoli consapevoli che anche un clic può avere conseguenze gravi.
Un altro punto fondamentale è non fidarsi mai del front-end. Ogni dato o azione sensibile deve essere sempre convalidata lato server, attraverso meccanismi come token anti-CSRF, sessioni sicure e controllo di provenienza.
Infine, è importante ricordare che la sicurezza non è uno stato, ma un processo continuo. Gli attaccanti aggiornano costantemente i propri metodi. Di conseguenza, anche i team di sviluppo e sicurezza devono aggiornare le proprie conoscenze e strumenti, mantenendo alta la vigilanza anche su quelle parti del sistema — come la UI — che un tempo si pensavano "sicure per definizione".
Difendere un'applicazione significa anche difendere la fiducia dell'utente. Un utente che si sente tradito da un'interfaccia ingannevole, difficilmente tornerà.
