Una recente ricerca condotta da Barracuda ha rilevato che le applicazioni web presentano in media 20 vulnerabilità, che rischiano di esporle al furto di dati, alla compromissione degli account e ad accessi non autorizzati.

Si tratta di un numero significativo, ma è importante ricordare che non tutte le vulnerabilità comportano i medesimi pericoli. La stessa vulnerabilità può infatti rappresentare un livello di rischio completamente diverso a seconda dell'applicazione.

La gravità dipende dal contesto

Immaginiamo che la falla di sicurezza sia una serratura difettosa: se si trova sulla porta di un magazzino vuoto, potrebbe trattarsi di un problema relativamente minore; se invece la stessa serratura viene montata sulla porta di un caveau di una banca, il rischio cambia completamente.

Yaz Bekkar, Principal Consulting Architect XDR, International presso la Direzione Tecnica di Barracuda Networks

Questo discorso vale anche per le applicazioni web. Un componente obsoleto su un semplice sito di marketing, privo di accesso riservato o di dati dei clienti, può rappresentare un rischio relativamente basso. Se però quello stesso componente viene inserito in un portale clienti collegato a informazioni personali e sistemi di back-end, può trasformarsi in una priorità immediata.

Ecco perché la gestione delle vulnerabilità non può essere ridotta semplicemente a punteggi di gravità. Non sono questi ultimi che vengono sfruttati dagli autori degli attacchi, ma le vie di accesso.

Un piccolo problema di divulgazione delle informazioni potrebbe rivelare la versione del software in esecuzione. Un’altra vulnerabilità potrebbe esporre un endpoint amministrativo. Una terza potrebbe compromettere la sicurezza della sessione. Presi singolarmente, questi riscontri possono sembrare a rischio basso o medio. Ma, considerati nel loro insieme, possono portare alla compromissione di un sistema. La ricerca mostra chiaramente come le vulnerabilità a basso rischio possano essere combinate per esporre informazioni sensibili, rubare credenziali o ottenere accessi non autorizzati.

Per questo, i dirigenti aziendali non dovrebbero chiedere al proprio team di sicurezza quante vulnerabilità ci siano, ma quali vulnerabilità, o quali combinazioni di vulnerabilità, potrebbero offrire a un hacker una facile via d’accesso a qualcosa che non possono permettersi di perdere.

Un ordine di priorità che è consigliabile utilizzare vede tre elementi principali: l’esposizione, la sfruttabilità e l’impatto sul business. Concetti che possono equivalere alle seguenti domande: un aggressore può raggiungere questo punto debole? Con quanta facilità può sfruttarlo? A cosa potrebbe accedere in seguito?

Venti vulnerabilità non significano necessariamente venti emergenze. Sono venti pezzi di un puzzle, e la priorità è capire quali pezzi possano essere uniti dagli aggressori. E poi interrompere quel percorso prima che lo facciano.

Un'applicazione web non è statica

La ricerca ha evidenziato inoltre che molte vulnerabilità derivano da semplici disattenzioni, come ad esempio configurazioni errate, controlli di accesso inadeguati, software obsoleti o crittografia debole. Non si tratta sempre di una questione di scarsa sicurezza; ciò riflette anche il fatto che l’ambiente che i team di sicurezza devono proteggere è in continua evoluzione.

Un'applicazione web non è un prodotto statico. Viene continuamente aggiornata, riconfigurata e connessa a nuove API, servizi cloud e componenti di terze parti. Ogni modifica può alterare la superficie di attacco.

Ad esempio, un aggiornamento software può risolvere diverse vulnerabilità note, introducendo al contempo nuovo codice, nuove dipendenze o nuovi comportamenti. Una vulnerabilità in uno di questi componenti potrebbe essere individuata solo a distanza di settimane o mesi. Ogni aggiornamento fa parte del ciclo di sicurezza, non ne rappresenta la fine.

Immaginiamo che un'azienda aggiorni un portale clienti per correggere una falla nel sistema di autenticazione. L'aggiornamento risolve il problema iniziale, ma introduce anche una nuova libreria software e modifica il modo in cui il portale comunica con la propria API di backend. In seguito, si potrebbe individuare una vulnerabilità proprio in quella libreria, oppure la nuova configurazione potrebbe involontariamente esporre ulteriori dati.

Un'azienda può chiudere una porta, ma cambiando l'architettura possono apparirne altre. Ecco perché le vulnerabilità di base persistono nonostante l'aumento degli investimenti.

Strumenti più avanzati garantiscono una maggiore visibilità, ma non possono congelare un ambiente in continua evoluzione. L’obiettivo non è raggiungere uno stato permanente di totale assenza di vulnerabilità, bensì ridurre il tempo che intercorre tra la comparsa di una falla, la sua individuazione e la sua correzione in modo sicuro.

Sicurezza efficace: cosa significa all'atto pratico

Per una tipica PMI o azienda di medie dimensioni che desideri proteggere le proprie applicazioni web, può rivelarsi utile adottare il seguente approccio:

• Osservare l’azienda con gli occhi di un cybercriminale

Si inizia identificando ogni sito web, portale clienti, API, dominio e sottodominio esposto a Internet, comprese le vecchie applicazioni, gli ambienti di test e i servizi gestiti da agenzie esterne.

Ogni risorsa dovrebbe avere un responsabile designato, una funzione aziendale ben definita, il tipo di dati che gestisce e la data dell’ultima scansione di sicurezza.

Bisogna poi eliminare le esposizioni evidenti e non necessarie: applicazioni inutilizzate, elenchi di directory, informazioni di debug ed endpoint amministrativi o interni accessibili pubblicamente. Questo passaggio è particolarmente importante poiché la divulgazione di informazioni ha rappresentato il 25% delle vulnerabilità rilevate nello studio.

• Eliminare innanzitutto le strade d’attacco più brevi

Con una media di 20 vulnerabilità per applicazione, un’azienda che gestisce dieci applicazioni esposte online potrebbe trovarsi ad affrontare circa 200 risultati. Questo spiega perché un piccolo team di sicurezza non possa trattare ogni vulnerabilità in modo equivalente in un'unica, lunga coda di lavoro.

La priorità dovrebbe essere data a ciò che è esposto, sfruttabile e ad alto impatto.

In pratica, ciò significa occuparsi innanzitutto del software obsoleto esposto online, delle vulnerabilità note e già sfruttate, delle interfacce amministrative visibili all’esterno, delle fughe di dati sensibili e dei controlli deboli sull’autenticazione o sulle sessioni. Lo studio raccomanda scansioni continue, configurazioni rafforzate, rimozione dei software obsoleti e applicazione coerente dell’autenticazione a più fattori.

Laddove non sia possibile applicare immediatamente una correzione definitiva, l’azienda dovrebbe ridurre temporaneamente l’esposizione limitando gli accessi, disabilitando la funzionalità vulnerabile o isolando il servizio interessato.

• Verificare che la falla sia stata effettivamente risolta

Un ticket contrassegnato come “risolto” non garantisce che la vulnerabilità sia scomparsa.

L’applicazione dovrebbe essere sottoposta a una nuova scansione o riesaminata dopo ogni patch o modifica di configurazione importante. La correzione potrebbe non aver raggiunto tutti i sistemi, essere stata applicata in modo errato o aver introdotto un’ulteriore debolezza.

Questo passaggio è fondamentale poiché i cybercriminali possono combinare diversi riscontri apparentemente a basso o medio rischio in un percorso che porta al furto di credenziali, all’esposizione di dati sensibili o all’accesso non autorizzato.

L’obiettivo della sicurezza delle applicazioni web, dunque, non è azzerare le vulnerabilità, bensì azzerare ogni ambiguità: conoscere ogni porta pubblica, sapere chi è responsabile di chiuderla e accertarsi che sia davvero chiusa a chiave.