Perché la sicurezza delle API è affare di tutti

Aug 20, 2023

Il pianeta è inondato di API, i meccanismi utilizzati dai computer per scambiare informazioni, gli elementi costitutivi di tutti i software. Le aziende creano le proprie API per uso interno o per consentire ai clienti di interagire con i propri sistemi. Utilizzano le API per comunicare con i partner nelle extranet e nei cloud. Utilizzano API di terze parti per accedere a funzionalità già pronte, ad esempio per visualizzare Google Maps o utilizzare tabelle di ricerca del codice postale nei moduli.

Il numero di API sta crescendo in modo esponenziale man mano che proliferano le applicazioni mobili, web e cloud. Alcune statistiche di settore:

Non sorprende che anche le API siano un vettore di attacco significativo e in rapida crescita. Secondo Gartner: “La crescita esplosiva delle API sta espandendo la superficie di attacco delle organizzazioni, offrendo agli autori malintenzionati nuove opportunità di violazione ed esfiltrazione di dati”.

A seconda del punto di vista, è molto sorprendente o molto poco sorprendente che circa il 50% delle API utilizzate non siano gestite.

Sorprendenti perché rappresentano un rischio evidente e crescente. Non sorprende perché l’esplosione dell’uso delle API è aggravata dalla mancanza di consapevolezza dei rischi e perché le API sono difficili da gestire. Gli sviluppatori pubblicano spesso nuove API o nuove versioni senza preoccuparsi di eliminare i predecessori. Il cyberspazio è disseminato di API zombie, che espongono sistemi e dati back-end ma non vengono monitorati e non forniscono alcun valore aziendale.

Una superficie d'attacco in continua espansione e scarsamente pattugliata: questo è il sogno di ogni hacker che diventa realtà.

L'avvertimento di Gartner evidenzia uno degli ovvi rischi della sicurezza delle API: le API sono punti di passaggio per molto traffico sensibile. Nelle app bancarie o di e-commerce, questi potrebbero includere i dettagli del conto dei clienti o i numeri di carta di credito. Ma le API espongono non solo i dati di un'azienda (e dei suoi clienti), ma anche la logica aziendale alla base dei servizi. Le debolezze nella logica aziendale offrono agli hacker nuovi modi per lanciare attacchi che probabilmente non verranno rilevati prima che si verifichino gravi perdite.

Ad esempio, abbiamo svolto del lavoro per una banca che utilizzava una routine per arrotondare somme molto piccole nelle transazioni di cambio valuta. L'algoritmo era irrilevante per le operazioni tipiche poiché significava una differenza di una frazione di centesimo. Ma il sistema non applicava limiti al numero di transazioni che un singolo cliente poteva eseguire in un giorno e, aggirando i controlli front-end e attaccando direttamente la logica aziendale, era possibile eseguire un gran numero di piccole transazioni che avrebbero consentito a un utente malintenzionato utilizzare la funzione di arrotondamento per stampare denaro sul nostro conto. Abbiamo ottenuto risultati simili con i clienti del settore delle criptovalute, dove l'abuso della logica aziendale delle API ci ha permesso di rubare anche criptovalute.

Naturalmente, la banca disponeva di controlli che alla fine l’avrebbero allertata del problema, ma ha riconosciuto che avrebbe potuto effettuare operazioni anomale per diversi milioni di dollari prima che venissero sollevati eventuali segnali d’allarme. Questo esempio illustra un paio di importanti principi della sicurezza API. Le API più utili sono pubbliche. Sono pensati per essere usati. Non puoi nasconderli o renderli troppo difficili da accedere senza impedire loro di svolgere il loro lavoro.

Tecniche come i penetration test possono aiutare, ma anche i penetration test sono solo esercizi puntuali e i tester valutano solo l'ambito fornito. Le aziende con punti ciechi delle API non sanno come individuare le API e alla maggior parte dei penetration tester non verrà chiesto di testare la logica di business o non dispongono di competenze specifiche dell'API per valutare cosa potrebbe fare un utente malintenzionato API competente con il loro accesso .

La seconda lezione è che non ha senso concentrarsi solo su una parte del ciclo di vita dell'API. I principi dello spostamento a sinistra sono giustamente focalizzati sulla creazione di sicurezza al momento della progettazione e della codifica, ma il ciclo di vita della produzione del codice è altrettanto importante. Le cose cambiano. Il codice originale è stato modificato da un altro sviluppatore. La documentazione è scarsa o inesistente. L'attività è sotto pressione. Gli aggiornamenti potrebbero non essere testati a fondo. E anche se lo sviluppo e i test fossero impeccabili e le revisioni fossero meticolose, potrebbe esserci qualcosa che è mancato nel progetto originale che potrebbe ritorcersi contro di te. Spostati a sinistra, sì, ma smetti di guardare a destra a tuo rischio e pericolo.