Sicurezza delle applicazioni web: l'architettura spiegata per i principianti

Chi inizia a sviluppare per il web tende a immaginare la sicurezza come qualcosa che si aggiunge alla fine: un antivirus, un firewall, un plugin. È un'immagine confortevole e completamente sbagliata. La sicurezza non è un elemento che si inserisce nel prodotto finito, è una proprietà del modo in cui il prodotto è stato costruito.

La differenza è fondamentale. Un'applicazione web è come una casa. Non puoi rendere sicura una casa installando una serratura costosa sulla porta d'ingresso se i muri sono di cartone e le finestre non si chiudono. La sicurezza viene dalla struttura, non da un accessorio incollato sopra.

Questo articolo spiega, senza presupporre conoscenze preliminari, come l'architettura di un'applicazione web ne determina la sicurezza. È per i principianti che vogliono comprendere i fondamenti giusti fin dall'inizio, prima di entrare in abitudini che sarebbe costoso annullare in seguito.

L'anatomia di un'applicazione web

Per parlare di sicurezza bisogna prima capire i partiti. Un'applicazione web ha, in poche parole, tre livelli e ognuno ha il suo ruolo in termini di sicurezza.

Il client è ciò che viene eseguito nel browser dell'utente: le schermate, i pulsanti, ciò che la persona vede e tocca. Il server è il luogo in cui avviene la vera logica, lontano dagli occhi dell'utente. E il database è il luogo in cui vengono archiviate le informazioni.

Tra questi strati, i dati viaggiano attraverso la rete. Questa semplice struttura contiene già la lezione di sicurezza più importante per i principianti, ed è da lì che inizieremo.

La regola d'oro: mai fidarsi del cliente

Se ricordi solo un principio di questo articolo, ricorda questo: tutto ciò che viene eseguito nel browser dell'utente è sotto il controllo dell'utente e quindi può essere manipolato. Il cliente è territorio nemico.

I principianti commettono l'errore di imporre controlli di sicurezza al client. Convalidano il modulo nel browser, nascondono un pulsante a chi non ha il permesso, controllano se il valore è valido sullo schermo. Tutto ciò è positivo per l'esperienza dell'utente e assolutamente inutile per la sicurezza. Un utente malintenzionato ignora semplicemente lo schermo e parla direttamente con il server, inviando ciò che vuole.

La conseguenza architetturale è chiara: ogni decisione sulla sicurezza deve essere presa sul server. Convalida dei dati, controllo delle autorizzazioni, regole aziendali, tutto questo risiede sul server, dove l'utente non può raggiungere. Il cliente suggerisce; decide il server. Questa separazione è la spina dorsale della sicurezza web.

I due pilastri: chi sei e cosa puoi

Praticamente tutta la sicurezza delle applicazioni si basa su due concetti che i principianti tendono a confondere.

Autenticazione dimostra chi sei. È il login: nome utente e password, forse un secondo fattore. Risponde alla domanda “sei davvero chi dici di essere?”.

Autorizzazione definisce cosa puoi fare una volta identificato. Risponde alla domanda “ti è permesso farlo?”

La confusione tra i due genera uno dei fallimenti più comuni che ci siano. Un sistema conferma il login (autenticazione) ma si dimentica di verificare, in ogni azione, se quell'utente ha diritto a quei dati (autorizzazione). Il risultato è il classico attacco che prevede la modifica di un numero nell'URL e l'accesso alle informazioni di qualcun altro, un difetto che è in cima alle liste di OWASP da anni.

In architettura ciò significa due controlli distinti. Confermare l’identità all’ingresso non è sufficiente. L'autorizzazione deve essere verificata ogni volta che si accede a una risorsa. Dimenticare il secondo è come controllare il badge di chi entra nel palazzo ma lascia tutte le stanze sbloccate.

Protezione dei dati in transito e inattivi

I dati di un'applicazione esistono in due stati ed entrambi necessitano di protezione.

In transito è quando i dati viaggiano tra il client e il server sulla rete. In questo caso la protezione è crittografia della comunicazione, tramite HTTPS. Senza questo, chiunque su una rete condivisa, ad esempio il Wi-Fi pubblico, può intercettare e leggere ciò che viene trasmesso, comprese le password. HTTPS oggi è uno standard basilare e non negoziabile.

A riposo è quando i dati vengono archiviati nel database. La protezione più importante da comprendere per i principianti è la gestione delle password: non dovrebbero mai essere archiviate così come l'utente le ha digitate. Passano attraverso un processo chiamato hash, che li trasforma in qualcosa di irreversibile. Quindi, anche se la banca viene trapelata, le password non sono leggibili. Salvare le password in formato testo è forse il peccato mortale più comune per i principianti.

Le classiche minacce prevenute dall'architettura

Alcune categorie di attacchi sono così comuni che ogni principiante dovrebbe conoscerle per nome. Appaiono nell'elenco OWASP, il riferimento globale per i rischi delle applicazioni web.

L'Iniezione avviene quando i dati inviati dall'utente vengono interpretati come comandi dal sistema. Il caso classico è l'iniezione SQL, in cui un campo modulo viene utilizzato per ingannare il file database. La difesa dell'architettura consiste nel non mescolare mai direttamente i dati dell'utente con i comandi, trattando sempre l'input come dati e mai come istruzioni.

Cross-site scripting (XSS) si verifica quando il codice dannoso inviato da un utente finisce per essere eseguito nel browser di un altro. La difesa consiste nel trattare e sfuggire a tutto ciò che arriva dall'esterno prima di visualizzarlo sullo schermo.

Il modello comune di queste minacce è lo stesso principio di prima: i dati provenienti dall’esterno non sono affidabili e devono essere convalidati ed elaborati sul server prima di qualsiasi utilizzo. L’architettura sicura è, in larga misura, un’architettura che sistematicamente diffida degli input.

Riflessione per chi ha appena iniziato

La trappola mentale più pericolosa per il principiante è "il mio progetto è troppo piccolo per essere attaccato". E' esattamente il contrario. La maggior parte degli attacchi non sceglie obiettivi, ma sono bot automatizzati che scansionano Internet alla ricerca di difetti noti. Un progetto piccolo e scarsamente protetto è proprio l’obiettivo più facile per queste scansioni. Nessuno deve volerti attaccare; basta una porta aperta trovata per caso.

C’è anche la dimensione legale che i principianti ignorano. In Brasile, la LGPD rende responsabili di proteggerli coloro che raccolgono i dati delle persone, indipendentemente dalle dimensioni del progetto. Costruire in sicurezza fin dall'inizio non è solo una buona pratica tecnica, è una responsabilità legale ed etica nei confronti delle persone che ti hanno affidato i loro dati.

Non è necessario padroneggiare tutto per iniziare nel modo giusto. I fondamenti dell'architettura, non fidarsi mai del cliente, separare l'autenticazione dall'autorizzazione, crittografare la comunicazione, proteggere le password, convalidare tutti gli input, mettono già un principiante davanti a un enorme numero di applicazioni sul mercato. La sicurezza, all’inizio, riguarda meno le tecniche avanzate e più il non commettere gli errori basilari che sai come evitare.

Imparare a disegnare in sicurezza fin dal primo progetto è un investimento che si ripaga molte volte. Rifare un sistema costruito senza queste fondamenta è costoso e doloroso; costruirlo fin dall’inizio è solo questione di abitudine.

Se stai iniziando a sviluppare per il Web e vuoi costruire sulle basi giuste, ci sono altri articoli di blog su autenticazione, OWASP, LGPD e architettura sicura che approfondiscono ciascuno di questi punti. Se si tratta di un momento di apprendimento o di processo decisionale nella tua organizzazione, vale la pena parlarne.