Attacchi drive-by: come una pagina può sfruttare un browser

Quando non serve un clic

Nel normale uso, una pagina può caricare script, immagini, caratteri e video. In base alle impostazioni del browser, gli script possono usare API grafiche, multimediali e WebAssembly. Elaborare questi contenuti offre un possibile percorso verso un difetto, anche se chi visita la pagina non ha aperto allegati né concesso nuovi permessi.

Un exploit richiede una vulnerabilità concreta e un contenuto capace di attivarla. Tra i possibili bersagli ci sono il motore JavaScript, il codice di rendering e la decodifica multimediale. Caricare una pagina non concede ai suoi script privilegi di sistema. Se l'exploit riesce, può trasformare un difetto del browser in esecuzione di codice nel processo coinvolto, che resta soggetto alla sandbox e ad altre restrizioni.

I browser moderni separano i siti e limitano i processi che mostrano le pagine, come spiega ladocumentazione di Chrome sull'isolamento dei siti. Compromettere quel processo non dà automaticamente pieno accesso al dispositivo: possono servire altre falle per uscire dalla sandbox o ottenere più privilegi. Uncaso analizzato da Google nel 2024combinava un difetto del processo della pagina con una fuga dalla sandbox di Chrome. La catena prendeva di mira versioni Android specifiche non aggiornate, non ogni visitatore.

Dove colpiscono gli exploit moderni

Motori JavaScript. Motori come V8 e SpiderMonkey includono compilatori e una gestione complessa della memoria. Una falla può consentire comportamenti imprevisti dentro un processo del browser. Di norma quel processo è vincolato dalla sandbox: il codice del motore non dispone semplicemente di privilegi illimitati sul sistema operativo.

Elaborazione grafica. WebGL e WebGPU espongono funzionalità grafiche tramite API controllate dal browser. Browser e driver possono avere difetti, ma gli shader non arrivano all'hardware senza verifiche. Una falla grafica non dimostra, da sola, che si possa uscire dalla sandbox.

Elaborazione di immagini e media.I browser decodificano file complessi provenienti da pagine non fidate. Una falla nel decoder può essere sfruttabile, ma l'effetto dipende dal difetto e dal processo in cui avviene la decodifica. Le sandbox del browser e del sistema possono limitare il danno; un caso relativo a un'app di messaggistica non proverebbe l'esistenza di un exploit per browser.

WebAssembly e worker. Permettono ai siti di eseguire codice o attività in contesti separati, entro le regole del browser. Usarli non costituisce un exploit. Un difetto della loro implementazione o di componenti collegati può però aprire un'altra strada a un aggressore.

Come arriva il contenuto ostile

Il contenuto controllato dall'aggressore deve comunque raggiungere il browser. MITRE documenta pubblicità malevole, siti compromessi, risorse di terze parti manomesse e script o finestre incorporate. La frequenza di questi canali cambia da campagna a campagna: nessuno è sempre il più usato.

Una pubblicità malevola può inserire codice in uno spazio pubblicitario; un attacco a un sito frequentato da un gruppo preciso è invece più mirato. Nessuno dei due compromette automaticamente ogni visitatore: il codice può prima controllare browser e dispositivo, oppure richiedere un'azione successiva. Per il caso delle pubblicità, leggi la nostra guida alla pubblicità malevola.

In un caso documentato nel 2024, siti governativi mongoli compromessi caricavano di nascosto una finestra controllata dagli aggressori. Ilrapporto del Threat Analysis Group di Googledescrive catene di exploit diverse inviate a visitatori iOS e Android selezionati, con versioni vulnerabili. Le falle avevano già una correzione, ma i dispositivi non l'avevano ancora ricevuta o applicata. Il caso mostra come un sito fidato possa diventare un canale di consegna, non che ogni visita abbia successo.

Dal rilascio della correzione all'installazione

Pubblicare una correzione non protegge un browser che esegue ancora una versione vulnerabile. I tempi variano secondo produttore, piattaforma, supporto del dispositivo e politica degli aggiornamenti: indicare ore o settimane fisse sarebbe fuorviante. Il caso Google del 2024 mostra che falle già corrette restavano sfruttabili su specifici dispositivi non aggiornati.

Un aggressore può prendere di mira una falla nota dopo che è disponibile una correzione: è il caso di un «n-day». Può anche usare una falla prima che esista una correzione, cioè uno «zero-day». Tempo necessario per costruire un exploit e durata dell'esposizione variano. Tieni aggiornati browser e sistema operativo e controlla se un aggiornamento attende di essere applicato.

Il download automatico aiuta, ma l'installazione può richiedere un riavvio. Laguida di Google agli aggiornamenti di Chromespiega come verificare se ne occorre uno. I dispositivi gestiti possono seguire la politica dell'organizzazione: verifica la versione in esecuzione, invece di supporre che un aggiornamento scaricato sia già attivo.

Ridurre l'esposizione e limitare i danni

Le buone abitudini riducono l'esposizione, ma anche un sito familiare può caricare contenuti compromessi. Tieni aggiornato il browser, usa le protezioni integrate e, quando opportuno, limita script o pubblicità indesiderati. Antivirus e sistemi di protezione del dispositivo possono rilevare un programma malevolo o un comportamento sospetto, ma non garantiscono di riuscirci. Sandbox e isolamento dei siti offrono ulteriori barriere se qualcosa va storto.

Con un browser remoto come Browser.lol, il codice della pagina gira in un contenitore lontano dal browser locale. Cambia così il primo ambiente che un exploit incontra; quando non serve più, puoi terminare la sessione. Questo non dimostra che dispositivo e account siano al sicuro: file scaricati, credenziali inserite nel sito, appunti condivisi, trasferimenti di file e infrastruttura del servizio sono altre possibili vie. Tieni aggiornati sia il browser locale sia le immagini remote e tratta i file con cautela. Per capire la distinzione tra correzioni e zero-day, leggi la nostra guida agli exploit zero-day.