Pop-up dannosi: il rischio è il codice che non avete scritto

La domanda se i pop-up siano dannosi nasce da un’esperienza di navigazione: finestre che si aprono senza essere state chieste, inviti a iscriversi, promozioni che coprono il testo. Su quel piano la risposta è che dipende dall’uso, e riguarda l’esperienza dell’utente più che la sicurezza.

Per un’azienda che ha un sito la domanda è un’altra, e ha una risposta meno rassicurante. Il pop-up che compare sulle vostre pagine quasi mai è codice che avete scritto voi: è uno script caricato dal server di un fornitore — la piattaforma di automazione marketing, il servizio di chat, il gestore dei consensi, lo strumento di test — che viene eseguito nel browser dei vostri visitatori con pieno accesso a tutto ciò che c’è nella pagina.

1. Che cos’è un pop-up e chi lo genera davvero
2. Il rischio degli script di terze parti
3. Quando il pop-up è sintomo di una compromissione
4. Sovrapposizioni ingannevoli e finti moduli di accesso
5. Che cosa verificare sul vostro sito

Che cos’è un pop-up e chi lo genera davvero

Tecnicamente un pop-up è una finestra o un livello che si sovrappone al contenuto della pagina. Nella pratica odierna non è più una finestra separata del browser — quelle sono bloccate da tempo per impostazione predefinita — ma un elemento generato via JavaScript all’interno della pagina stessa: un livello che compare sopra il testo e che l’utente percepisce come una finestra a sé.

Questa differenza tecnica ha una conseguenza importante. Una finestra separata era un oggetto del browser, con confini precisi; un livello dentro la pagina è parte della pagina, ed eredita tutti i suoi permessi. Lo script che lo genera può leggere il contenuto della pagina, i campi di un modulo mentre vengono compilati, i valori memorizzati dal browser per quel sito.

Il punto è chi ha scritto quello script. Su un sito aziendale l’inventario tipico comprende il gestore dei consensi ai cookie, uno o più strumenti di analisi, una piattaforma per l’iscrizione alla newsletter, un servizio di assistenza in chat, talvolta un sistema di raccomandazione dei prodotti. Sono cinque o sei fornitori diversi, ognuno con il proprio codice in esecuzione sulle vostre pagine, e ogni aggiornamento che rilasciano arriva ai vostri utenti senza che voi lo approviate.

Il rischio degli script di terze parti

Da qui nasce una categoria di attacco che non richiede di violare il vostro server: è sufficiente compromettere uno dei fornitori il cui codice caricate. L’attaccante modifica lo script sul server del fornitore, e da quel momento il codice malevolo viene distribuito a tutti i siti che lo includono — i vostri visitatori lo ricevono da una fonte che il browser considera legittima, perché è quella che voi stessi avete autorizzato.

Le conseguenze possibili sono proporzionate ai permessi di uno script che gira nella pagina. Lettura dei dati inseriti in un modulo, comprese le credenziali di accesso a un’area riservata. Modifica del contenuto visualizzato. Reindirizzamento verso una pagina controllata dall’attaccante. Su un sito che tratta pagamenti, intercettazione dei dati della carta nel momento in cui vengono digitati.

È un rischio che appartiene alla categoria delle dipendenze, la stessa di cui abbiamo parlato a proposito delle patch delle applicazioni web, con un’aggravante: le dipendenze del server le aggiornate voi, quelle caricate nel browser le aggiorna il fornitore. Non esiste una versione da bloccare, perché lo script viene richiesto ogni volta che la pagina si apre. È anche il motivo per cui la classificazione OWASP dedica una categoria specifica all’integrità del software e dei dati.

Quando il pop-up è sintomo di una compromissione

C’è poi lo scenario che l’articolo di partenza citava di sfuggita e che merita più spazio, perché è quello in cui vi trovate a gestire un incidente: pop-up che compaiono sul vostro sito e che nessuno in azienda ha configurato.

Quando accade, la spiegazione non è mai il browser dell’utente. È codice iniettato nelle vostre pagine, e le vie di ingresso sono poche e ricorrenti: un modulo o un plugin del gestore dei contenuti con una vulnerabilità nota e non corretta, un’utenza amministrativa compromessa, un file caricato attraverso una funzione di upload che non verifica cosa riceve, o uno dei fornitori di cui sopra.

Il segnale arriva quasi sempre dall’esterno — un cliente che segnala, un motore di ricerca che marca il sito come non sicuro, un browser che mostra un avviso ai visitatori. Vale la pena sapere che a quel punto il danno reputazionale è già in corso, e che rimuovere lo script visibile senza individuare la via di ingresso significa ritrovarselo dopo qualche giorno.

Sovrapposizioni ingannevoli e finti moduli di accesso

L’uso ostile più efficace di un livello sovrapposto non è la pubblicità invadente: è la riproduzione di qualcosa che l’utente si aspetta di vedere. Un modulo di accesso che compare sopra la pagina reale, con la vostra grafica e il vostro logo, raccoglie credenziali con un tasso di successo che nessuna campagna di phishing via posta elettronica raggiunge — perché l’utente è già sul sito giusto, ha digitato lui l’indirizzo, e il certificato è valido.

Esiste anche la variante in cui l’elemento sovrapposto è invisibile o quasi, e serve a far compiere all’utente un’azione diversa da quella che crede: il clic atterra su un pulsante che non è quello mostrato. È una tecnica nota da anni e si contrasta con configurazioni specifiche del server, che però vanno impostate — e che su un’applicazione mai verificata quasi sempre non lo sono.

Il punto comune ai due casi è che la difesa non sta nell’attenzione dell’utente ma nella configurazione dell’applicazione. Chiedere ai visitatori di riconoscere un modulo falso sovrapposto a un sito autentico non è una misura di sicurezza.

Che cosa verificare sul vostro sito

Le domande utili sono cinque, e nella maggior parte delle aziende non hanno una risposta documentata. Quali script di terze parti vengono caricati dalle vostre pagine, e da quali domini. Chi li ha autorizzati e quando, perché spesso sono rimasti attivi strumenti dismessi anni prima. Se esistono restrizioni su ciò che quegli script possono fare, o se hanno accesso completo alla pagina. Se il gestore dei contenuti e i suoi moduli sono aggiornati. E se qualcuno controlla periodicamente che il codice consegnato ai visitatori sia quello previsto.

L’ultima è quella che manca sempre. Un sito viene verificato al momento del rilascio e poi vive per anni, mentre gli script di terze parti cambiano ogni settimana senza preavviso: una verifica fatta una volta descrive uno stato che il giorno dopo non esiste più.

In conclusione

I pop-up non sono dannosi in quanto tali, e usati con misura restano uno strumento legittimo. Ma per un’azienda la domanda giusta non riguarda l’invasività della finestra: riguarda l’origine del codice che la genera, i permessi con cui viene eseguito nel browser dei propri clienti, e la possibilità che quel codice cambi senza che nessuno se ne accorga.

Su questo fronte gli strumenti a disposizione dei visitatori — blocco dei pop-up, estensioni, programmi di protezione — non c’entrano nulla. La responsabilità sta da questa parte dello schermo.