L’utilizzo delle Api (Application programming interface) per semplificare l’accesso alle applicazioni aziendali in ambienti mobile e cloud facilita l’espansione degli ecosistemi digitali, aprendo l’azienda al mondo esterno. L’utilizzo di questi “connettori” consente infatti di esporre dati e funzionalità delle applicazioni a utenti esterni attraverso app mobili, cloud o oggetti (IoT); si tratta in pratica di finestre aperte sulle applicazioni che se da un lato abilitano nuovi modelli di business, dall’altro espongono le aziende a non pochi rischi se questa attività non viene adeguatamente gestita.
Se ben progettata, un’Api deve essere trasparente sulla struttura interna di un’applicazione, rendere molto chiaro a cosa servono i singoli comandi e quindi consente un accesso molto granulare all’applicazione stessa; questo la espone a una serie di vulnerabilità che aumenta la possibilità di attacchi, mettendo a rischio i sistemi aziendali (il problema non è “semplicemente” che un’app mobile non funzioni correttamente, il rischio è che l’Api si trasformi in un cavallo di Troia, “agganciandosi” all’applicazione, che consente al malware di entrare in azienda, compromettendo le applicazioni legacy – figura 1). Una corretta gestione delle Api è dunque uno dei pilastri della definizione di una qualsiasi strategia di mobile security. Forrester ha dedicato alcuni studi (The Forrester Wave: Api Management Solutions, The Api Management Buyer’s Guide e Applying The Forrester Wave: Api Management Solutions) a questa tematica, analizzando gli 11 principali fornitori di soluzioni per la gestione delle Api (figura 2). Ma quali sono le tipologie di attacco che sfruttano le vulnerabilità cui abbiamo accennato? Sostanzialmente gli attacchi possono essere raggruppati in tre macro categorie:
Quelli che sfruttano i dati inviati alle Api, come url, parametri di query, contenuti pubblicati. Essendo autodescrittive, le Api sono particolarmente vulnerabili da questo punto di vista perché forniscono indicazioni preziose su come viene utilizzato un determinato parametro dall’applicazione stessa.
- Quelli incentrati sulle identità che sfruttano le vulnerabilità dei sistemi di autenticazione, autorizzazione e registrazione delle sessioni. Molte Api richiedono al client l’utilizzo di una “chiave” Api per accedere alle loro funzionalità, ma questa “chiave” identifica l’applicazione (la chiave è comune per ogni copia dell’app) e non una specifica istanza o un determinato utente. Anche la gestione delle sessioni è un altro ambito lacunoso e foriero di rischi: nel web “normale” (ossia quello dove le applicazioni vengono fruite tramite browser) la sessione di lavoro viene mantenuta aperta tramite cookie, nelle Api la gestione delle sessioni è molto più complessa e, anche in questo caso, un approccio non corretto lascia aperture rischiose; una via d’uscita è rappresentata da OAuth (protocollo di autorizzazione open standard che consente l’accesso da parte di terzi ai dati degli utenti senza doverne conoscere la password), ma è un approccio complesso da adottare.
- Quelli che intercettano le transazioni legittime e sfruttano dati non crittografati. Se l’Api non utilizza correttamente il protocollo Ssl/Tls , tutte le richieste e le risposte tra un client e il server delle Api possono venire potenzialmente compromesse.
Come mitigare i rischi
Esistono delle strategie che possono supportare l’azienda nel mitigare i rischi derivanti dalla pubblicazione delle Api? Una interessante guida realizzata da Ca Technologies, Proteggere le Api da attacchi e hijacking. Rendere sicure le applicazioni per il mobile, il cloud e l’open web, ne identifica cinque.
Convalida dei parametri – La singola misura di protezione più efficace contro gli attacchi che sfruttano i dati inviati alle Api è la convalida di tutti i dati in entrata rispetto a una whitelist di valori previsti. L’approccio più pratico consiste nell’applicare la convalida dello schema a tutti i dati in ingresso, rispetto a un modello di dati altamente restrittivo. Gli schemi devono essere definiti con la massima rigidità.
Applicazione del rilevamento delle minacce – In genere si tratta di definire blacklist dei contenuti a rischio, come istruzioni Sql o tag script; la sfida sta nell’applicare efficacemente i criteri di blacklisting perché il rischio di “falsi positivi” è elevato.
Attivazione generalizzata dell’Ssl/Tls – Per le Api il protocollo Ssl/Tls dovrebbe diventare la regola in quanto fornisce riservatezza e integrità su tutti i dati scambiati tra un client e un server. Non solo deve essere attivato in ogni Api, ma deve essere configurato correttamente: non è infatti raro che molti sviluppatori non convalidino correttamente i certificati e le relazioni di trust rendendolo così inefficace.
Separazione delle identità – L’identità dell’utente e dell’app sono elementi separati. Gli sviluppatori lato server devono quindi separare nettamente le identità degli utenti e le identità delle Api e prendere in considerazione anche l’autorizzazione basata su un contesto di identità ampio (utente, applicazione, device, posizione, orario ecc.).
Utilizzo di soluzioni collaudate – Non ha senso creare un proprio framework di sicurezza per le Api, esistono ottime soluzioni commerciali per garantire la sicurezza delle Api, la vera sfida è applicarle.
