Script di terze parti ancora caricati da un dominio CDN abbandonato

Migliaia di siti web caricano ancora script di terze parti da un dominio di una content delivery network che qualcuno ha registrato nuovamente a luglio 2025, anni dopo che il servizio sottostante è stato dismesso. Il dominio era stato lasciato scadere, ma i suoi chiamanti non sono spariti: un articolo contribuito da Report URI, pubblicato da The Hacker News, riporta che migliaia di siti web, repository di codice e pagine di documentazione contengono ancora riferimenti hard-coded a nomi host sotto di esso. Il nuovo proprietario detiene il DNS wildcard su tutto il dominio, il che significa che qualsiasi nome host sotto di esso ora risolve verso un'infrastruttura che quella persona controlla. L'apex, l'indirizzo principale del dominio, attualmente serve una pagina di downloader multimediale piena di annunci, il che di per sé non è degno di nota. Ciò che conta è che la decisione su cosa caricheranno dopo quelle migliaia di pagine ora appartiene a uno sconosciuto, e nessuno degli interessati è stato avvisato, perché dall'esterno nulla si è rotto.

Questo schema non è ipotetico. A giugno 2024, il dominio polyfill.io, uno shim JavaScript incorporato in più di 110.000 siti, ha cambiato proprietario e ha iniziato a servire redirect condizionali ai visitatori su mobile. I siti che lo eseguivano non erano stati violati; avevano esternalizzato un tag script anni prima e non avevano mai rivisto la decisione. Un tag script è una riga di codice che dice a un browser di recuperare ed eseguire un file ospitato altrove, e uno shim è un piccolo pezzo di codice che colma le lacune nei browser più vecchi. Entrambi i casi condividono un problema che la maggior parte dei team di sicurezza non può controllare: il codice malevolo non è mai stato sul loro server, ed è arrivato molto tempo dopo l'ultimo deployment.

Gli strumenti lato server stanno guardando nel posto sbagliato, sostiene l'articolo. L'analisi statica, la scansione delle dipendenze e l'analisi della composizione del software esaminano ciò che un'organizzazione costruisce e distribuisce, ma uno script di terze parti non è nessuna di queste cose. Viene recuperato dal browser del visitatore, da un server che l'organizzazione non gestisce e non può controllare, in tempo reale a ogni visualizzazione di pagina. Questo lo rende unicamente ostile ai test convenzionali, perché la risposta può variare in base a geografia, user agent, referrer, ora del giorno e sessione. Un crawler che scarica il file una volta da un intervallo di indirizzi di un data center può ricevere una versione pulita, mentre un acquirente su una rete mobile in un altro paese ne riceve una più sinistra. Lo script di terze parti stesso detiene gli stessi privilegi del codice first-party: può leggere il DOM (la struttura della pagina che un browser costruisce), leggere i campi del modulo carattere per carattere mentre vengono digitati, leggere cookie e local storage, e fare richieste in uscita verso qualsiasi luogo desideri. Gli attacchi lato client di tipo Magecart non richiedono affatto una violazione del server; richiedono che un tag script approvato inizi a comportarsi diversamente.

C'è un osservatore affidabilmente presente per ognuna di quelle visualizzazioni di pagina: il browser che ha eseguito il codice. La Content Security Policy (CSP), un insieme di istruzioni che un sito invia ai browser elencando quali fonti di codice possono essere eseguite, è solitamente discussa come difesa contro il cross-site scripting, e lo è. La sua seconda funzione è più utile per un team di sicurezza che non sa ancora quale codice sta eseguendo: una policy può controllare quale codice è autorizzato a essere eseguito, bloccare il codice non autorizzato e segnalare quando ciò accade. Quelle segnalazioni provengono da sessioni reali, in luoghi reali, da utenti reali sui loro dispositivi reali, quindi un payload malevolo che si attiva solo per utenti loggati in un paese viene comunque segnalato, perché il browser che lo ha eseguito è ciò che invia l'avviso. L'articolo cita un esempio concreto: a settembre 2026, gli avvisi raccolti da Report URI hanno fatto emergere un cluster di siti di e-commerce compromessi che eseguivano una campagna di social engineering della famiglia 'ClickFix'. Loader codificati in Base64, cioè codice mascherato da testo ordinario, erano stati inseriti nei contenuti del CMS dopo una compromissione amministrativa, concatenandosi attraverso un redirector a un overlay falso 'verifica di essere umano' che inseriva un comando PowerShell negli appunti della vittima e lo rendeva persistente come attività pianificata. I nomi host controllati dall'attaccante sono emersi negli avvisi dai browser delle vittime mentre diversi di quei domini erano ancora valutati puliti dai principali servizi di reputazione. Nessuno scanner aveva segnalato le pagine, perché sul server erano a posto.

L'obiezione comune è che una Content Security Policy romperà il sito, ma in modalità report-only non può. Content-Security-Policy-Report-Only non applica nulla, non blocca nulla e non cambia alcun comportamento; segnala solo ciò che una policy avrebbe bloccato. Questo trasforma il primo deployment in un esercizio di misurazione sicuro e raccoglie tutti i dati necessari su quale codice è in esecuzione su un sito. Per la maggior parte delle organizzazioni, quell'elenco è molto più lungo di quanto si aspettassero, afferma l'articolo.

Per chiunque gestisca pagamenti con carta, la questione è già risolta. I requisiti 6.4.3 e 11.6.1 di PCI DSS versione 4.0.1 hanno smesso di essere best practice e sono diventati obbligatori il 31 marzo 2025. Insieme, richiedono che ogni script su una pagina di pagamento sia autorizzato, che la sua integrità sia garantita, che esista un inventario scritto con giustificazione aziendale, e che un meccanismo rilevi e avvisi su modifiche non autorizzate del contenuto della pagina di pagamento e degli header HTTP (le informazioni dietro le quinte che un server web invia insieme a ogni pagina). Un QSA, un valutatore di sicurezza qualificato che verifica la conformità ai pagamenti con carta, può e chiederà l'inventario, il meccanismo di allerta e la traccia di prove che ha prodotto. Report URI afferma che il suo prodotto può fornire tutti e tre.

L'articolo delinea un deployment in tre fasi: raccogliere i dati iniziali per una settimana, costruire un inventario da ciò che è stato segnalato, poi monitorare i cambiamenti nel tempo e approvarli o negarli. Cita anche una scansione giornaliera decennale dei primi un milione di siti che mostra l'adozione di CSP cresciuta di oltre il 12.000% nel decennio; l'articolo non nomina chi ha eseguito quella scansione. Questa crescita, sostiene, riflette un cambiamento più ampio in dove le organizzazioni hanno bisogno di visibilità: non solo su ciò che distribuiscono, ma su quale codice i browser dei loro utenti effettivamente eseguono.

Report URI si descrive nell'articolo come una piattaforma di sicurezza lato client che risponde a domande che un team di sicurezza non può altrimenti risolvere sul proprio sito: quali terze parti stanno eseguendo codice sulle sue pagine, quali sono cambiate da ieri, e quali stanno prendendo dati o comunicando con infrastrutture note per essere ostili. Gli script serviti agli utenti reali vengono sottoposti a hash e archiviati in modo che i cambiamenti possano essere identificati e investigati a posteriori, i nomi host vengono controllati rispetto alle informazioni sulle minacce, e le policy vengono monitorate per deviazioni, colmando il divario tra ciò che è stato approvato e ciò che è effettivamente in esecuzione. Il deployment non aggiunge JavaScript alla pagina né agent, moduli o SDK allo stack; il primo passo è aggiungere un header di risposta HTTP e leggere ciò che torna nelle successive 48 ore. I lettori dovrebbero valutare le raccomandazioni sapendo che l'articolo è un contributo di Report URI, il fornitore della piattaforma che descrive, e che si chiude con un'offerta di prova gratuita di 30 giorni che non richiede carta di credito né modifiche al codice del sito.

La lezione pratica per i proprietari di siti è che un tag script è una decisione a lungo termine. Ogni riferimento a un nome host esterno è una dipendenza da chi possiede quel nome host oggi, non da chi lo possedeva quando il codice è stato aggiunto, e queste non sono sempre la stessa azienda. Un inventario, una policy report-only e l'abitudine di rivedere vecchie integrazioni non fermeranno un attaccante, ma rendono possibile accorgersi quando un indirizzo da cui dipendono le tue pagine cambia mani. I lettori che desiderano una revisione strutturata di ciò che i propri siti caricano, e di come iniziare a monitorarlo, possono guardare ciò che AEU-I offre in IT security-first, infrastruttura e consulenza (https://aeu-i.com).