Script di terze parti: chi esegue codice sul vostro sito

Aprite il vostro sito aziendale e guardate cosa carica. Non le immagini e i fogli di stile: gli script. Nella maggior parte dei siti aziendali italiani sono fra dieci e trenta, provenienti da otto o dieci domini diversi, e in azienda quasi nessuno è in grado di dire a cosa serva ciascuno.

Ognuno di quegli script viene eseguito con gli stessi privilegi del vostro codice. Non in una sandbox, non con permessi ridotti: è la vostra pagina, e ne fa parte a tutti gli effetti.

Il rischio che ne deriva non è quello di un attaccante che forza il vostro server. È più prosaico e molto più comune: qualcuno ha accesso legittimo alle vostre pagine, quel qualcuno non lavora più con voi da tre anni, e nessuno gli ha revocato niente.

1. Chi si trova dentro la vostra pagina
2. Il tag manager è un accesso amministrativo
3. I tag orfani e come si accumulano
4. Quando il dominio da cui caricate cambia proprietario
5. La responsabilità sul consenso non si trasferisce
6. Le verifiche che chiudono il problema

Chi si trova dentro la vostra pagina

Uno script caricato da un dominio esterno può leggere i cookie non protetti, accedere al contenuto dei campi di un form prima che venga inviato, modificare quello che l’utente vede, spedire dati a qualunque destinazione e caricare ulteriori script.

L’ultima capacità è quella che rende il problema difficile da governare. Voi autorizzate un fornitore; il suo script ne richiama altri; nessuno di quei passaggi compare in una revisione del vostro codice, perché avviene nel browser del visitatore e in tempo reale. La catena di fiducia si estende a soggetti che non avete mai valutato, e cambia senza che ve ne accorgiate.

Cosa succede quando uno di quegli script viene manipolato è già descritto altrove su questo blog: le conseguenze dell’esecuzione di codice arbitrario nel browser dei visitatori sono l’oggetto dell’articolo sul cross-site scripting, e la compromissione di un sito legittimo per colpire chi lo frequenta quella dell’articolo sull’attacco watering hole. Qui il tema è a monte: come si è arrivati ad avere dieci soggetti dentro la pagina, e chi decide.

Il tag manager è un accesso amministrativo

I sistemi di gestione dei tag esistono perché il marketing possa inserire tracciamenti senza chiedere una pubblicazione all’IT. È una scelta di efficienza sensata, con una conseguenza che raramente viene esplicitata nel momento in cui si distribuiscono le utenze.

Chi ha accesso a un tag manager può iniettare JavaScript arbitrario in tutte le pagine del sito, immediatamente, senza toccare il server web e senza passare da nessun controllo di codice. Sul piano dei privilegi effettivi è un accesso equivalente a quello di un amministratore dell’applicazione, e va governato come tale.

Nella pratica raramente lo è. Le utenze vengono concesse ad agenzie, consulenti e freelance per il tempo di un progetto e restano attive dopo; l’account che ha creato il contenitore appartiene a una persona che non lavora più in azienda; il secondo fattore è configurato su alcune utenze e non su altre. È il caso in cui il principio del privilegio minimo va applicato con la severità che riservereste a un pannello di amministrazione, perché il potere concesso è lo stesso.

La verifica è banale e quasi nessuno la fa: aprire l’elenco degli utenti del contenitore e chiedersi, per ognuno, se ha ancora un motivo per esserci.

I tag orfani e come si accumulano

La sequenza si ripete con una regolarità impressionante.

Un’agenzia esterna installa un tag per una campagna. La campagna finisce, il rapporto con l’agenzia si chiude. Nessuno rimuove il tag: chi potrebbe farlo non sa se serva ancora, e nel dubbio non tocca niente perché rimuovere qualcosa può rompere una misurazione. Anni dopo quel codice è ancora nella pagina, continua a raccogliere dati e a inviarli a una destinazione che nessuno in azienda è più in grado di identificare.

Il danno non è teorico e si articola su tre piani. Il tag continua a trasmettere dati dei vostri visitatori a un soggetto con cui non avete più un contratto — quindi nessun accordo sul trattamento in vigore. Continua a essere codice eseguibile che nessuno presidia, quindi una superficie in più. E impedisce di sapere con certezza cosa il vostro sito stia facendo, che è il presupposto di qualunque dichiarazione fatta a un cliente o a un auditor.

Quando un fornitore esce, la revoca degli accessi va trattata come parte della chiusura del rapporto, insieme alla rimozione di quello che ha installato. È una delle voci che vale la pena formalizzare nel processo di valutazione dei fornitori, in ingresso e in uscita.

Quando il dominio da cui caricate cambia proprietario

Questo è il caso peggiore, ed è la conseguenza diretta del precedente.

Il vostro sito carica uno script da un dominio esterno. Quel servizio viene dismesso, la società chiude o semplicemente qualcuno dimentica di rinnovare la registrazione. Il dominio torna disponibile e chi lo registra eredita la possibilità di eseguire codice su tutte le pagine che lo richiamano ancora, senza aver violato nulla: il vostro sito continua a chiederglielo, richiesta dopo richiesta, per ogni visitatore.

Non è uno scenario ipotetico ed è un mercato attivo: i domini scaduti da cui molti siti caricano ancora risorse hanno un valore proprio per questa ragione. Il vostro browser non distingue fra il proprietario di ieri e quello di oggi, e nemmeno voi, perché la pagina continua a funzionare come sempre.

L’unico modo per accorgersene è verificare periodicamente le origini esterne e controllare che ognuna sia ancora chi credete che sia. È un controllo che rientra in una valutazione delle vulnerabilità del sito, insieme alle configurazioni errate della categoria descritta nell’analisi della security misconfiguration.

La responsabilità sul consenso non si trasferisce

Accanto al rischio tecnico c’è quello amministrativo, e ha una caratteristica che sorprende: resta vostro qualunque cosa faccia il fornitore.

Se sul vostro sito uno script imposta cookie di profilazione prima che l’utente abbia espresso un consenso valido, chi risponde è il titolare del trattamento — cioè voi. Non l’agenzia che ha installato il tag, non la piattaforma che lo fornisce. Il fatto che nessuno in azienda ne conoscesse l’esistenza non attenua nulla: descrive il problema anziché giustificarlo.

Ne segue un paradosso che vale la pena vedere in faccia. Un banner configurato con cura, che blocca correttamente tutto ciò che è dichiarato, mentre un tag non censito lavora comunque a monte, produce una situazione peggiore dell’assenza di banner: documenta per iscritto un’intenzione che i fatti smentiscono. Per i soggetti in perimetro, la direttiva NIS2 aggiunge il requisito di valutazioni tracciabili sulla catena di fornitura, e il codice terzo eseguito sulle vostre pagine ne fa parte a pieno titolo.

Le verifiche che chiudono il problema

Cinque controlli, in ordine di rendimento rispetto allo sforzo.

I primi tre sono verifiche organizzative: costano poche ore e le può fare chi conosce il sito. Sul quarto vale la pena leggere l’articolo sul session hijacking, che tratta nel dettaglio quali attributi impediscono a uno script di leggere un cookie di sessione.

Il quinto è di natura diversa e chiude il ragionamento. Una politica sul contenuto eseguibile scritta in una configurazione dichiara quali origini sono ammesse; non dice se il browser la applica come previsto né se esistono modi per aggirarla. Da questo punto in avanti la distinzione fra vulnerability assessment e penetration test diventa concreta: il primo vi dice quali script vengono caricati e come sono configurati i cookie, il secondo verifica se da lì si arriva effettivamente alle sessioni dei vostri utenti.