La input validation, ossia la sanificazione dell’input, rappresenta una delle contromisure più efficaci e sottovalutate nella sicurezza informatica.
Gli amministratori e i security manager si concentrano su firewall sofisticati e sistemi di rilevamento avanzati. E invece, la maggior parte degli attacchi riesce a penetrare i sistemi attraverso input non validati: campi di form, parametri URL, upload di file e persino emoticon. È una vulnerabilità che costa poco da prevenire ma ha un costo enorme da rimediare.
Ogni singolo carattere inserito dagli utenti, ogni parametro ricevuto via API, ogni file caricato sul sistema deve essere considerato potenzialmente maligno fino a prova contraria. Il principio è semplice: non devi fidarti mai di niente che arrivi dall’esterno. Questa paranoia costruttiva trasforma la validazione dell’input da attività opzionale a fondamento architetturale di ogni sistema sicuro.
Ma basta relativamente poco per trasformare la paranoia da concetto negativo a prassi operativa sistematica, fornendo ai responsabili della sicurezza librerie di controlli pratici, metodologie di implementazione scalabili e framework di testing che rendano la sanificazione dell’input un pilastro automatico e non negoziabile di ogni progetto di sviluppo aziendale[1].
Un campo di input apparentemente innocuo può contenere migliaia di variazioni maligne. Un semplice campo “nome” può ricevere codice JavaScript a sufficienza per sferrare attacchi di cross-site scripting, comandi SQL per attacchi di injection e buffer overflow, oppure combinazioni creative di caratteri speciali progettate per confondere parser e interpreti.
La superficie di attacco cresce esponenzialmente per ogni campo non protetto.
La statistica più allarmante è quella di OWASP: le vulnerabilità di injection (che principalmente sono causate proprio da input non sanitizzato) rimangono costantemente nella top 3 delle minacce web da oltre un decennio. Non perché siano difficili da prevenire, ma perché continuano a essere trascurate durante lo sviluppo e vengono scoperte solo dopo il deployment in produzione.
L’approccio con le blacklist tenta di identificare e bloccare gli input maligni permettendo tutto il resto. Sembra logico, ma è matematicamente condannato al fallimento: esistono infinite variazioni di payload maligni, molte delle quali sono ancora sconosciute.
Un filtro che blocca la stringa di testo <script> può essere aggirato da <ScRiPt>, <script >, %3Cscript%3E e centinaia di altre varianti.
L’approccio con le whitelist ribalta la logica: definisce precisamente cosa è permesso e rifiuta tutto il resto. Un campo email accetta solo caratteri alfanumerici e alcuni simboli specifici (@, ., -, _) in posizioni predefinite. Qualsiasi altro carattere o pattern deve essere respinto automaticamente.
Questo approccio è intrinsecamente più sicuro perché riduce la superficie di attacco ad un insieme finito e controllabile di punti potenzialmente deboli.
La sanitizzazione efficace richiede controlli multipli applicati in sequenza.
Il primo livello verifica la lunghezza: un campo password deve essere lungo almeno 12 caratteri ma non più di 128, un codice fiscale esattamente 16 caratteri.
Il secondo livello controlla il formato: regex specifiche controllano email, telefoni, codici postali, e così eliminano immediatamente ogni input malformato.
Il terzo livello valida range e valori: un’età deve ricadere tra 0 e 120 anni (salute!), un mese tra 1 e 12 mesi, un codice paese deve pescare le sigle da una lista ufficiale.
Il quarto livello implementa la business logic: un utente non può inserire una data di nascita futura, non può ordinare più prodotti di quanti ne siano disponibili, non può accedere a risorse per cui non ha autorizzazioni.
La validazione dell’input nasconde insidie tecniche che possono vanificare anche implementazioni che apparentemente sembrano corrette. L’encoding rappresenta la sfida più insidiosa: lo stesso carattere può essere rappresentato in modi diversi (HTML entities, URL encoding, Unicode normalization). Il carattere < può apparire come <, %3C, \u003C, ognuno tecnicamente valido ma potenzialmente pericoloso.
Il double decoding crea vulnerabilità particolarmente subdole: un input viene decodificato dal web server, passa la validazione, e viene decodificato nuovamente dall’applicazione, rivelando caratteri pericolosi precedentemente nascosti. La stringa %253Cscript%253E diventa %3Cscript%3E dopo il primo decoding e <script> dopo il secondo, aggirando quei filtri che controllano solo il primo livello.
L’upload di file rappresenta una delle funzionalità più rischiose che un’applicazione web possa offrire, eppure spesso è implementata con controlli minimi. Non basta verificare l’estensione del file: un attaccante può rinominare un eseguibile maligno da malware.exe a documento.pdf e molti sistemi lo accetteranno senza effettuare ulteriori verifiche.
La validazione sicura dei file richiede controlli a livello di magic bytes (i primi byte che identificano realmente il tipo di file), scansione antimalware, quarantena temporanea e sandbox per garantire un’esecuzione sicura. I file caricati non dovrebbero mai essere eseguiti direttamente dal web server e dovrebbero essere memorizzati in directory separate dalla document root web.
Un altro aspetto trascurato è il fatto che lo stesso input può essere sicuro in un contesto e pericoloso in un altro. La stringa roberto'; DROP TABLE users; -- è perfettamente sicura se viene memorizzata come testo in un campo testuale di un database (come nel caso di questo articolo), ma è devastante se viene utilizzata in una query SQL non parametrizzata. Quindi, la validazione deve considerare non solo il contenuto dell’input, ma anche come verrà utilizzato.
Questo principio richiede una validazione specifica per ogni contesto: input destinati a query SQL richiedono escaping diverso da quelli destinati agli output HTML, che a loro volta differiscono dai parametri che servono per le chiamate di sistema. La stessa stringa può richiedere una sanitizzazione completamente diversa a seconda della sua destinazione finale.
La sanitizzazione dell’input crea inevitabilmente una certa tensione tra sicurezza e usabilità. Controlli troppo restrittivi frustrano gli utenti legittimi: un campo nome che rifiuta gli apostrofi blocca “D’Onofrio”, mentre uno che non accetta caratteri accentati discrimina “Marilù”. Ms controlli troppo permissivi aprono la porta a vulnerabilità anche sconosciute.
La soluzione è un trade-off che richiede una comprensione approfondita dei casi d’uso reali e l’implementazione di whitelist intelligenti, che accettino eccezioni legittime alla regola, pur mantenendo la protezione contro gli attacchi.
Spesso questo significa implementare logiche di validazione sofisticate che distinguono tra caratteri speciali legittimi e tentativi di exploit. L’AI generativa e i Large Language Models ci saranno d’aiuto? Visto che, a loro volta, sono suscettibili di prompt injection e possono essere aggirati?
La validazione dell’input deve avvenire a più livelli dell’architettura applicativa. La Client-side validation migliora l’user experience fornendo un feedback immediato all’utente, ma non offre alcuna sicurezza reale, perché può essere aggirata.
La Server-side validation rappresenta il controllo di sicurezza più efficace e deve essere implementata indipendentemente da qualsiasi validazione client-side.
La Database-level validation aggiunge un ulteriore livello di protezione attraverso i constraints, i triggers e le stored procedure, cioè quei meccanismi che verificano l’integrità dei dati anche se la logica applicativa viene compromessa. Questo approccio di defense-in-depth garantisce che nessun singolo punto di fallimento possa compromettere l’intero sistema.
[1] Il Manuale CISO Security Manager prepara alla certificazione CISSP e fornisce linee guida dettagliate per implementare sistemi di input validation robusti e scalabili, pattern di design sicuri e metodologie di testing per validare l’efficacia dei controlli implementati.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Fabrizio Saviano
Source link
