Script di terze parti sul tuo sito: ogni tag e un rischio

Apri il tuo sito web adesso e conta quanti servizi esterni carica. Google Analytics. Google Tag Manager. Facebook Pixel. Un widget di live chat. Google Fonts. jQuery da un CDN. Un banner per il consenso cookie. Un embed YouTube. Un feed Twitter. Un widget recensioni clienti. Uno strumento di heatmap come Hotjar.

Il sito aziendale medio carica tra 15 e 30 script di terze parti. Alcuni siti ecommerce ne caricano 40 o piu. Ognuno di quegli script viene eseguito con accesso completo alla tua pagina web. Possono leggere gli input dei moduli. Possono modificare la pagina. Possono intercettare i clic. Possono reindirizzare i visitatori. Possono rubare dati.

Se uno qualsiasi di quei servizi di terze parti viene compromesso, i tuoi visitatori ne sono coinvolti. Non perche tu abbia fatto qualcosa di sbagliato, ma perche hai dato fiducia al codice di qualcun altro per essere eseguito sulle tue pagine.

Questo e il rischio supply chain applicato al web, ed e una delle minacce alla sicurezza piu sottovalutate che le aziende affrontano oggi.

Cosa possono fare gli script di terze parti sulla tua pagina

Quando aggiungi uno script di terze parti al tuo sito (un tag <script> che punta a un dominio esterno), quello script viene eseguito con gli stessi permessi del tuo codice. Non c'e sandbox, nessuna restrizione, nessun confine. Ha accesso completo a:

• L'intero DOM: Puo leggere e modificare ogni elemento della pagina. Puo iniettare nuovi elementi, nascondere quelli esistenti, o cambiare testo e link.
• Dati dei moduli: Puo leggere tutto cio che un utente scrive nei moduli, incluse password, numeri di carta di credito, informazioni personali e credenziali di accesso.
• Cookie: Puo leggere i cookie non contrassegnati come HttpOnly, inclusi token di sessione e dati di tracciamento.
• Local storage e session storage: Puo leggere e scrivere nel local storage del browser, dove le applicazioni spesso memorizzano token e preferenze utente.
• Richieste di rete: Puo effettuare richieste HTTP verso qualsiasi dominio, incluso l'invio di dati raccolti a server esterni.
• Interazioni utente: Puo aggiungere event listener per tracciare clic, scroll, movimenti del mouse e digitazioni.

Il problema della supply chain

Gli attacchi supply chain sui siti web funzionano cosi: invece di attaccare il tuo sito direttamente, un attaccante compromette uno dei servizi di terze parti da cui il tuo sito dipende. Quando il servizio compromesso distribuisce il suo script modificato ai tuoi visitatori, il codice malevolo viene eseguito sulle tue pagine come se lo avessi messo tu stesso.

Per un approfondimento su come funzionano gli attacchi supply chain nel contesto dei plugin CMS, leggi il nostro articolo sugli attacchi supply chain tramite plugin.

Perche gli attacchi supply chain sono efficaci

• Scala: Compromettere una libreria o un servizio di terze parti popolare puo colpire migliaia o milioni di siti web contemporaneamente.
• Fiducia: I proprietari dei siti si fidano dei loro fornitori di terze parti. Gli script si caricano automaticamente ad ogni visualizzazione di pagina. Nessuno sta verificando manualmente il codice che si carica ogni volta.
• Stealth: La modifica malevola puo essere sottile, magari aggiungendo poche righe di codice che si attivano solo sulle pagine di checkout, o solo per visitatori da regioni specifiche.
• Persistenza: Finche il tuo sito carica lo script compromesso, l'attacco continua. E poiche gli script sono caricati dal server della terza parte, l'attaccante puo modificare il payload in qualsiasi momento senza toccare il tuo sito.

Il caso British Airways: una lezione da 230 milioni di dollari

La violazione dati di British Airways del 2018 e uno degli esempi piu istruttivi di attacco tramite script di terze parti. Gli attaccanti hanno iniettato uno script malevolo (successivamente identificato come parte delle operazioni del gruppo Magecart) che prendeva di mira specificamente la pagina di pagamento della compagnia aerea.

Cosa e successo

Gli attaccanti hanno modificato uno script caricato sul sito di British Airways. Lo script modificato era di sole 22 righe di JavaScript. Quando i clienti inserivano i dati di pagamento nella pagina di checkout, lo script copiava numero di carta di credito, data di scadenza, CVV e nome del titolare, e inviava questi dati a un server controllato dagli attaccanti.

L'attacco e durato circa 15 giorni prima di essere rilevato. Durante quel periodo, sono stati rubati circa 380.000 dettagli di carte di pagamento.

Le conseguenze

• L'ICO del Regno Unito ha inizialmente proposto una multa di 183 milioni di sterline sotto il GDPR. Poi ridotta a 20 milioni di sterline.
• British Airways ha affrontato un'azione legale collettiva dai clienti colpiti.
• Il marchio ha subito danni reputazionali significativi.

E la causa principale era la modifica di uno script di terze parti. I server della compagnia aerea non erano stati direttamente violati. L'attacco e avvenuto nel browser, tramite codice eseguito sulla macchina del cliente.

Per saperne di piu sugli attacchi alle pagine di pagamento, leggi il nostro articolo sul web skimming nell'ecommerce.

Script di terze parti comuni sui siti aziendali

Analytics e tracciamento

• Google Analytics / GA4: Caricato su quasi ogni sito aziendale. Traccia visualizzazioni di pagina, comportamento utente, conversioni. Esegue JavaScript estensivo su ogni pagina.
• Google Tag Manager: Particolarmente potente. GTM e essenzialmente una piattaforma per caricare e gestire altri script. Chiunque abbia accesso al tuo container GTM puo distribuire JavaScript arbitrario sul tuo sito senza toccare il tuo repository di codice.
• Facebook/Meta Pixel: Traccia il comportamento utente per scopi pubblicitari.
• Hotjar, Crazy Egg, FullStory: Strumenti di registrazione sessione e heatmap. Catturano interazioni utente in dettaglio.

Funzionalita

• Widget di live chat: Intercom, Drift, Zendesk Chat, Tidio. Caricano JavaScript significativo e spesso includono la capacita di iniettare overlay e pop-up sulle tue pagine.
• Widget recensioni clienti: Trustpilot, Google Reviews. Caricano contenuto esterno sulla tua pagina.
• Embed social media: Feed Twitter/X, gallerie Instagram, player YouTube. Ognuno carica script dalla rispettiva piattaforma.

Infrastruttura

• Librerie ospitate su CDN: jQuery, Bootstrap o altre librerie caricate da CDN pubblici come cdnjs, jsDelivr o unpkg.
• Web font: Google Fonts, Adobe Fonts caricano file di font e CSS associato da server esterni.
• Piattaforme consenso cookie: CookieBot, OneTrust, CookieYes.

Come verificare gli script di terze parti sul tuo sito

Metodo 1: Strumenti per sviluppatori del browser

1. Apri il tuo sito in Chrome o Firefox.
2. Apri gli Strumenti per sviluppatori (F12).
3. Vai alla scheda Network.
4. Ricarica la pagina.
5. Filtra per "JS" per vedere i file JavaScript.
6. Guarda la colonna "Domain". Ogni dominio che non e il tuo e uno script di terze parti.
7. Ripeti per le pagine chiave: homepage, pagina contatti, pagine prodotto, pagina checkout.

Metodo 2: Content Security Policy Report-Only

L'approccio piu approfondito e distribuire una Content Security Policy in modalita report-only. Questo dice ai browser di segnalare (ma non bloccare) ogni risorsa caricata sulla tua pagina che proviene da un dominio non nella tua lista approvata. In pochi giorni, avrai un quadro completo di ogni risorsa esterna che il tuo sito carica.

Subresource Integrity (SRI)

La Subresource Integrity e una funzionalita di sicurezza del browser che permette di verificare che gli script caricati da fonti esterne non siano stati manomessi. Funziona includendo un hash crittografico del contenuto atteso del file nel tag script.

Come funziona SRI

<script src="https://cdn.example.com/library.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8w"
  crossorigin="anonymous"></script>

Quando il browser scarica lo script, calcola l'hash del file e lo confronta con l'hash nell'attributo integrity. Se non corrispondono (il che significa che il file e stato modificato), il browser rifiuta di eseguire lo script.

Limitazioni di SRI

• Funziona solo per file statici. Se lo script di terze parti cambia frequentemente, l'hash non corrispondera dopo ogni aggiornamento e lo script si interrompera.
• Non funziona con script generati dinamicamente.
• Richiede aggiornamenti manuali. Ogni volta che lo script esterno viene aggiornato legittimamente, devi aggiornare l'hash sul tuo sito.

Content Security Policy (CSP)

Una Content Security Policy e un header HTTP che dice al browser quali fonti sono autorizzate a caricare risorse sulla tua pagina. E la difesa piu potente contro gli attacchi tramite script di terze parti, ma e anche una delle piu complesse da implementare correttamente.

Cosa controlla CSP

• script-src: Quali domini possono fornire JavaScript.
• style-src: Quali domini possono fornire CSS.
• img-src: Quali domini possono fornire immagini.
• font-src: Quali domini possono fornire font.
• connect-src: Quali domini possono ricevere richieste AJAX/fetch.
• frame-src: Quali domini possono essere incorporati in iframe.

Sfide della CSP

• Script inline: Molti servizi di terze parti richiedono script inline. CSP li blocca per impostazione predefinita a meno che non si usi 'unsafe-inline' (che vanifica gran parte dello scopo) o allowlisting basato su nonce/hash.
• Catene di terze parti: Google Tag Manager carica altri script, che possono caricare ancora altri script. Devi autorizzare ogni dominio nella catena.
• Rottura di funzionalita: Una CSP troppo restrittiva interrompera il tuo sito. Testare in modalita report-only prima e essenziale.

Self-hosting delle risorse critiche

Uno dei modi piu efficaci per ridurre il rischio di terze parti e ospitare le risorse internamente invece di caricarle da CDN esterni.

Cosa puoi ospitare internamente

• Font: Invece di caricare Google Fonts da fonts.googleapis.com, scarica i file dei font e servili dal tuo dominio.
• Librerie JavaScript: Invece di caricare jQuery, Bootstrap o altre librerie da CDN pubblici, includile nel tuo processo di build.
• Framework CSS: Come le librerie JavaScript. Ospitali internamente.

Impatto sulle prestazioni degli script di terze parti

• Lookup DNS: Ogni dominio esterno richiede un lookup DNS separato. 10 script di terze parti da 10 domini diversi significano 10 lookup DNS aggiuntivi.
• Overhead di connessione: Ogni dominio esterno richiede un handshake TLS e una connessione HTTP separati.
• Blocco del rendering: Gli script nel <head> bloccano il rendering della pagina finche non sono scaricati e analizzati.
• Blocco del thread principale: L'esecuzione JavaScript avviene sul thread principale del browser. Script di terze parti pesanti bloccano tutti gli altri processi.
• Spostamenti di layout: Contenuti di terze parti che si caricano dopo il rendering iniziale della pagina possono causare spostamenti di layout, un'esperienza utente negativa e un fattore nei Core Web Vitals di Google.

Implicazioni sulla privacy sotto il GDPR

Gli script di terze parti non sono solo un problema di sicurezza e prestazioni. Sono un problema di privacy e conformita, in particolare sotto il GDPR e la nLPD svizzera.

• Consenso: Sotto il GDPR, hai bisogno del consenso informato prima di caricare script di tracciamento. Il tuo banner per il consenso cookie deve effettivamente bloccare questi script fino al consenso dell'utente.
• Accordi di trattamento dati: Hai bisogno di un accordo di trattamento dati (DPA) con ogni terza parte il cui script elabora dati personali per tuo conto.
• Informativa sulla privacy: La tua informativa sulla privacy deve elencare ogni servizio di terze parti che raccoglie dati tramite il tuo sito web.
• Trasferimenti transfrontalieri: Se uno script di terze parti invia dati a server fuori dall'UE/SEE, hai bisogno di garanzie adeguate per i trasferimenti transfrontalieri di dati.

Un piano d'azione pratico

1. Audit e inventario: Crea un elenco completo di ogni script di terze parti sul tuo sito. Per ognuno, documenta lo scopo, chi lo ha aggiunto e se e ancora necessario.
2. Rimuovi cio che non ti serve: Sii onesto su cosa sta effettivamente fornendo valore. Meno script significa meno rischi, prestazioni migliori e conformita piu semplice.
3. Self-hosting dove possibile: Sposta font, librerie JavaScript, framework CSS e font di icone sul tuo hosting.
4. Implementa SRI per le risorse statiche.
5. Distribuisci una Content Security Policy.
6. Usa Tag Manager con cautela: Limita l'accesso al container GTM. Abilita l'autenticazione a due fattori per tutti gli utenti GTM.
7. Monitora: Configura il monitoraggio per rilevare cambiamenti negli script di terze parti caricati sul tuo sito.

Prossimi passi

Se sei preoccupato per gli script di terze parti sul tuo sito (e dopo aver letto questo articolo, dovresti esserlo), possiamo aiutarti. In Envestis eseguiamo valutazioni di sicurezza dei siti web che includono un audit approfondito degli script di terze parti, delle loro implicazioni sulla sicurezza, del loro impatto sulle prestazioni e del loro stato di conformita.

Contattaci per una valutazione. Ti daremo un quadro chiaro della tua esposizione a terze parti e un piano pratico per ridurla.