API Security : La nuova frontiera per i CISO

Articolo di Paolo Maggioni, Sales Specialist di Aditinet Consulting

L’esposizione di servizi tramite API sta diventando l’opzione più diffusa, specialmente nel mondo Finanziario e delle Fintech. L’utilizzo di API consente di fornire l’accesso ai propri servizi in forma standardizzata, semplificando drasticamente tutte le attività necessarie a permettere a terze parti od ad applicazioni mobile di interfacciarsi ai nostri sistemi. Le API dovrebbero essere intrinsecamente anche sicure fornendo nativamente meccanismi di autenticazione e di autorizzazione che permettono di verificare che ogni azione sia eseguita da un soggetto legittimato che opera esclusivamente all’interno dei privilegi che gli sono stati assegnati per il subset di aggetti a cui gli è consentito l’accesso.

Complessità, velocità e sicurezza

 Se le API sono intrinsecamente sicure perché, come ha indicato Gartner, dovrebbero diventare il principale vettore di attacco entro la fine di quest’anno? La risposta sta nella complessità di implementazione del meccanismo di autenticazione ed autorizzazione che porta spesso i developer a sottovalutare l’importanza dell’applicazione del concetto di Least Privilege portando così a lasciare esposta una superficie vulnerabile troppo ampia. Uno studio di Knight Ink fatto nell’arco di 12 mesi del 2021 ha portato per esempio a verificare che di 55 applicazioni finanziarie mobile che utilizzavano API, 54 avevano chiavi hard coded nel codice che le lasciavano potenzialmente esposte ad attacchi di tipo Men in the Middle.

Nuove metodologie di attacco e la necessità di nuovi strumenti di protezione

Un acronimo che si sta sentendo sempre più spesso è BOLA, Broken Object Level Authorization, un sigla che individua una vulnerabilità specifica delle API che ha scalato tutte le posizione nella classifica delle OWASP Top10. Le vulnerabilità di tipo Broken Object si manifestano a livello applicativo quando i controlli sulle autorizzazioni all’accesso delle risorse sono troppo laschi ed una API può accedere in maniera fraudolenta a certi dati/servizi utilizzando un Token legittimo che le è stato rilasciato per accedere solo al proprio specifico subset.  

E’ chiaro che gli attacchi che sfruttano questo tipo di vulnerabilità non possono essere intercettati dagli strumenti messi sinora in opera per difendere le applicazioni, anche per il WAF più sofisticato quello che passa è uno scambio legittimo di pacchetti correttamente autenticati ed autorizzati e lo scam passa ad un livello applicativo troppo alto perché possa rilevarlo. Sempre lo studio del 2021 di Knight Ink ha portato a rilevare che il 100% delle API finanziarie teste nel corso dei 12 mesi era vulnerabile ad attacchi di tipo OWASP API1:2019 ( BOLA ) ed OWASP API2:2019 ( Broken Authentication ) con potenziali effetti disastrosi quali cambi fraudolenti del PIN utenti o illegittimi trasferimenti di fondi.

Automazione e supporto ai developer

Il fattore umano, ovvero la pressione a cui sono sottoposti i developer per rilasciare sempre più velocemente nuove funzionalità, è ovviamente la causa principale della presenza di questa tipologia di vulnerabilità. La prima contromisura da prendere è quindi legata alla Pipeline di sviluppo dove è necessario introdurre degli strumenti di supporto ai developer che li aiutino ad individuare tutte le casistiche di Broken Authorization e Broken Authentication già durante lo sviluppo dell’applicazione, quando correggere gli errori è ancora semplice e veloce.  Stiamo parlando di strumenti di DAST ( Dynamic Application Security Testing ) integrati nella Pipeline in grado di generare automaticamente attacchi specificatamente indirizzati all’exploit di vulnerabilità di tipo BOLA e di segnalarle allo sviluppatore in modo che possa risolverle prima che possano andare in produzione.

Strumenti del behaviuor delle API

Considerato che comunque non tutte le vulnerabilità potrebbero essere risolte in fase di sviluppo e che certe tipologie di attacco possono passare dai WAF senza essere rilevate, diventa fondamentale implementare una linea di difesa ulteriore specificatamente disegnata per la rilevazione degli attacchi alle API. Gli strumenti di nuova generazione devono essere in grado di analizzare il comportamento e la composizione delle API con utilizzo di Intelligenza Artificiale ed algoritmi di Machine Learning in modo da “imparare” sia le correlazioni fra gli oggetti da proporre che le tipologie di utilizzo in modo da poter attivare gli strumenti di reazione automatici quando si individua una situazione sospetta.

Discovery e Documentazione delle API

Un capitolo a parte merita la tematica del discovery e della documentazione delle API. Sul piano teorico tutte le API esposte dovrebbero passare da un API Gateway/API Manager per consentirne un pieno controllo. Sul piano pratico si rileva invece che mediamente un 30% delle API esposte sono “rogue”, non conosciute all’API Gateway e pubblicate in forma silente dai responsabili dell’applicazione. Questa situazione è fonte di potenziali esposizioni e da qui la nascita di nuovi strumenti in grado di analizzare il traffico del Datacenter ed individuare tutte gli API endpoint, siano essi conosciuti o meno.

Una componente fondamentale del Discovery è quella relativa alla tipologia dei dati esposti da ciascuna API e di conseguenza del potenziale rischio che una violazione comporta. Per ogni API dovrebbe sempre noto quando si stanno esponendo dati sensibili, dati personali o credenziali ma questo non sempre è correttamente indicato nella documentazione. Una soluzione di API protection di nuova generazione deve essere perciò in grado di classificare tutti i dati esposti, segnalare la presenza di dati sensibili e, soprattutto, segnalare le eventuali incongruenze con la documentazione prodotta dai developer.

 A questo punto è però doverosa anche una spiegazione su cosa si intenda per documentazione quando si parla di API: stiamo parlando di quello che viene chiamato OpenAPI file ( una volta riferito come Swagger file ) , l’oggetto che descrive completamente l’API con un formato standard interoperabile ed utilizzabile da tutti gli strumenti di gestione.

L’OpenApi file ha un’ulteriore importanza dato che dovrebbe essere quello utilizzato dai WAF per implementare una prima linea di difesa personalizzata delle API che non si limiti alle generiche vulnerabilità di livello 7. Anche qui, una moderna soluzione di API Security, dovrebbe essere in grado di operare su due livelli, generare automaticamente l’OpenAPI file qualora questo non sia stato prodotto dai developer ( e da qui far partire  il ciclo virtuoso )  e controllare gli scostamenti fra l’effettivo comportamento della API e quello riportato nella documentazione prodotta dai developer. Vediamo nella figura sotto un esempio di check prodotto da Noname Security, la prima soluzione pensata espressamente per la API Security.

Concludendo, i CISO si trovano di fronte ad una nuova sfida con tempi molto stretti ed il disegno dei processi di gestione della API Security deve essere una delle priorità per questo 2022.

Se volete ricevere maggiori informazioni su come mettere in sicurezza i Vostri API End Point, potete mandare una richiesta all’indirizzo sales@aditinet.it.