← Tutti gli episodi
Copertina di Non fidarti di ciò che arriva: il pericolo dell'input
Stagione 18 · Episodio 005

Non fidarti di ciò che arriva: il pericolo dell'input

29 agosto 2026 5:30
0:00 5:30

Ciao, e benvenuto nella quinta puntata della diciottesima stagione. Nelle scorse puntate abbiamo protetto la conversazione e affrontato l'identità. Oggi arriviamo a uno dei principi più profondi e importanti di tutta la sicurezza informatica, un'idea che, una volta capita, ti fa vedere una quantità enorme di vulnerabilità sotto una luce unica. È un principio che si può riassumere in una frase: non fidarti mai di ciò che arriva da fuori. Oggi capiamo perché tanti problemi di sicurezza nascono da un'unica radice: fidarsi ciecamente dei dati che vengono dall'esterno.

Partiamo dall'idea di fondo, che è semplice ma potentissima. Un sito, un programma sul Web, riceve in continuazione dati dal mondo esterno: ciò che gli utenti scrivono nei moduli, ciò che arriva dalla rete, ciò che proviene da altri sistemi. La tentazione naturale, e l'errore fatale, è trattare questi dati come se fossero innocui, come se fossero esattamente ciò che ci aspettiamo. Ma non è così: i dati che arrivano da fuori possono essere stati preparati da un malintenzionato, con l'intenzione di ingannare il programma. E se il programma si fida ciecamente di ciò che riceve, senza controllarlo, può essere indotto a fare cose che non dovrebbe. La fiducia cieca nell'input è la radice di innumerevoli guai.

Voglio spiegarti il meccanismo profondo con cui questo inganno funziona, perché è illuminante, restando sul piano concettuale. In un programma, c'è una distinzione fondamentale tra due cose: le istruzioni, cioè i comandi che dicono al programma cosa fare, e i dati, cioè le informazioni su cui il programma lavora. Normalmente questi due mondi sono separati. Il pericolo nasce quando un programma, ingenuamente, mescola i dati che arrivano da fuori con le proprie istruzioni, senza tenerli ben distinti. Perché allora un malintenzionato può nascondere, dentro quelli che sembrano innocui dati, delle istruzioni camuffate, e se il programma le mescola alle proprie, finisce per eseguire i comandi dell'attaccante credendo di trattare semplici dati.

Facciamo un'analogia, senza dettagli tecnici. Immagina una segretaria che esegue istruzioni scritte su foglietti, e che riceve anche messaggi dai visitatori, da trascrivere. Finché tiene separate le due cose, gli ordini da eseguire e i messaggi da trascrivere, tutto va bene. Ma immagina che un visitatore furbo scriva, dentro il suo messaggio, qualcosa formulato in modo da sembrare un'istruzione, e che la segretaria, confondendo le due cose, lo esegua invece di trascriverlo. Nascondendo un ordine dentro un messaggio, ha fatto compiere alla segretaria un'azione che non doveva. Questo è il cuore di un'intera famiglia di attacchi: infilare istruzioni là dove ci si aspettano solo dati.

Questa famiglia di problemi, in cui dati ostili vengono scambiati per comandi, è storicamente una delle cause più diffuse e gravi di vulnerabilità sul Web. Per anni, moltissimi degli attacchi più dannosi hanno sfruttato proprio questa radice: programmi che si fidavano dell'input e mescolavano dati ostili con le proprie operazioni. È un problema subdolo perché nasce da una svista comprensibile: quando scrivi un programma, è naturale concentrarsi sul caso normale, in cui i dati sono innocui, e dimenticare che qualcuno, un giorno, manderà dati preparati apposta per ingannarti. La difesa richiede un cambio di mentalità: assumere sempre che l'input possa essere ostile.

E veniamo dunque alla difesa, che riprende il principio da cui siamo partiti ma lo rende operativo. La prima regola è: tratta ogni dato che arriva da fuori come sospetto, potenzialmente ostile, finché non hai verificato il contrario. Non fidarti mai ciecamente. La seconda regola è: tieni sempre ben separati i dati dalle istruzioni, non lasciare mai che ciò che arriva da fuori possa essere scambiato per un comando. La terza è: controlla e ripulisci ciò che arriva, verificando che abbia la forma che ti aspetti e rimuovendo o neutralizzando ciò che potrebbe essere pericoloso, come un filtro all'ingresso. Trattare ogni cosa in arrivo come sospetta, e filtrarla alla porta, è la difesa fondamentale contro un'intera classe di attacchi.

Voglio elevare questo a una lezione più generale, perché va oltre la tecnica ed è un principio di saggezza. Il principio non fidarti di ciò che arriva da fuori, verifica sempre, è una delle idee più profonde della sicurezza, e in fondo anche della vita. Non si tratta di paranoia, ma di prudenza sana: riconoscere che non tutto ciò che arriva è benevolo, e mettere un controllo consapevole al confine tra il tuo mondo e il mondo esterno. I sistemi sicuri sono quelli che hanno confini chiari e vigilati, dove ciò che entra viene esaminato prima di essere accolto. La fiducia va data, ma dopo la verifica, non prima. Questo confine vigilato tra dentro e fuori è uno dei fondamenti di ogni buona difesa.

Per oggi ci fermiamo qui. Uno dei principi più profondi della sicurezza è non fidarsi ciecamente dei dati che arrivano da fuori, perché possono essere preparati da un malintenzionato per ingannare il programma. Il meccanismo dell'inganno sta nel mescolare i dati ostili con le istruzioni del programma, così che comandi camuffati da dati vengano eseguiti, come una segretaria che scambia un messaggio per un ordine. È stata storicamente una delle cause più diffuse di vulnerabilità. La difesa è trattare ogni input come sospetto, tenere i dati separati dalle istruzioni, e filtrare alla porta. La fiducia va data dopo la verifica, non prima. Nella prossima puntata vediamo la versione di questo problema che colpisce nel browser: il codice degli altri nella tua pagina. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.