Non c’è dubbio che l’utilizzo delle API (Application Programming Interface) sia esploso, ma come per ogni tecnologia adottata in modo massivo, a stretto giro seguono la scia i criminal hacker con le loro tecniche cosiddette di API hack.
Questi hanno iniziato a sfruttarne le vulnerabilità dal punto di vista della cyber security per rubare dati e portare a termine i loro attacchi.
Le API rendono tutto un po’ più semplice, dalla condivisione dei dati alla delivery di caratteristiche e funzionalità critiche, ma rendono anche molto più facile la vita per gli aggressori. Vediamo in che modo e come è possibile porvi rimedio.
Indice degli argomenti
API hack: librerie software troppo facili da trovare
Uno dei modi più semplici per trovare le API, sia che si tratti di una Web App o di un’applicazione mobile, è monitorare il traffico di comunicazione con un intercept proxy.
Questo cattura tutte le richieste che il browser o l’applicazione mobile fanno ai server di backend, permettendo di catalogare tutti gli endpoint API disponibili.
Per esempio, la maggior parte delle API hanno /API/V1/login come endpoint di autenticazione. Ma potremmo anche sfruttare il più grande motore di ricerca Google per identificarle. È sufficiente una semplice ricerca: site:api.*.com.
Se il target è anche un’applicazione mobile, “smontando” il pacchetto dell’applicazione, troviamo tutte le possibili attività in vista. Da lì è facile cercare configurazioni errate o le API che non proteggono correttamente i dati degli utenti.
Da ultimo, è possibile semplicemente cercare la documentazione delle API.
Questo perché alcune organizzazioni pubblicano documenti API per terze parti, ma utilizzano gli stessi endpoint API per tutti gli utenti.
Con un inventario decente degli endpoint, è possibile testare sia il comportamento standard dell’utente che quello anormale.
API hack: il problema dei troppi parametri
Mentre gli aggressori “navigano” attraverso le API per portare a termine un attacco, devono capire cosa possono inviare per estrapolare i dati.
Gli aggressori contano sul fatto che i sistemi complessi hanno più probabilità di contenere falle. Una volta che un aggressore identifica un’API, cataloga i parametri e poi tenta di accedere ai dati di un amministratore (escalation verticale dei privilegi) o di un altro utente (escalation orizzontale dei privilegi) per raccogliere ulteriori dati.
Spesso, troppi parametri non necessari vengono esposti agli utenti.
In un recente progetto di ricerca, una chiamata API ad un servizio target ha inviato una massiccia quantità di dati.
Molti elementi di dati non erano necessari, come la chiave del processore per un gateway di pagamento e gli sconti disponibili, dati che ovviamente non dovrebbero apparire.
Questi elementi bonus forniscono una migliore comprensione del contesto e della sintassi delle chiamate API. Non c’è bisogno di molta immaginazione per capire cosa fare dopo; questi parametri extra danno all’aggressore un ricco set di dati da colpire.
API hack: il problema dei troppi dati
Sulla stessa linea di troppi parametri disponibili, il concetto di raccolta dei dati diventa un ovvio passo successivo.
Molte organizzazioni mettono a disposizione i loro sistemi per connessioni anonime e tendono a far trapelare dati di cui l’utente medio non ha bisogno.
Inoltre, molte organizzazioni tendono a memorizzare dati a cui si può accedere direttamente.
Un’altra sfida comune per quanto riguarda i dati è che le organizzazioni tendono a immagazzinare molti più dati del necessario. Parliamo di dati sui clienti che non sono più tali o le note di vecchi casi con informazioni sensibili; tutte informazioni che non possono fornire più valore commerciale all’organizzazione, ma potrebbero essere molto imbarazzanti e – soprattutto – dannose se violati.
Poca attenzione agli aspetti di sicurezza
La parte di Application design si concentra quasi esclusivamente sulla la funzionalità e l’usabilità ma, troppo raramente, la sicurezza dell’applicazione.
Troppo spesso la sicurezza delle API viene lasciata completamente fuori dal processo di progettazione. È un aspetto troppo fondamentale per non essere parte del progetto sin dall’inizio.
Come rimediare
Alla luce di quanto visto, è possibile individuare quattro macro aree “problematiche”, ma con approcci diversi non difficili da “sbrogliare”.
Per quanto riguarda la facilità con cui al momento è possibile “trovare” le API dobbiamo assicurarci che la nostra documentazione API sia gated e controllata con accessi che consentono l’accesso solo agli utenti validi.
Anche le richieste API al server dovrebbero essere il più possibile offuscate e controllate.
Per i parametri, se si limita ciò che l’utente può vedere solo a ciò che è necessario, si limita automaticamente la trasmissione di dati critici e si mantiene sconosciuta la struttura della query di dati. Questo step rende molto più difficile per un aggressore imporre richieste di forza bruta a parametri di cui conosce l’esistenza.
Terzo problema, i dati. In questo caso una revisione approfondita è un must per qualsiasi organizzazione che memorizza qualsiasi informazione, non solo i dati personali.
Dopo aver esaminato i dati memorizzati, i requisiti di accesso ai dati devono essere messi in atto e testati. Assicuratevi che i dati a cui si accede in modo anonimo tramite l’app siano dati che dovrebbero essere accessibili a tutti.
Da ultimo il paradigma della security by design. Se non avete esaminato l’architettura di sicurezza della vostra applicazione, è un primo passo significativo verso un sistema sicuro. Ricordate, le API rendono gli aggressori più efficienti non solo la vostra app.
È importante verificare sempre il livello di sicurezza delle proprie applicazioni. Non abbassiamo la guardia.
