Le lacune nella sicurezza delle applicazioni Web

In che modo la sicurezza disparata porta al compromesso

La storia dell'Azienda A e dell'Azienda B

Questa è la storia dell'Azienda A e dell'Azienda B, i cui approcci alla sicurezza delle applicazioni Web e delle API, apparentemente diversi tra di loro, condividono un difetto, minimo ma di importanza cruciale. Questo difetto è sfociato in delle violazioni di dati (con tutte le conseguenze negative del caso) per entrambe le aziende.

L'Azienda A dispone della protezione API più solida possibile, in grado di bloccare tutte le violazioni dello schema e limitare le richieste eccessive, e utilizza l'intelligence delle minacce più recente per bloccare gli indirizzi IP dannosi conosciuti. L'utenticazione API basata su password potrebbe essere più sicura se fosse sostituita con il TLS reciproco, ma l'azienda non ancora riportato alcuna violazione.

Tuttavia, la sicurezza delle API, il feed di informazioni sulle minacce e il WAF provengono tutti da fornitori diversi. Grazie agli aggiornamenti dei fornitori, l'intelligence sulle minacce che alimenta la sicurezza API non è più compatibile con il WAF, che invece protegge la pagina di accesso agli account. Di conseguenza, un aggressore è in grado di utilizzare su questa pagina un nuovo exploit SQL injection, e ottenere il nome utente e la password di un utente legittimo. L'autore dell'attacco invia poi delle richieste autenticate e convalidate dallo schema alla propria API, ricavando enormi quantità di dati sensibili.

Dall'altra parte abbiamo l'Azienda B, la cui applicazione Web è invece blindata contro gli attacchi DDoS. Inoltre, l'Azienda B offre un'API a pagamento agli utenti che desiderano effettuare l'integrazione con questa applicazione.

In questo caso, l'aggressore acquista nel "dark web" la chiave API di un utente pagante, e con questa chiave sferra un attacco DDoS low-and-slow contro il server API dell'Azienda B. L'aggressore attiva quindi un bot che invia richieste a intervalli regolari. Ciascuna richiesta API inviata dal bot viene accettata come legittima dal server, in quanto è corredata da una chiave API accettabile. Malauguratamente, il team di backend dell'Azienda B si è dimenticato di far schermare il server API dal provider di servizi di mitigazione DDoS, benché tutti gli altri server aziendali siano protetti.

Man mano le che richieste si accumulano, il server API ne viene progressivamente travolto fino a non essere più in grado di lavorare quelle degli altri utenti, molti dei quali disdicono il proprio abbonamento a causa della frustrazione.

Qual è il problema che le Aziende A e B hanno in comune?

La disparità di soluzioni porta a sviste e a lacune nella sicurezza

Negli esempi mostrati, gli approcci alla sicurezza API e alla sicurezza delle applicazioni Web di entrambe le aziende erano di fatto un mosaico di soluzioni fornite da una moltitudine di provider. Le soluzioni non erano integrate ed erano inoltre soggette a errori manuali.

Per capire perché questo costituisca un problema, prendiamo in esame i componenti tipici di un sistema di sicurezza per le API e per le applicazioni Web:

• WAF: blocca gli attacchi sferrati contro le applicazioni e le proprietà Web

• Gestione dei bot: ha il compito di filtrare o bloccare possibili bot dannosi

• Mitigazione DDoS: mantiene le proprietà Web online durante attacchi DDoS di ogni tipo (volumetrici o low-and-slow)

• Protezione API: comprende la limitazione della frequenza, la validazione dello schema, l'autenticazione per le API

Entrambe le aziende avevano adottato tutte queste misure di protezione, ma poiché le loro soluzioni per la sicurezza erano diverse (anche se di ottima qualità), presentavano delle falle che gli aggressori sono stati in grado di sfruttare.

Nel caso dell'Azienda A sia la protezione API che il WAF erano stratificati piuttosto che integrati, e pertanto l'azienda si è trovata a dover fronteggiare e bloccare l'attacco. Gli attacchi bloccati dalla protezione API, però, potevano bypassare il WAF, e viceversa. La protezione DDoS dell'Azienda B non proteggeva l'infrastruttura API, la loro soluzione di gestione dei bot non è stata in grado di rilevare le richieste APi provenienti dai bot, e il loro sistema di autenticazione era debole e facilmente superabile.

Questi sono solo alcuni esempi di potenziali falle di sicurezza. Tra le altre falle nella sicurezza delle applicazioni Web troviamo:

• Intelligence delle minacce limitata: un'intelligence delle minacce non aggiornata, che non controlla nei posti giusti o che non è in un formato compatibile. Questo è ciò che è accaduto all'Azienda A.

• Troppa intelligence delle minacce e da troppe fonti: il risultato sono dei falsi positivi, ridondanze e altre inefficienze.

• Falsi positivi di bot: questo fenomeno può ingenerare frustrazione negli utenti, rallentare il servizio e provocare lassismo nei controlli.

• Alert fatigue: l'azienda media impiega 45 tool di cybersicurezza di diversi fornitori, ciascuno dei quali genera i propri avvisi. La presenza di una moltitudine di prodotti può far sì che i dipendenti ignorino le minacce per poter portare a termine i propri compiti.

• Autenticazione insufficiente: entrambe le aziende erano vulnerabili al furto di credenziali.

• Difesa dalle minacce non scalabile: le apparecchiature hardware di sicurezza generano strozzature nel traffico e vengono sopraffatte quando si verificano attacchi su larga scala o attacchi di tipologie diverse.

Queste lacune diventano sempre più rischiose, man mano che aumenta la complessità e la sofisticazione degli attacchi informatici. Per McKinsey, gli odierni autori degli attacchi "comprendono organizzazioni altamente sofisticate, che sfruttano tool e capacità integrate con l'intelligenza artificiale e l'apprendimento automatico." Questi aggressori spesso migliorano le proprie tattiche e si muovono più velocemente dei loro bersagli.

I rischi aggiuntivi delle API

Le API rivestono un'importanza sempre maggiore per l'infrastruttura delle applicazioni Web di un'azienda. Al giorno d'oggi, il 58% del traffico elaborato da Cloudflare è basato su API, e questa percentuale continua ad aumentare. Di fatto, molte aziende si descrivono come API-first. Inoltre, Cloudflare blocca una quota maggiore di traffico API dannoso rispetto al traffico Web, e questo dimostra che gli autori degli attacchi hanno le API costantemente nel loro mirino.

Poiché le API sono intrecciate in profondità alle applicazioni web, la loro sicurezza deve essere messa al primo posto. Spesso succede invece che i team di sviluppo facciano uscire le API in modo affrettato, e senza previamente consultare gli specialisti della sicurezza informatica. Il risultato è che numerose violazioni delle applicazioni Web sono riconducibili a una sicurezza API insufficiente.

Ad esempio, una violazione legata all'API ha colpito le Poste americane, quando si è scoperto che un'API che supportava il tracciamento in tempo reale dei pacchi mancava di alcune autorizzazioni di base. Gli utenti loggati potevano tranquillamente ottenere informazioni sugli account di altri utenti, utilizzando dei parametri di ricerca "wildcard" che potevano rivelare tutte le informazioni contenute nel set di dati. Questa falla ha messo a rischio i dati di 60 milioni di utenti registrati.

Una soluzione consolidata

E se invece la Società A e la Società B, invece di usare un'accozzaglia di soluzioni per la sicurezza, avessero raggruppato tutti i loro servizi di sicurezza per le API e le applicazioni web in un'unica piattaforma? E se questi servizi, diversi l'uno dall'altro, fossero stati integrati? E se i dati sullo stato dell'infrastruttura fossero stati consultabili da un'unico cruscotto, in modo che le aziende potessero valutare correttamente sia gli attacchi che il proprio stato di sicurezza?

L'Azienda A avrebbe potuto fare in modo che tutte le proprie applicazioni e il framework di sicurezza API fossero provvisti dell'intelligence delle minacce più recente e, grazie alla centralizzazione delle informazioni, avrebbe potuto stroncare l'attacco sul nascere. L'Azienda B avrebbe potuto estendere agevolmente la protezione dagli attacchi DDoS a tutti i propri server.

L'utilizzo di una piattaforma si traduce in una gestione più agevole, con meno lacune.

Questo approccio consolidato alla sicurezza delle applicazioni Web richiede un'infrastruttura altamente scalabile, capace di fungere da proxy per qualunque tipo di traffico. Nei decenni precedenti, quando le aziende dovevano difendersi da nuovi tipi di attacchi o avevano necessità di ampliare la propria postura di sicurezza, la soluzione era acquistare nuove apparecchiature. Un servizio basato su cloud, invece, è scalabile con maggiore facilità e può fungere da proxy per qualsiasi tipo di infrastruttura. Benché una piattaforma consolidata non rappresenta una garanzia contro tutti gli attacchi, di certo avrebbe potuto aiutare le nostre due aziende.

Più di un esperimento teorico: l'importanza crescente del WAAP

Questo non è solamente un mero esperimento teorico. Gartner definisce questi servizi consolidati come "Web Application and API Protection", o WAAP. Nel 2022, Gartner aveva previsto che "entro il 2024, il 70% delle aziende che implementano strategie multi-cloud per le applicazioni Web negli ambienti di produzione favoriranno servizi WAAP basati su piattaforma rispetto ai servizi WAAP basati su apparecchiature e IaaS-native."

"WAAP" non è semplicemente l'ennesimo acronimo, in quanto il consolidamento di WAF, della gestione dei bot, della protezione da attacchi DDoS, della sicurezza API e di altri servizi è sempre più essenziale per le aziende moderne. La natura globale di Internet espone le proprietà Web e le API ad attacchi sferrati da luoghi diversi e su diversi livelli di portata e complessità. Non è una sorpresa che nel 2022 IBM abbia segnalato che l'83% delle aziende interpellate aveva subito una violazione dei dati, con un costo medio nel mondo di 4,35 milioni di dollari e di 9,44 milioni negli Stati Uniti.

Un'altra considerazione: l'eterogeneità dell'infrastruttura

Se l'Azienda A e l'Azienda B dovessero costruire le proprie applicazioni e API dal nulla, oggi potrebbero alloggiarle interamente nel cloud, magari sfruttando un unico provider di hosting per facilitarne l'implementazione. Nella realtà la maggior parte delle aziende implementa infrastrutture ibride con server per database in locale e di tipo obsoleto, API di terze parti basate su cloud e servizi per applicazioni ospitati in più cloud. Queste implementazioni offrono numerosi vantaggi, ma sono gravate da specifici problemi di sicurezza.

Ad esempio, la sicurezza insita nel cloud di un dato provider può non estendersi alla totalità della sua infrastruttura. Per cominciare, anche la mappatura e la scoperta della sua infrastruttura, per poi provvedere alla sua difesa, può rivelarsi un compito difficile. Poi, i suoi prodotti di sicurezza potrebbero non essere compatibili con altre soluzioni presenti nel tuo stack tecnologico.

Pertanto, oltre a consolidare le capacità fondamentali per garantire la sicurezza delle applicazioni Web, il WAAP deve essere agnostico rispetto all'infrastruttura, ovvero deve essere in grado di anteporsi a qualsiasi tipo di infrastruttura o di distribuzione su cloud.

Sicurezza Web consolidata e agnostica rispetto all'infrastruttura

Cloudflare è cloud native e agnostico rispetto all'infrastruttura, offre sicurezza alle applicazioni Web da oltre dieci anni, e offre tutte queste capacità nella veste di un'unica piattaforma consolidata con un singolo pannello di controllo. Cloudflare gode inoltre del vantaggio di poter osservare un'ampia porzione del traffico Internet, poiché in media serve oltre 46 milioni di richieste HTTP al secondo e blocca 112 miliardi di minacce informatiche al giorno. Ciò consente all'azienda di sfruttare una visibilità assolutamente unica sulle minacce zero-day e sui nuovi attacchi.

Questo articolo fa parte di una serie sulle ultime tendenze e argomenti che hanno un impatto sui decisori tecnologici di oggi.

Approfondisci questo argomento.

Gartner ha nominato Cloudflare "azienda leader" nel Gartner® Magic Quadrant™ 2022 per Web Application and API Protection (WAAP).
Get the report!

Punti chiave

Dopo aver letto questo articolo sarai in grado di capire:

• Come soluzioni disparate possono creare lacune nella sicurezza

• Esempi di come potrebbero manifestarsi queste lacune

• Perché Gartner consiglia il consolidamento con una piattaforma di sicurezza delle applicazioni Web indipendente dall'infrastruttura

RISORSE CORRELATE

• Gartner® Magic Quadrant™ for Web Application and API Protection (WAAP)

• Le API hanno superato la sicurezza tradizionale

• Cloudflare One: la nostra piattaforma SASE