La “API-ness” è ormai un dato di fatto, ovvero le organizzazioni di tutto il mondo hanno acquisito finalmente la consapevolezza del potenziale concreto delle API (Application Program Interface), a partire dalla loro capacità di trasformare i modelli di business e generare direttamente nuovi guadagni.
Una presa di coscienza che è cresciuta progressivamente, insieme alla loro adozione: già nel 2015, Harvard Business Review riportava che il 90% delle entrate di Expedia era guidato dalle API e eBay e Salesforce si attestavano su percentuali rispettivamente del 60% e del 50%.
In termini semplici, un’API è un’interfaccia utente progettata per altre app anziché per gli utenti stessi. Spesso viene gestita attraverso un gateway API, ovvero software leggeri in esecuzione su un server applicativo che gestisce quei punti di connessione per altri servizi applicativi o app mobile per il push o il pull dei dati. Questo permette di definire le API in relazione ad altre API e ai client, consentendo alle organizzazioni di utilizzare l’output del servizio originale in diverse modalità, applicazioni o ambienti senza ricominciare da zero; un problema sempre complesso da affrontare per chi desidera sfruttare le infrastrutture esistenti con modifiche minime.
L’influenza e la diffusione delle API hanno continuato a crescere negli ultimi anni. Il portale del forum della community programmableweb.com ne ha elencate 12.000 nel 2015 e, nell’ottobre 2019, il numero si è arrivato a quasi 23.000. Una crescita che non è passata inosservata nemmeno agli hacker e criminali informatici.
Uno dei maggiori problemi della sicurezza delle API è che le autorizzazioni sono eccessivamente ampie, il che significa che eventuali attacchi alle API possono potenzialmente fornire agli hacker piena visibilità sull’infrastruttura applicativa. Le call API sono anche soggette a minacce tradizionali legate alle richieste web, come attacchi che sfruttano tecniche di injection, brute force, parameter tampering e snooping della sessione.
La visibilità rappresenta un altro aspetto critico, e sempre più pervasivo. Tutte le organizzazioni, indipendentemente dal mercato in cui operano, anche i vendor IT, hanno infatti da sempre una scarsa capacità di mantenere informazioni costantemente aggiornate sullo stato delle API.
Il problema del controllo degli accessi
Dal punto di vista della sicurezza, potremmo definire il 2019 come “l’anno del controllo degli accessi mal configurato” e non credo che quando ci troveremo a fare il bilancio del 2020, in una situazione che per mesi ci ha costretto ad operare nell’emergenza, noteremo molte differenze.
Nell’ultima edizione del nostro Report sulla protezione delle applicazioni 2019, gli F5 Labs hanno evidenziato come il successo di tutte le violazioni API avvenute su piattaforme di grandi dimensioni e con un numero significativo di API e mobile apps registrate nel corso del 2018, sia dipeso dalla mal configurazione di solo alcune di esse. E’ stato evidenziato, inoltre, che ogni singola violazione sia stata il risultato di una configurazione errata del controllo degli accessi. In altre parole, i proprietari dei sistemi non si erano resi conto che le proprie API erano completamente aperte! Fortunatamente i principali autori degli attacchi erano in realtà ricercatori di sicurezza in cerca di notorietà, ma senza una reale volontà di sottrarre o sfruttare i dati; questo non significa che le organizzazioni saranno sempre così fortunate.
Da un altro studio altrettanto interessante promosso dalla North Carolina State University lo scorso anno abbiamo appreso che oltre 100.000 repository di codici su GitHub avevano token API e chiavi crittografiche – in poche parole, gli strumenti per il controllo dell’accesso alle API – memorizzati in chiaro e visibili. Si tratta di un trend che incontriamo spesso: sviluppatori che utilizzano workarounds o pratiche non sicure durante lo sviluppo, non riuscendo poi a riportarsi in una condizione sicura quando il codice viene poi portato in produzione. La memorizzazione delle informazioni di autenticazione API in chiaro su GitHub è quindi solo una delle manifestazioni di un approccio scorretto e diffuso.
Le sette regole d’oro per raggiungere l’API-ness
Riusciranno le organizzazioni a stare al passo con la curva della sicurezza delle API a mano a mano che la loro diffusione diventerà sempre più capillare? A mio avviso ci sono delle azioni che dovrebbero necessariamente intraprendere fin da subito per poterlo fare:
In primo luogo è necessario realizzare un inventario, scoprire dove sono le proprie API e come contribuiscono alle operazioni aziendali. Il contesto è fondamentale e conoscerlo attraverso scansioni perimetrali (per avere una visione globale dal punto di vista dell’hacker) e confrontarsi in modo approfondito con i team addetti allo sviluppo e alle operations è essenziale.
Non tralasciate l’autenticazione; il report di F5 sullo stato dei servizi applicativi nel 2019 mostra che il 25% delle organizzazioni intervistate non utilizza l’autenticazione delle API. Il 38% ha dichiarato di averlo fatto solo “alcune volte” e il 37% ha affermato di farlo nella “maggior parte dei casi”. I dati sono preoccupanti. Le credenziali sono le chiavi per accedere al business e quindi devono essere archiviate in modo sicuro.
Gestisci con attenzione le autorizzazioni perché nessuna API deve poter trasmettere input non autorizzati o non validati alle applicazioni. Tralasciare questo punto significa aprire le porte agli attacchi di injection. Le credenziali API devono essere trattate utilizzando il principio del privilegio minimo, ed è necessario controllare gli accessi in base al ruolo.
Configura e verifica i log di tutte le connessioni API, indipendentemente dal risultato della richiesta e dal comportamento. Un’altra buona pratica è monitorare gli asset che queste API servono.
È necessario crittografare in modo sempre crescente tutto il traffico degli utenti sul Web, e le API non fanno eccezione: richiedono una crittografa delle connessioni e convalida dei certificati al pari di qualsiasi altro servizio.
Adotta strumenti di sicurezza pensati per le API, come un proxy “API-aware” o un firewall applicativo per ispezionare, convalidare e limitare le richieste. Alcuni servizi di sicurezza API possono analizzare il client di origine, per provare a determinare se una richiesta è legittima o dannosa, e possono garantire che le richieste API non vengano processate, se dannose.
Esegui costantemente i test per essere aggiornato, perché l’adozione delle API cresce comportando lati oscuri sempre maggiori. Un buon suggerimento è anche quello di adottare programmi di bug bounty delle vulnerabilità per sfruttare in modo proattivo l’intuizione dei ricercatori della security.
In conclusione, anche se le API non sono una novità, il loro ruolo è sempre più rilevante se consideriamo come Internet sta crescendo e come le applicazioni stanno evolvendo. Da molti punti di vista, le API reintroducono nei nostri ambienti minacce già esistenti per la security ma in forme che hanno maggiori probabilità di essere sfruttate, con conseguenze più estese e una difficoltà maggiore nel riconoscerle. Lo ha dimostrato il famoso caso di Cambridge Analytica, dove alcune lacune di sicurezza delle API dei social media hanno permesso di sottrarre milioni di dati sugli utenti. Allo stesso tempo, però, le API sono una componente indispensabile dell’architettura moderna, ed evitarle o ignorare eventuali problemi di sicurezza ad esse correlati non è più possibile e non ci porterà di certo alla felicità.
Di Ray Pompon, Principal Threat Research Evangelist di F5
