idee che impediscono un’efficace protezione per le API

0
50

This post is also available in: Inglese Francese Tedesco Portoghese, Brasile Spagnolo

Non è un segreto per nessuno che ogni moderna applicazione utilizza API per interagire con i suoi diversi componenti, i suoi utenti e, a volte, con servizi esterni. Infatti, l’uso delle API è aumentato durante il 2021. Secondo una ricerca di mercato, il traffico di attacco API ha triplicato la sua crescita rispetto al traffico API complessivo. Oltre a questo, Gartner stima che più del 50% di tutti gli incidenti di furto dati nel 2021 è riconducibile ad API non protette.   

Perché allora la protezione delle API non ha tenuto il passo con l’uso delle stesse? In base a quanto apprendiamo dalle società stesse in merito alle loro strategie di protezione API, sembra che molte formulino idee false che lasciano le API vulnerabili ed esposte a minacce.  
 
Idea n.1: Il mio WAF protegge le mie applicazioni e le loro API 

Per quanto quest’idea sia corretta da un certo punto di vista, le API sono esposte a molti vettori di minaccia dai quali la maggior parte dei web application firewall (WAF) non può proteggere.  

Per cominciare, la maggior parte delle soluzioni WAF sono state sviluppate per proteggere le vulnerabilità delle applicazioni web.   Le API, per contro, richiedono un’analisi specifica, come la capacità di analizzare il loro contenuto e confrontarlo con lo schema specifico dell’API. Gli WAF standard normalmente non includono questo tipo di capacità. 

In secondo luogo, la maggior parte delle soluzioni WAF (specialmente i cloud WAF (Web managed services) implementano solo modelli di sicurezza negativi. Questo impedisce alle soluzioni di fornire protezione contro gli attacchi zero-day, che sono attacchi sconosciuti per i quali non esiste ancora una firma. La top ten dei vettori di minaccia OSWAP dedicata alle API include molti tipi di attacchi che semplicemente non possono essere coperti attraverso un modello di sicurezza negativo. Richiedono invece un modello di sicurezza positivo e un’analisi comportamentale per stabilire se la chiamata API sia dannosa o meno – una caratteristica che la maggior parte dei WAF semplicemente non ha. 

Ci sono infine anche minacce automatizzate, compresi i bot malevoli, che rappresentano un grosso problema per le API. Come distinguere tra un bot malevolo e una chiamata machine-to-machine legittima? Soluzioni di bot management più avanzate, in grado anche di analizzare le chiamate API, si rendono necessarie per proteggersi contro gli attacchi da bot malevoli, quali account take over (ATO), data scraping e altre tipologie di attacchi DoS alle applicazioni. Attualmente, nessun WAF offre tale funzione. 

[Ti potrebbe interessare anche: Five Common Pitfalls in Application Protection]

Idea n.2: Il mio gateway API gestisce e protegge le mie API 

I gateway API sono sempre stati progettati per gestire il ciclo di vita delle API, tradurre i protocolli, instradare le chiamate API verso la destinazione corretta e gestire le quote così da garantire che le risorse del server che gestiscono le chiamate API non vengano esaurite o abusate. 

Inoltre, i gateway API autenticano l’entità che effettuata la chiamata API per assicurarsi che sia autorizzata ad effettuare ciascuna chiamata specifica. Alcuni gateway API dispongono inoltre di un motore integrato signature-based per fornire un’ulteriore protezione alle chiamate API gestite. Per quanto si tratti in ogni caso di funzioni importanti, esse non sono sufficienti a fornire una protezione API efficace. Ad oggi non ci sono soluzioni gateway API che includano una protezione API con un motore a modello di sicurezza positivo, capacità di protezione bot, analisi comportamentale e protezione DoS delle applicazioni. 

Sapevi che tutte le chiamate API vengono centralizzate per passare attraverso i gateway API? Questo vale solo per le API conosciute e gestite. Conseguentemente, in diverse aziende ci sono molte API non documentate e non gestite che non vengono affrontate – ed è impossibile proteggere ciò di cui non si conosce l’esistenza. 

Inoltre, la maggior parte dei gateway API include hook per l’integrazione con soluzioni di protezione API di terzi. Si tratta di una dichiarazione trasparente da parte dei vendor di API, che comprendono il limite del loro gateway API nel proteggere le stesse API che gestiscono. 

Idea n.3: Le mie API sono ben documentate, consentendo una protezione efficace 

In effetti per proteggere efficacemente un’API se ne devono conoscere perfettamente la struttura, i possibili parametri, la tipologia e l’intervallo di valori e il contenuto atteso del corpo dell’API. API ben documentate combinate con una buona soluzione di protezione API possono far aumentare significativamente la protezione. 

Tuttavia, nella maggior parte dei casi, non tutte le API usate in un’azienda sono ben documentate. E anche se lo fossero, le API cambiano più frequentemente delle applicazioni. Ne deriva che la loro documentazione e la policy di sicurezza devono essere regolarmente aggiornate; un’operazione che non viene svolta con la regolarità necessaria. E se si chiede agli architetti della sicurezza, la maggior parte di loro dirà che non si fidano della documentazione API. 

Qualsiasi soluzione efficace di protezione API deve includere la scoperta automatica delle API. Ciò comporta scoprire non solo la loro esistenza ma anche la loro struttura (ovvero, lo schema), i loro parametri, il tipo di parametri e i loro intervalli di valore. Un buon motore di scoperta può anche generare e applicare automaticamente una politica di sicurezza su misura per le API scoperte così da proteggerle efficacemente. Questo è il miglior modo per proteggere efficacemente un’API durante il suo ciclo di vita. 

[Ti potrebbe interessare anche: How To Achieve Application Protection Behind AWS/Azure CDN]

Idea n.4: Ho una soluzione di protezione API dedicata – sono coperto 

Disporre di una buona protezione API che si attenga alle raccomandazioni di questo blog è un ottimo inizio. Ma è solo questo – un inizio – e non basta a proteggere pienamente le tue applicazioni. Le API non esistono da sole. Esse sono parte di un’applicazione. E quest’ultima viene installata su un’infrastruttura. Non trovando un modo per entrare attraverso le API, gli hacker cercheranno di farlo attraverso una vulnerabilità dell’applicazione non collegata all’API. Essi possono lanciare un attacco bot o attaccare semplicemente l’infrastruttura mediante un attacco DDoS. 

La protezione delle applicazioni deve essere vista in termini olistici – il che significa che devono essere coperte tutte le basi. La tua protezione è solida quanto il tuo link più debole.  
 
La protezione API è soltanto un componente importante della tua architettura generale di protezione delle applicazioni, che dovrebbe includere un solido WAF, bot management, threat intelligence e protezione DDoS. Se puoi gestire queste soluzioni da un unico pannello e sincronizzarle, le tue applicazioni e le tue API saranno protette efficacemente. 

Vuoi saperne di più? Partecipa al nostro webinar per maggiori informazioni sulle best practice per affrontare le lacune di protezione presentate in questo blog.  

Ti è piaciuto il post? Registrati subito per ricevere ogni settimana le ultime novità Radware direttamente nella tua email oltre all’accesso esclusivo al Premium Content di Radware

Previous articlePerché le aziende non riescono a gestire gli attacchi bot in aumento
Yaron Azerual is a senior product marketing manager at Radware bringing 27 years of engineering, product management and product marketing experience from both large corporations such as Lucent, Avaya as well as from smaller companies and startups such as Alvarion and Wavion. Yaron brings deep understanding of both the development aspects of communication and security products and of the customer challenges those products should solve. He holds a bachelor's in electrical engineering from Tel Aviv University.

LEAVE A REPLY

Please enter your comment!
Please enter your name here