Ciao, e benvenuto nella settima puntata della cinquantaduesima stagione. Finora abbiamo difeso la porta da chi entra. Oggi guardiamo nella direzione opposta: cosa esce dalla porta. Perché a volte il problema non è ciò che lasci entrare, ma quanto dici tu, nel rispondere. Oggi capiamo i dati che trapelano: non dire troppo.
Partiamo dal problema, perché è più comune di quanto sembri. Immagina un'interfaccia a cui il client chiede i dati di un utente. Per mostrare un nome e una foto, servono due o tre informazioni. Ma il server, per pigrizia o distrazione, restituisce l'intera scheda: il nome, sì, ma anche l'indirizzo, il numero di telefono, la data di nascita, magari l'identificativo interno, a volte perfino tracce di dati che non dovrebbero mai uscire. Il client ne userà tre, ma il server ne ha spediti trenta. E quei trenta, ora, sono usciti dalla porta, e non tornano più indietro: una volta che un dato ha lasciato il tuo server, non puoi più richiamarlo, è nel mondo.
Voglio smontare l'illusione più diffusa, perché è il cuore della puntata. C'è un'illusione tipica, e va smontata: tanto l'applicazione mostra solo il nome e la foto, il resto l'utente non lo vede. Falso. L'applicazione mostra tre campi, ma la risposta completa, con tutti e trenta, è arrivata comunque fino al client. E lì chiunque può guardarla, così com'è, sotto la superficie di ciò che appare sullo schermo. Ciò che il server manda è pubblico verso il destinatario, punto. Nascondere un dato nell'interfaccia grafica non lo protegge: se è nella risposta, è già uscito.
Voglio darti il principio guida, perché è semplice. Il principio è quello che in sicurezza si chiama dare il minimo indispensabile. Rispondi con i dati che servono, e solo quelli. Non spedire tutto ciò che hai perché è comodo, e lasciare che sia il client a scegliere cosa mostrare. La risposta stessa è una superficie di attacco: ogni campo in più che esce è un campo in più che può finire dove non deve. Meno dici, meno puoi far trapelare. La domanda giusta, per ogni risposta, non è cosa posso mandare, ma qual è il minimo che basta. È lo stesso principio del dare a ciascuno solo i permessi che gli servono, applicato però ai dati: non solo chi può accedere, ma anche quanto di ciò a cui accede deve davvero attraversare la porta.
Voglio allargare a un altro modo di dire troppo, perché è insidioso. C'è un secondo modo di dire troppo, più sottile: i messaggi di errore. Quando qualcosa va storto, è comodo restituire tutti i dettagli tecnici: cosa è fallito, dove, come è fatto il sistema sotto. Comodo per te che stai correggendo, ma un regalo per l'attaccante, a cui stai raccontando come sei costruito dentro. Un errore dovrebbe dire, verso l'esterno, giusto quel tanto che serve a capire cosa fare, e tenere per sé, nei registri interni, tutti i dettagli succosi. Anche gli errori sono una voce che parla: falla parlare poco. Un attaccante spesso comincia proprio così, provocando errori apposta, per farsi raccontare, pezzo dopo pezzo, com'è fatta la macchina che vuole forzare: ogni messaggio troppo dettagliato è un tassello che gli regali.
Voglio darti l'immagine che rende chiara questa idea, perché è divertente e vera. Pensa a qualcuno a cui chiedi soltanto: che ore sono? E quello, invece di dirti l'ora, ti mette in mano tutta la sua agenda, con dentro ogni appuntamento, ogni indirizzo, ogni segreto. Tu volevi l'ora; lui ti ha dato la sua vita intera, perché era più semplice passarti il quaderno che cercare una riga sola. Rispondere con tutti i dati che hai, quando ne bastavano tre, è esattamente questo: consegnare l'agenda per dire l'ora.
Voglio trarre la lezione generale, perché è netta. La lezione è che la sicurezza non è solo controllare ciò che entra, ma misurare ciò che esce. Ogni risposta è una dichiarazione, e più dichiari, più superficie offri. Dai il minimo indispensabile, nei dati e negli errori, e ricorda che nascondere qualcosa nell'interfaccia grafica non è proteggerlo: se è nella risposta, è già in mano al destinatario. La riservatezza non si difende all'ultimo schermo: si difende alla fonte, decidendo cosa lasciare uscire dalla porta.
Per oggi ci fermiamo qui. Abbiamo guardato i dati che trapelano, cioè cosa esce dalla porta. Il problema tipico: il client chiede due o tre informazioni, e il server, per comodità, gli spedisce l'intera scheda, trenta campi invece di tre. L'illusione da smontare: tanto l'applicazione mostra solo il nome. Falso: la risposta completa è arrivata comunque al client, e lì chiunque può guardarla; nascondere un dato nella grafica non lo protegge. Il principio è dare il minimo indispensabile, perché la risposta stessa è una superficie di attacco. E vale anche per gli errori, che non devono raccontare come sei fatto dentro. Come chi, alla domanda che ore sono, ti passa tutta l'agenda. La lezione: misura ciò che esce, e difendi la riservatezza alla fonte. Nella prossima puntata: le chiavi del regno, i segreti. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.