Ciao, e benvenuto nella terza puntata della cinquantaduesima stagione. Oggi parliamo della distinzione che manda in confusione quasi tutti, e del buco di sicurezza più comune, più dannoso e più sottovalutato che esista nelle interfacce. Se lo capisci bene, hai già evitato la maggioranza dei disastri veri. Oggi capiamo l'autorizzazione.
Partiamo dalla distinzione, perché è tutto. Nella puntata scorsa abbiamo visto l'autenticazione: chi sei. Oggi c'è l'autorizzazione: cosa ti è permesso fare. Sono due domande diverse, e confonderle è la radice di innumerevoli guai. L'autenticazione controlla che tu sia entrato con la tua chiave. L'autorizzazione controlla che, una volta dentro, tu possa aprire proprio quella stanza, e non tutte le altre. Provare chi sei non ti dà il diritto di fare qualsiasi cosa: ti dà solo un nome verificato, a cui vanno poi associati dei permessi.
Voglio darti il buco più comune di tutti, perché è il cuore della puntata. Ed eccolo, il buco numero uno delle interfacce, quello che compare più di ogni altro. Il server controlla che tu sia entrato, ma dimentica di controllare che quella cosa sia tua. Immagina di chiedere i dettagli dell'ordine numero mille, ed è il tuo. Poi chiedi l'ordine numero milleuno, e il server te lo dà, anche se è di un altro cliente. Perché? Perché ha verificato che eri autenticato, ma non che quell'ordine specifico appartenesse a te. Ha controllato la chiave d'ingresso, non la proprietà della stanza.
Voglio farti vedere quanto è banale sfruttarlo, perché fa impressione. La cosa spaventosa è quanto sia facile. Non serve essere un genio, non servono strumenti sofisticati. Basta cambiare un numero. Vedi che il tuo ordine è il mille, provi il milleuno, il millesei, il duemila, e se il server non controlla la proprietà, ti restituisce i dati di sconosciuti, uno dopo l'altro. Interi archivi di dati personali sono finiti in mano ad attaccanti così, semplicemente cambiando un numero nella richiesta. Non un attacco raffinato: una porta lasciata aperta, dietro l'altra porta che invece era chiusa a chiave.
Voglio dirti perché ci si casca sempre, perché è istruttivo. Perché questo errore è così comune? Perché è invisibile durante lo sviluppo. Quando provi la tua applicazione, chiedi sempre i tuoi dati, e funziona tutto: vedi il tuo ordine, tutto a posto. Il bug appare solo quando qualcuno chiede, di proposito, i dati di un altro, e a te, mentre costruisci in buona fede, non viene in mente di provarlo. Funziona vuol dire funziona per l'utente onesto. La sicurezza è ciò che succede quando arriva quello disonesto, e quel caso, di solito, nessuno lo prova.
Voglio darti la regola che lo previene, perché è semplice da dire. La regola è tanto semplice a dirsi quanto facile a dimenticarsi: per ogni cosa a cui si accede, controlla non solo che il chiamante sia autenticato, ma che abbia il diritto di accedere proprio a quella cosa. Ogni volta, per ogni oggetto, senza eccezioni. Il permesso non è una proprietà della persona in generale: è una proprietà della coppia tra questa persona e questa cosa specifica. E va verificato sul server, sempre, perché il client, lo sappiamo, mente.
Voglio darti l'immagine che rende chiara questa idea, perché è perfetta. Pensa alla chiave magnetica di un albergo. Ti fa entrare nell'albergo, e apre la tua stanza, la trecentodue. Va tutto bene. Ma immagina un albergo dove, per un errore, quella stessa chiave apre anche la trecentotre, la trecentoquattro, tutte le stanze. Sei un ospite legittimo, sei entrato in modo legittimo, e ciononostante puoi frugare nelle camere di tutti. Il problema non è chi sei: è che la serratura controllava che fossi un ospite, non che quella fosse la tua stanza.
Voglio trarre la lezione generale, perché è il fulcro. La lezione è che l'autenticazione e l'autorizzazione sono due cose diverse, e la seconda è dove si nascondono i guai peggiori. Sapere chi è qualcuno è facile; ricordarsi di controllare, per ogni singola cosa, che abbia il diritto di toccarla, è la disciplina noiosa e ostinata che separa i sistemi sicuri da quelli che regalano i dati altrui cambiando un numero. Il buco più comune non è un attacco sofisticato: è una dimenticanza. E le dimenticanze si prevengono solo con l'abitudine di controllare sempre, anche quando sembra superfluo.
Per oggi ci fermiamo qui. Abbiamo visto l'autorizzazione, e la distinzione che confonde tutti: l'autenticazione è chi sei, l'autorizzazione è cosa ti è permesso fare. Il buco più comune delle interfacce è proprio qui: il server controlla che tu sia entrato, ma dimentica di controllare che quella cosa sia tua. Basta cambiare un numero nella richiesta per vedere i dati di sconosciuti. È così comune perché è invisibile in sviluppo, dove chiedi sempre i tuoi dati. La regola: per ogni cosa, controlla che il chiamante abbia diritto proprio a quella, ogni volta, sul server. Come una chiave d'albergo che, per errore, apre tutte le stanze. La lezione: il guaio peggiore non è un attacco raffinato, è una dimenticanza, e si previene controllando sempre. Nella prossima puntata: il client mente sempre, dati e iniezioni. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.