Ciao, e benvenuto nella quarta puntata della cinquantaduesima stagione. Oggi torniamo alla tesi della stagione, il client mente sempre, e la portiamo dentro un pericolo specifico e antico quanto il Web: cosa succede quando i dati che arrivano da fuori non sono davvero solo dati. Oggi capiamo dati e iniezioni.
Partiamo dal principio, perché è la radice del problema. Ogni singolo pezzo di dati che arriva dal client è un potenziale attacco. Non solo l'identità, non solo i permessi: proprio i dati, i valori che l'utente scrive nei campi, i testi, i numeri, tutto. Perché il client controlla ciò che manda, e può mandare qualsiasi cosa, non solo ciò che ti aspetti. Tu hai disegnato un campo per un nome, ma dall'altra parte c'è qualcuno che in quel campo può scrivere ciò che vuole, incluso qualcosa di studiato apposta per farti del male.
Voglio darti il cuore dell'iniezione, perché è un'idea sola. Il pericolo si chiama iniezione, e il suo cuore è una confusione: quando dei dati vengono scambiati per istruzioni. Il tuo programma prende ciò che l'utente ha scritto e lo mescola dentro un comando, per esempio una richiesta alla banca dati. Se l'utente scrive un nome normale, tutto bene. Ma se scrive qualcosa costruito ad arte, quel qualcosa smette di essere trattato come un nome, e viene eseguito come parte del comando. Il dato ha varcato il confine, ed è diventato codice. Da valore, a ordine.
Voglio farti vedere la dinamica, perché è chiara con un parallelo. Immagina di dettare a qualcuno una lettera da firmare, e quel qualcuno la firma senza leggerla. Tu volevi dettare un saluto, ma dentro il testo hai infilato, di nascosto, una frase come: e regala tutti i miei soldi a chi porta questa lettera. Chi firma senza rileggere ha eseguito un ordine credendo di scrivere un saluto. L'iniezione è questo: il programma prende ciò che gli hai passato e lo esegue, senza distinguere tra la parte che era davvero un dato e la parte che, di nascosto, era un comando.
Voglio darti la difesa, perché è concettualmente semplice. La difesa nasce da un principio solo: non mescolare mai dati non fidati dentro a un comando come se fossero parte del comando. I dati vanno tenuti separati, trattati sempre e solo come dati, per quanto strani siano. Non li si incolla dentro l'istruzione: li si passa a parte, in un canale che dice chiaramente questa è roba dell'utente, trattala come inerte. Così, anche se l'utente scrive qualcosa che sembra un comando, resta una stringa senza potere, perché non è mai stata messa nel posto dove i comandi vengono eseguiti.
Voglio allargare l'idea, perché va oltre la banca dati. L'iniezione non riguarda solo le banche dati. La stessa confusione, dati scambiati per istruzioni, compare ovunque un programma costruisca un comando mescolandoci dentro roba che arriva da fuori: comandi di sistema, indirizzi, testi che finiranno mostrati ad altri utenti. È una famiglia di problemi, non uno solo. Ma la cura è sempre la stessa idea: tieni saldo il confine tra ciò che è dato e ciò che è istruzione, e non lasciare mai che l'utente, dall'esterno, lo attraversi a modo suo.
Voglio darti l'immagine che rende chiara questa idea, perché è antica. Pensa al cavallo di Troia. Sembrava un dono, un oggetto inerte, e lo fecero entrare dentro le mura senza sospetto. Ma dentro il dato, il cavallo, erano nascoste le istruzioni, i soldati. La città cadde non perché le mura fossero deboli, ma perché qualcosa che sembrava un semplice oggetto è stato lasciato entrare senza controllarne il contenuto, e una volta dentro ha agito. L'iniezione è il cavallo di Troia dei programmi: un dato dall'aria innocua, che porta dentro un comando.
Voglio trarre la lezione generale, perché è il fulcro. La lezione è che, dietro la porta, ogni dato che arriva è sospetto finché non è provato innocuo, e la difesa non è indovinare quali dati siano cattivi, ma tenere un confine netto: i dati sono dati, i comandi sono comandi, e i due mondi non si mescolano mai per mano dell'utente. Chi tiene saldo quel confine è immune a un'intera famiglia di attacchi. Chi lo lascia sfumare, anche per comodità, apre una porta a chiunque sappia travestire un ordine da informazione.
Per oggi ci fermiamo qui. Abbiamo visto dati e iniezioni. Ogni dato che arriva dal client è un potenziale attacco, perché il client può mandare qualsiasi cosa, non solo ciò che ti aspetti. L'iniezione è una confusione: dati scambiati per istruzioni, quando ciò che l'utente scrive viene eseguito come parte di un comando. Come dettare una lettera che qualcuno firma senza leggere, con dentro un ordine nascosto. La difesa è un principio solo: non mescolare mai dati non fidati dentro a un comando, tenerli separati e trattarli come inerti. E vale ovunque, non solo per le banche dati. Come il cavallo di Troia: un oggetto dall'aria innocua che porta dentro istruzioni. La lezione: tieni saldo il confine tra dato e istruzione, e non lasciare mai che l'utente lo attraversi. Nella prossima puntata: la conversazione allo scoperto, cifrare il canale. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.