I sette livelli della sicurezza delle applicazioni web: tutte le vulnerabilità e come affrontarle

La società digitale vive e “respira” attraverso le applicazioni web. Un passo importante verso la sicurezza delle informazioni è quello di comprendere i diversi livelli strutturali di cui le applicazioni si compongono, per mettere in atto un’efficace strategia di protezione. Questo perché le applicazioni possono essere soggette a vulnerabilità, che è utile conoscere per intervenire adeguatamente sul piano della cyber security.

Come funzionano le applicazioni

La logica funzionale delle applicazioni web, oggi non più riconducibile al solo paradigma client / server, continua peraltro a ruotare attorno ad un’architettura strutturata in 3 layer:

• Il layer della presentazione lato utente: è la dimensione che si preoccupa di fornire l’apparenza, la “facciata” del software, rivolta verso l’utilizzatore. Indipendentemente da quanti nodi di elaborazione la richiesta attraverserà prima di essere processata, ci sarà sempre un client a chiedere qualcosa e un sistema organico sottostante l’applicazione che risponderà ad essa.
• Il layer della logica di funzionamento (tipicamente l’algoritmo, il modello computazionale, che ne rende possibile l’esecuzione, anche in contesti bigdata); è la dimensione che definisce come i dati richiesti dal client verranno processati, quale flusso elaborativo (centralizzato in un server, o decentralizzato in cluster) attraverseranno e come saranno restituiti all’utente finale;
• Il layer dei dati o “del database”, dimensione fino ai primi anni 2000 dominata dal paradigma relazionale, oggi sempre più propensa all’utilizzo di tecnologie alternative, come i database noSql.

Sia il corretto funzionamento dell’applicazione, sia l’interoperabilità con gli altri servizi di cui necessita o a cui si accosta, in un contesto, come quello attuale, di operazioni differenziate e  dinamiche, richiedono la sinergica interazione di queste tre dimensioni, ognuna delle quali, a seconda del layer in cui ci troviamo, comporta e nasconde delle criticità e delle vulnerabilità.

I sette livelli della sicurezza delle applicazioni

Immaginando, a solo scopo accademico, di rappresentare la nostra applicazione web come un grafico a torta (scelto per la “democraticità”, conferita alla ripartizione dalla forma circolare, ad indicare che ogni “spicchio” ha la stessa priorità degli altri), è possibile identificare 7 grandi “fette”, corrispondenti a diversi contesti, portatori di altrettanto peculiari tipologie di vulnerabilità riscontrabili:

• Livello della sicurezza fisica: attiene alla pianificazione della sicurezza “materiale” dei locali strategici per il deploy del progetto; dai datacenter alle room di programmazione, dagli ambienti di test a quelli di collaudo, sia il layer della logica di business, sia il layer della base dati, devono essere adeguatamente protetti dall’intrusione e gestiti con attenzione sotto il profilo della resilienza e della continuità operativa.
• Livello di rete: sappiamo che ogni dato, ogni informazione che i nostri flussi elaborano, viaggiano nel mondo digitale come una sequenza di bit, all’interno di frame o, (a livello superiore) di Una corretta mappatura e l’eventuale segmentazione di rete, se supportata da uno studio preliminare degli asset dell’organizzazione e dall’oculata configurazione degli apparati (switch e router) consente di minimizzare la probabilità di occorrenza della violazione informatica e di progettare soluzioni ad alta ridondanza e resilienza.
• Livello sistemistico (sistemi operativi), è l’ecosistema più critico. I sistemi operativi attraverso le socket gestiscono il collegamento tra il numero di porta e l’indirizzo IP del destinatario della trasmissione, costituendo l’interfaccia tra l’utente e l’applicazione e rendendo possibile la comunicazione. Questo delicato “entry point” può essere utilizzato per violare i sistemi client (ma la minaccia è ben più cogente per i server, come vedremo tra poco) e manipolarli “dall’interno”, da riga di comando.
• Livello del web server, cioè del software che “ospita” il “dietro le quinte” dell’applicazione web. Non dimentichiamo infatti che, oltre al sistema operativo della macchina server, considerato al punto sopra, esiste un servizio apposito di “hosting” dell’applicazione, in ascolto su una certa porta e avente un certo “footprint” (impronta) che l’attaccante con opportune scansioni può scoprire e utilizzare per iniettare exploit. E’ opportuno dunque minimizzare le tracce che il servizio rilascia all’esterno, configurando correttamente il banner dei servizi remoti in modo tale che non dia informazioni (in particolare la versione del servizio).
• Livello del database dell’applicazione: la base informativa sottostante all’applicativo interagisce “per definizione” attraverso query con il software. Oltre ai dati in sé, primo asset da proteggere (anche attraverso tecniche crittografiche), ad essere meritevole di attenzione è anche il livello middleware (ad esempio il DBMS relazionale) che gestisce l’allocazione e la consistenza dei record del database, la profilazione degli accessi, l’affidabilità delle transazioni, le piccole macro di programmazione etc;
• Livello dei moduli di terze parti:  se l’applicazione web integra plugin o script di terze parti per realizzare certe funzionalità (pensiamo ad esempio al circuito di pagamento tramite una piattaforma bancaria o al marketing transazionale), tale “esternalizzazione” può incidere negativamente sull’assessment generale della sicurezza qualora rinunciassimo ad indagare anche sull’attenzione, la diligenza e la cura implementata dalla terza parte coinvolta, la quale, in caso contrario, potrebbe rappresentare “l’anello debole della catena”.
• Livello della logica applicativa: come abbiamo visto, l’applicazione web è sempre un software, cioè una serie di istruzioni in codice che, seguendo un algoritmo, compie dei passi in sequenza per raggiungere un obiettivo. Nonostante il progresso e l’evoluzione delle teorie alla base dell’ingegneria del software e la sempre più diffusa adozione di metriche e processi di valutazione della qualità, all’interno degli svariati blocchi di codice, che traducono i flussi operativi disegnati dall’essere umano per un’applicazione, è intrinsecamente presente una certa percentuale di errore residuo, alla base della minaccia degli attacchi zero-day, ossia le nuove vulnerabilità non ancora conosciute dalla comunità del settore e quindi altamente “rivendibili” sul mercato dell’hacking. Una possibile (e reattiva) contromisura a questo livello, oltre alla rigorosa (e preventiva) applicazione della metodologia OWASP di sviluppo di software sicuro, sta nel coordinamento con le fonti istituzionali (in questo caso i produttori dei software e la comunità di cybersecurity) e nella immediata applicazione delle patch di sicurezza una volta individuate, azione che andrà a ridurre la finestra di vulnerabilità cui l’organizzazione si esporrebbe se, al contrario, vi fosse una negligenza nel seguire gli aggiornamenti del settore o una latenza nella reazione.

Conclusione

Il grafico a torta ci ricorda che, pur essendo oggi il mondo delle applicazioni web in grosso fermento, e pur assistendo al passaggio epocale dal paradigma client-server, basato sul modello di base dati relazionale, a quello decentralizzato, basato su piattaforme computazionali di nuova generazione (cluster elaborativi, file system dedicati come GFS o HDFS in Hadoop  e database noSql, ad esempio Dinamo di Amazon, ma anche Cassandra e Ryac), un’applicazione web è ancora dotata di un cuore organico e di una sua integrità sistemica.

Essa tuttavia non è entità a sé stante ma è il risultato sinergico di tante dimensioni, alcune “orizzontali” (le prime tre che abbiamo individuato), altre trasversali, ognuna delle quali deve essere presa in considerazione per pianificare una strategia adeguata di cybersicurezza.