Che cos'è la sicurezza API?

La sicurezza delle API è la pratica di proteggere l'interfaccia di programmazione delle applicazioni (API) da attacchi che utilizzerebbero o tenterebbero di sfruttare in modo malevolo un'API per rubare dati sensibili o interrompere i servizi. La sicurezza API impiega strategie, tecniche e soluzioni per garantire che solo gli utenti autorizzati possano accedere e utilizzare un'API e che i dati trasmessi attraverso l'API siano protetti da accessi o manipolazioni non autorizzati.

La sicurezza API spiegata

Poiché le API fungono da struttura di backend per sistemi e servizi, è fondamentale proteggere le API per proteggere i dati sensibili che trasferiscono, comprese le informazioni di accesso, come l'autenticazione, l'autorizzazione, la convalida degli input e la crittografia. La sicurezza delle API si riferisce ai metodi e agli strumenti progettati per proteggere questi framework backend e mitigare gli attacchi da violazioni di accesso, attacchi bot e abusi.

Tipi comuni di attacchi API

• Attacco denial-of-service (DoS)
• Attacco denial-of-service (DDoS) distribuito
• Attacco Man-in-the-middle (MITM)
• Attacco al controllo degli accessi interrotto
• Iniezione

Un attacco API riuscito può provocare perdite massicce di dati, furto di informazioni private o personali e interruzione del servizio.

Definizione di un'API

API è l'acronimo di Application Programming Interface (interfaccia di programmazione dell'applicazione), che consiste in un insieme di definizioni e protocolli che consentono ai componenti software di comunicare. Servendo da intermediario tra i sistemi software, l'API consente alle applicazioni o ai servizi software di condividere dati e funzionalità. Ma l'API non si limita a fornire l'infrastruttura di connettività. Inoltre, regola il modo in cui le applicazioni software possono comunicare e interagire. L'API controlla i tipi di richieste scambiate tra i programmi, il modo in cui vengono effettuate le richieste e quali formati di dati sono consentiti.

Le API consentono alle organizzazioni di condividere i dati con i clienti e altri utenti esterni. I tipi di API includono quelli utilizzati per l'elaborazione dei pagamenti, le videoconferenze, i social media, gli sms, il monitoraggio medico o del fitness e le case intelligenti. Le API possono essere aperte o chiuse, pubbliche o private, e in genere sono conformi agli standard architettonici, come REST, SOAP o GraphQL.

Le API avvantaggiano anche gli sviluppatori, dando loro accesso alle funzionalità di altre applicazioni, alleviando la necessità di costruire ripetutamente una nuova infrastruttura di connettività o di comprenderne il codice o l'architettura sottostante.

Figura 1: Struttura moderna dell'applicazione

Perché la sicurezza delle API è importante

Le app sono onnipresenti, parte integrante del business e della società. E dietro quasi ogni app c'è un'API, elevando la sicurezza dell'API a missione critica.

Le API fungono da struttura di backend per la maggior parte delle applicazioni native del cloud, comprese le app mobili, le applicazioni web e SaaS, nonché le applicazioni interne, rivolte ai partner e ai clienti. Per mettere l'uso delle API in prospettiva, Postman, la piattaforma di gestione delle API, ha visto 1,13 miliardi di chiamate API nel 2022. Con l'ascesa delle API, ovviamente, si crea una superficie di attacco potenzialmente redditizia che attira i cattivi attori.

Poiché le API espongono la logica dell'applicazione, le risorse e i dati sensibili - comprese le informazioni di identificazione personale (PII) - sono diventate un obiettivo per gli aggressori. Se gli aggressori riescono ad accedere ad API non protette, possono interrompere l'attività, accedere o distruggere dati sensibili e rubare beni.

Figura 2: Applicazione moderna a microservizi che sfrutta le API

Approccio tradizionale alla sicurezza delle applicazioni web

La sicurezza delle applicazioni web nell'era delle applicazioni monolite consisteva nel distribuire un web application firewall (WAF) nel perimetro per intercettare e ispezionare il traffico HTTP inviato dai client web. I WAF hanno fornito, e continuano a fornire, un'efficace sicurezza dell'applicazione quando il rischio potenziale per l'applicazione riguarda principalmente l'input malevolo dell'utente incorporato nell'invio di moduli web HTTP standard o nelle richieste del browser.

Ma la natura delle applicazioni web è cambiata, passando da applicazioni monolitiche ospitate da server web individuali ad applicazioni containerizzate e native del cloud, distribuite in un cluster di server host.

Gli sviluppatori e i team addetti alla sicurezza di oggi, che hanno a che fare con un'architettura di microservizi altamente distribuita e nativa del cloud, devono confrontarsi con reti senza perimetro. Le app moderne consumano input da un'ampia gamma di fonti: richieste web standard, chiamate API di dispositivi mobili, eventi cloud, comunicazione telemetrica di dispositivi IoT, archiviazione cloud, ecc.

Le richieste HTTP in entrata dei clienti (cioè il traffico nord-sud) sono spesso le prime di una sequenza di flussi di comunicazione. In molti casi, una singola richiesta in entrata genera decine di chiamate API interne (cioè, traffico est-ovest). Se queste chiamate API interne non vengono ispezionate e convalidate correttamente, gli endpoint API rimangono senza protezione.

Ispezionare l'input al perimetro non è sufficiente per catturare i payload pericolosi. Gli endpoint API interni possono essere configurati in modo errato e consentire l'accesso non autorizzato a singoli microservizi, esponendo la logica dell'applicazione ad azioni dannose. È fondamentale che tutti gli endpoint API, esterni e interni, siano continuamente monitorati e protetti.

Video: Panoramica della sicurezza API e suggerimenti per migliorare la sicurezza API

Anatomia di un attacco API

Poiché le organizzazioni si affidano alle API per guidare il business, gli aggressori sono a caccia di falle API da sfruttare. Questo esempio di attacco API mirato a un'applicazione di e-commerce con un'applicazione mobile come frontend illustra quanto sia facile per gli attori di minacce trovare varchi per accedere a dati preziosi.

Figura 3: L'anatomia di un attacco basato su API

Fase 1: Con il reverse engineering dell'applicazione mobile, un aggressore scopre un URL endpoint API deprecato utilizzato per recuperare i dati da un microservizio backend.

Fase 2: L'attaccante nota che non sono richieste né l'autenticazione né l'autorizzazione per inviare chiamate API a questo endpoint.

Fase 3: L'attaccante sfrutta la vulnerabilità SQLi. L'URL dell'endpoint API fornisce un identificatore di prodotto univoco sotto forma di valore numerico, e l'aggressore esegue una serie di controlli automatici per scoprire che il campo di input può essere sfruttato per eseguire un attacco SQLi di successo.

Fase 4: Piuttosto che abusare di questo SQLi per la manomissione dei dati, l'attaccante sceglie di abusare della vulnerabilità SQLi ed esegue un comando shell nel microservizio che esegue il database SQL. Il comando shell scarica un eseguibile dannoso e lo esegue. L'eseguibile è un software di mining di bitcoin.

Rischi della sicurezza API

Le configurazioni errate delle API, le falle logiche e le vulnerabilità lasciano le applicazioni e i dati esposti agli aggressori. Sebbene un gateway API possa vedere solo il traffico API instradato attraverso il gateway e non offra visibilità al traffico interno, alcune organizzazioni relegano la loro sicurezza API a un gateway API, credendo che fornisca una protezione API completa.

I team addetti alla sicurezza hanno bisogno di visibilità sulla superficie delle API. Non si può proteggere ciò che non si vede - e ciò che non si vede, alla fine, diventa l'attività non rilevata dei cattivi attori che scoprono un'API ombra.

Sebbene i gateway API monitorino efficacemente le API e il loro utilizzo, non sono in grado di rilevare e bloccare gli attacchi. La sicurezza delle API richiede una protezione in tempo reale contro gli attacchi dannosi, oltre alla visibilità e alla gestione del rischio.

La Top 10 di OWASP

L'Open Web Application Security Project (OWASP) ha pubblicato nel 2019 un elenco dei top 10 rischi per la sicurezza delle API per sensibilizzare sui rischi per la sicurezza delle API che riguardano le moderne applicazioni web. Questo elenco illustra gli attacchi più comuni contro le API web e include suggerimenti per proteggere le sue API da queste minacce.

Autorizzazione a livello di oggetto interrotta

Gli endpoint che gestiscono gli identificatori di oggetti sono spesso esposti dalle API, il che comporta un problema di controllo degli accessi di livello che amplia la superficie di attacco. Se non vengono implementati controlli di autorizzazione adeguati, ad esempio, gli aggressori potrebbero sostituire l'ID di una risorsa che appartiene ad un altro utente durante una chiamata API. Conosciuto come attacco insecure direct object reference (IDOR), questo permette all'attaccante di accedere a una risorsa a cui non è autorizzato ad accedere.

Autenticazione utente non funzionante

I meccanismi di autenticazione API sono bersagli facili perché sono esposti a tutti. Un meccanismo di autenticazione mal implementato, definito come vulnerabilità di autenticazione API non funzionante, dà accesso agli aggressori che possono sfruttare i difetti di implementazione per assumere l'identità degli utenti autorizzati.

Le configurazioni errate dell'autenticazione API possono verificarsi quando vengono aggirate le best practice del settore, come la mancata implementazione della convalida del token di accesso o la memorizzazione di credenziali e chiavi negli URL degli endpoint API.

Esposizione eccessiva di dati

Maggiore è il numero di dati esposti, maggiore è il rischio. Durante l'implementazione dell'API, gli sviluppatori a volte espongono le proprietà degli oggetti senza restrizioni dettagliate e si affidano al client per filtrare i dati non necessari prima che vengano visualizzati nell'interfaccia utente. Ma anche se il client API filtra i dati sensibili, gli aggressori possono comunque sfruttare la chiamata API iniziale e forse ottenere l'accesso a numeri di carte di credito, credenziali di accesso e numeri di previdenza sociale.

Mancanza di risorse e limitazione del tasso

Le API che non limitano il numero di risorse che un cliente può chiamare sono vulnerabili all'abuso delle API attraverso il sovraccarico del traffico. Questo tipo di sovraccarico degrada le prestazioni del server API, bloccando gli utenti legittimi e forse provocando un DoS. Il sovraccarico del server API espone anche l'API a difetti di autenticazione, come la forza bruta.

Autorizzazione a livello di funzione interrotta

Una delle sfide che gli sviluppatori di API devono affrontare è la complessità dell'implementazione delle politiche di controllo degli accessi per diverse gerarchie di gruppi di utenti e ruoli. La distinzione poco chiara tra funzioni di amministrazione e funzioni regolari crea difetti di autorizzazione che gli aggressori possono sfruttare per ottenere l'accesso alle risorse di un utente o per eseguire funzioni amministrative non autorizzate.

Assegnazione di massa

Una vulnerabilità di assegnazione di massa si verifica quando i dati forniti dal cliente vengono vincolati ai modelli di dati senza essere filtrati da una whitelist che impedisca agli utenti di assegnare i dati ai campi protetti. Con questa vulnerabilità, gli aggressori possono ottenere l'accesso a dati sensibili intercettando le query API e modificando le proprietà degli oggetti di backend memorizzati, indovinando le proprietà degli oggetti, leggendo la documentazione e setacciando gli endpoint API per trovare suggerimenti su come compromettere gli attributi dei dati di un'API privata.

Misconfigurazione della sicurezza

Le configurazioni errate della sicurezza possono esporre le informazioni sensibili degli utenti e i dettagli del sistema, con il rischio di compromettere il server. Le cause comuni includono la condivisione di risorse cross-origine (CORS) permissiva, configurazioni incomplete o ad hoc, intestazioni HTTP o metodi HTTP errati, configurazioni predefinite insicure, configurazioni incomplete o errate e messaggi di errore verbosi che espongono informazioni sensibili.

Iniezione

Le API sono soggette a vulnerabilità di iniezione - SQL injection, NoSQL injection e command injection - che possono verificarsi quando dati non attendibili vengono inviati a un interprete come parte di un comando o di una query. Un aggressore può ingannare un interprete e fargli eseguire comandi pericolosi, esponendo dati non autorizzati alla manipolazione e al furto.

Gestione impropria degli asset

Le API espongono un numero maggiore di endpoint rispetto alle applicazioni web tradizionali, e una solida gestione delle API che tenga traccia di questi endpoint è essenziale per prevenire l'abuso di endpoint API esposti, sensibili o vulnerabili. Gli endpoint API deprecati o gli endpoint di debug, ad esempio, potrebbero essere utilizzati dagli aggressori per compromettere l'applicazione.

Registrazione e monitoraggio insufficienti

Una registrazione e un monitoraggio inadeguati, sebbene non costituiscano una minaccia diretta, ritardano il rilevamento di attività dannose. I malintenzionati lavorano sotto la cappa dell'oscurità, con un ampio margine di tempo per portare avanti gli attacchi e avanzare verso diversi sistemi per alterare, estrarre e distruggere i dati. Il rilevamento della minaccia persistente può richiedere più di 200 giorni, secondo gli studi sulle violazioni. E all'indomani di una violazione dei dati, senza un'adeguata registrazione e monitoraggio, le organizzazioni non dispongono delle informazioni forensi per valutare il danno.

Video: Impara a conoscere OWASP, AppSec e la OWASP Top 10 dei rischi per la sicurezza delle applicazioni.

Sicurezza API per SOAP, REST e GraphQL

SOAP, REST e GraphQL sono tre modelli di architettura API comuni, e ogni stile architettonico API presenta considerazioni di sicurezza distinte.

Sicurezza API SOAP

SOAP (simple object access protocol) è un protocollo per lo scambio di dati strutturati nell'implementazione di servizi web nelle reti informatiche. SOAP utilizza l'XML come formato di messaggio e può essere trasportato su una serie di protocolli di livello inferiore, tra cui HTTP e SMTP. Le API SOAP sono in genere protette utilizzando una combinazione di sicurezza a livello di trasporto (come HTTPS) e di sicurezza a livello di messaggio (come le firme digitali e la crittografia XML).

La sicurezza delle API SOAP comporta estensioni del protocollo per affrontare i problemi di sicurezza. SOAP aderisce alle specifiche Web Services (WS), che garantiscono una sicurezza di livello aziendale per tutti i servizi web, grazie a caratteristiche come WS-ReliableMessaging, che estende il supporto integrato per la gestione degli errori.

Sicurezza dell'API Rest

L'architettura delle API di trasferimento di stato rappresentativo, o API REST, si basa sul trasferimento di dati JSON e sul protocollo di trasferimento HTTP/S, che semplificano lo sviluppo delle API REST rispetto ad altre architetture API. Le API RESTful utilizzano le richieste HTTP per POST (creare), PUT (aggiornare), GET (leggere) e DELETE (cancellare) i dati.

Mancando disposizioni di sicurezza integrate, la sicurezza delle API REST dipende dal design dell'API. I servizi di trasmissione dei dati, distribuzione e interazione con il cliente devono incorporare considerazioni sulla sicurezza. La maggior parte delle API RESTful si affida alla sicurezza del livello di trasporto (come HTTPS) e all'autenticazione basata su token.

Una scelta architettonica comune per affrontare la sicurezza delle API Rest è quella di distribuire le API Rest dietro un gateway API e poi fornire questa opzione di connettività ai clienti. Un gateway API, tuttavia, non è attrezzato per difendersi dalla gamma di minacce alla sicurezza.

REST vs. SOAP

Le API SOAP e RESTful supportano le richieste e le risposte HTTP, nonché il livello di sicurezza dei socket (SSL), ma la comunanza finisce qui. Le API SOAP, con le funzioni di sicurezza integrate, sono intrinsecamente sicure. Le API Restful, invece, devono essere rese sicure attraverso scelte di implementazione e di architettura.

Sicurezza dell'API GraphQL

GraphQL è un linguaggio API open-source che descrive il modo in cui i clienti richiedono informazioni e agisce come runtime per soddisfare le query con i dati esistenti. La sintassi GraphQL viene utilizzata dagli sviluppatori per effettuare richieste specifiche di dati da fonti singole o multiple. Con GraphQL, i clienti possono definire la struttura dei dati per una richiesta, e il server si assicurerà che venga restituita la struttura esatta.

L'applicazione della sicurezza dell'API GraphQL pone delle sfide legate alle richieste personalizzabili e flessibili. Il server potrebbe non essere in grado di gestire query complesse e potrebbe inavvertitamente eseguire query dannose nel processo.

I metodi per mitigare i rischi di sicurezza dell'API GraphQL includono il throttling e l'impostazione di una profondità massima della query, nonché un timeout della query per difendersi dalle query di grandi dimensioni.

Le migliori pratiche di sicurezza API

Con le API sempre più rese pubbliche, è importante affrontare i rischi di esposizione dei dati implementando le best practice per ridurre al minimo la superficie di attacco, rimediare alle vulnerabilità e arrestare le attività dannose in tempo quasi reale.

Utilizzi metodi di autenticazione e autorizzazione sicuri.

Si assicuri che solo gli utenti autorizzati possano accedere all'API con metodi di autenticazione sicuri, come OAuth2 o i token web JSON (JWT).

Implementazione della limitazione della tariffa

Implementazione della limitazione della velocità sulle sue API per prevenire attacchi di forza bruta e altri comportamenti dannosi. La limitazione della velocità limita il numero di richieste che possono essere effettuate a un'API entro un determinato periodo.

Utilizzare HTTPS

Le richieste e le risposte API devono essere effettuate tramite HTTPS, per garantire la crittografia e la sicurezza. Questo è particolarmente critico quando si tratta di dati sensibili.

Eseguire valutazioni regolari della sicurezza

Valutare regolarmente la sicurezza delle sue API per identificare le potenziali vulnerabilità. Esaminare le modifiche all'inventario API per rilevare le nuove API esposte e i loro profili di rischio, tra cui l'esposizione ai dati sensibili, l'esposizione a Internet, le vulnerabilità del carico di lavoro e il livello di autenticazione.

Utilizzi una chiave API

Una chiave API è un identificatore unico utilizzato per identificare l'applicazione che chiama un'API e verificare l'autorizzazione di accesso. Le chiavi API differiscono dai token di autenticazione in quanto identificano l'applicazione (o il sito web) che effettua la chiamata API, piuttosto che la persona che utilizza l'applicazione (o il sito web). Entrambe sono misure di sicurezza importanti.

Segua le migliori pratiche di conservazione delle chiavi API per evitare chiamate indesiderate, accessi non autorizzati e potenziali violazioni di dati con perdita di informazioni personali.

Monitorare le sue API

Gestire e monitorare le specifiche API, la documentazione, i casi di test, il traffico e le metriche. Blocca le attività indesiderate, come il traffico API dannoso e i bot cattivi, per aiutare a proteggere l'applicazione e ridurre i costi inutili.

Istruire i team sulle migliori pratiche di sicurezza.

Inserisca la sicurezza nelle fasi iniziali della Pipeline CI/CD e fornisca formazione per migliorare la conoscenza dei suoi sviluppatori sui rischi di sicurezza, come l'autenticazione debole e le vulnerabilità logiche. Implementazione dei principi DevSecOps , compresa la collaborazione tra i team addetti alla sicurezza e allo sviluppo.

Conoscere le sue vulnerabilità

Identifichi i punti deboli del suo ciclo di vita delle API cercando regolarmente i rischi della Top 10 di OWASP API Security. Utilizza strumenti e tecniche di scansione API per identificare ogni vulnerabilità API e risolverla immediatamente per evitare lo sfruttamento.

Richiede un token di sicurezza per l'autenticazione.

Richiedere un token di sicurezza per l'autenticazione è una prima linea di difesa. I token di sicurezza proteggono le API da accessi non autorizzati, rifiutando la chiamata API se il token di un utente non viene verificato.

Le best practice, in breve, dovrebbero iniziare con la visibilità e il monitoraggio delle superfici di attacco, che possono scoprire automaticamente tutte le applicazioni web e gli endpoint API all'interno del suo ambiente. I livelli di difesa devono includere politiche per il traffico nord-sud ed est-ovest, per bloccare le minacce dannose, sia che provengano da Internet che dalle sue applicazioni.

L'aggiunta di un altro livello di scansione delle vulnerabilità e della conformità, insieme all'autenticazione forte, proteggerà ulteriormente le sue applicazioni. Dovrà anche proteggere i suoi carichi di lavoro o il livello dell'infrastruttura, come gli host, le macchine virtuali, i container e le funzioni serverless che aiutano ad ospitare le sue applicazioni.

La soluzione per la sicurezza API di Prisma Cloud.

Prisma Cloud offre una scoperta completa delle API, una profilazione dei rischi e una protezione in tempo reale per tutte le API come parte della sua piattaforma completa di protezione delle applicazioni cloud-native del (CNAPP).

Capacità di sicurezza API

• Scoperta dell'API: Scopre automaticamente tutte le API nel suo ambiente ed elimina i punti ciechi causati da API ombra o non ufficiali.
• Profilatura del rischio dell'API: Identificare i rischi e i fattori di rischio dell'API (come la configurazione errata, l'esposizione a dati sensibili e il controllo degli accessi) e dare priorità alla correzione.
• Protezione in tempo reale: Applicare le protezioni in tempo reale per gli attacchi della OWASP Top 10 per le API, il rate limiting e i bad bot.

FAQ sulla sicurezza API