
Introduzione
Nel mondo interconnesso di oggi, le API (Interfacce di Programmazione delle Applicazioni) sono diventate la spina dorsale della comunicazione digitale, consentendo a diversi sistemi software di interagire tra loro. Dalle applicazioni mobili ai servizi cloud, le API facilitano lo scambio di dati e servizi in modo fluido. Tuttavia, man mano che le API acquisiscono sempre più importanza, aumentano anche i rischi ad esse associati. La crescente diffusione delle violazioni della sicurezza legate alle API evidenzia la necessità di misure di sicurezza robuste.
Che cose è un API?
Le API consentono a diversi componenti software di comunicare tra loro, fungendo da ponte tra i vari sistemi. Permettono la creazione di applicazioni complesse fornendo un insieme di protocolli e strumenti per la costruzione di software e applicazioni. Le API sono essenziali per il funzionamento dei servizi web, delle app mobili, dei dispositivi IoT e molto altro. Tuttavia, il loro uso diffuso le rende anche obiettivi privilegiati per gli attaccanti.
Le principali vulnerabilità delle API
Le vulnerabilità delle API sono varie e possono portare a gravi violazioni se non affrontate correttamente. Secondo la OWASP API Security Top 10, le vulnerabilità più comuni delle API includono:
Autorizzazione a livello di oggetto compromessa (BOLA)
Si verifica quando un'API non applica correttamente i controlli di accesso, permettendo agli attaccanti di accedere o modificare dati a cui non dovrebbero avere accesso.
Autenticazione compromessa
Accade quando i meccanismi di autenticazione sono deboli, portando a accessi non autorizzati.
Esposizione eccessiva dei dati
Le API spesso espongono più dati del necessario, rendendo informazioni sensibili accessibili a chi non dovrebbe poterle visualizzare.
Configurazioni di sicurezza errate
Configurazioni predefinite, incomplete o improprie che espongono l'API ad attacchi.
Attacchi di iniezione
Dati malevoli vengono inviati a un'API, portando a iniezioni SQL, iniezioni di comandi o altre forme di sfruttamento.
Server-Side Request Forgery (SSRF)
Si verifica quando un attaccante riesce a manipolare l'API e a fare in modo che il server che ospita l'API invii richieste verso destinazioni non previste.
Analisi approfondita: le vulnerabilità BOLA e BFLA
Autorizzazione a livello di oggetto compromessa (BOLA)
BOLA è una delle vulnerabilità più critiche nel campo della sicurezza delle API. Si verifica quando un'API non verifica correttamente i permessi dell'utente, consentendo agli attaccanti di accedere o manipolare dati a cui non dovrebbero avere accesso. Ad esempio, se un utente può accedere ai dati di un altro utente semplicemente modificando un ID nella richiesta API, ciò indica una vulnerabilità BOLA.
Autorizzazione a livello di funzione compromessa (BFLA)
BFLA si verifica quando un'API assegna in modo errato i permessi agli utenti per accedere a determinate funzioni. A differenza di BOLA, che riguarda l'accesso a livello di oggetto, BFLA riguarda funzioni di livello superiore. Questa vulnerabilità consente agli utenti non autorizzati di eseguire operazioni riservate, potenzialmente causando danni significativi.
Riferimenti e Definizioni delle API
Quando si sviluppano e si proteggono le API, comprendere gli strumenti e gli standard utilizzati per definirle, documentarle e interagirci è fondamentale. Tuttavia, lasciare la documentazione di un'API esposta è rischioso, come vedremo nel nostro caso di studio.
Ecco alcune delle specifiche e degli strumenti conosciuti che possono essere utilizzati per generare automaticamente una documentazione API:
Swagger
Swagger è un framework per progettare, costruire e documentare API RESTful. Permette agli sviluppatori di definire le loro API utilizzando un formato standardizzato, semplificando la generazione di documentazione interattiva per le API e librerie client. L'interfaccia intuitiva di Swagger facilita i test e l'interazione con le API.
OpenAPI
La OpenAPI Specification (OAS) è uno standard per definire le API RESTful. Fornisce un modo strutturato per descrivere la tua API, inclusi gli endpoint, i formati di richiesta/risposta e i metodi di autenticazione. OpenAPI si basa su Swagger ed è diventato lo standard del settore per la documentazione delle API, garantendo coerenza e chiarezza tra le diverse API.
WSDL (Web Services Description Language)
WSDL è un linguaggio basato su XML utilizzato per descrivere i servizi web, in particolare i servizi basati su SOAP. Definisce le operazioni che il servizio offre, i messaggi che accetta e restituisce, e i dettagli di binding necessari per la comunicazione. Sebbene sia più comunemente associato ai vecchi servizi SOAP, WSDL rimane pertinente in determinati ambienti aziendali.
ASP.NET Web API Help Page
La ASP.NET Web API Help Page è una funzionalità integrata in ASP.NET che genera automaticamente la documentazione di aiuto per la tua API. Fornisce informazioni dettagliate sugli endpoint della tua API, comprese le descrizioni dei parametri e le risposte di esempio, rendendo più facile per gli sviluppatori comprendere e utilizzare l'API.
GraphQL Introspection
L'Introspezione di GraphQL è una funzionalità potente che consente ai client di interrogare una API GraphQL per ottenere il suo schema. Ciò significa che gli sviluppatori possono recuperare informazioni dettagliate sui tipi, i campi e le operazioni disponibili direttamente dall'API, abilitando query dinamiche e una comprensione più approfondita delle capacità dell’API.
La documentazione API esposta è rischiosa
Mentre la documentazione API è fondamentale per gli sviluppatori, lasciarla pubblicamente accessibile senza i dovuti controlli può esporre il sistema a rischi significativi, che vanno dalla divulgazione di informazioni all'accesso non autorizzato, attacchi di tipo injection e altro ancora.
Studio di caso: Vulnerabilità rilevate automaticamente da ULTRA RED
CVE-2023-39375: Questa vulnerabilità è legata al BOLA (Broken Object Level Authorization), dove controlli di autorizzazione insufficienti consentivano a un attaccante non autenticato di creare un nuovo utente admin.
CVE-2023-39376: Una vulnerabilità BOLA che permetteva a un attaccante non autenticato di disabilitare le misure di sicurezza applicate dall’applicazione.
CVE-2024-41702: Una vulnerabilità di SQL Injection in un endpoint di login API, dove l'iniezione di oggetti JSON portava a passare valori non sanificati a una query SQL.
Esposizione di Informazioni Personali Identificabili (PII): Una vulnerabilità BFLA (Broken Function Level Authorization) che permetteva a un attaccante di accedere alle risorse di altri utenti, in particolare ai dipendenti di una grande azienda, esponendo informazioni sensibili altamente riservate, tra cui Protected Health Information (PHI).
Questi esempi evidenziano come una documentazione API non adeguatamente protetta possa fungere da punto di ingresso per attacchi gravi, esponendo informazioni sensibili e compromettere la sicurezza dell'intero sistema.

Vector Type - Server Side Request Forgery (SSRF)
Sintesi: Il SSRF (Server-Side Request Forgery) potrebbe essere critico, soprattutto quando è riflesso. Nel nostro caso, abbiamo potuto sfruttare il SSRF per recuperare i metadati del cloud e ottenere accesso iniziale all'ambiente cloud del cliente.
Rilevamento: Il sistema è programmato per analizzare automaticamente le Definizioni API che abbiamo menzionato in precedenza e scansionare gli endpoint alla ricerca di vulnerabilità. Purtroppo per il cliente, c'era una richiesta API che ha esposto una vulnerabilità critica.Questa vulnerabilità consentiva a un attaccante di inviare messaggi email ad altri utenti, con l'invio proveniente dal server di posta affidabile del fornitore dell'API!
Abbiamo testato il parametro per il SSRF e ottenuto una callback riuscita.Ma c'è di più: l'attaccante poteva allegare file a ciascun messaggio email fornendo una lista di URL.
Nell'immagine sottostante, vediamo che la richiesta viene inviata all'endpoint /api/Email/SendEmail, che include parametri come Address, Emails, CCs, e BCCs. Per questo esempio, abbiamo popolato questi campi con indirizzi email segnaposto usando un dominio generato da Interactsh.
Abbiamo provato alcuni endpoint comuni e interessanti per SSRF, come l'endpoint dei metadati di AWS, inserendo l'URL dei metadati di AWS http://169.254.169.254/latest/meta-data come allegato a un file.

Ok, quindi la richiesta è stata completata con successo perché abbiamo ricevuto il parametro isSuccess come true.
Ho utilizzato Interactsh per verificare se il file è stato inviato, ma anche una mail temporanea potrebbe essere utilizzata per il test.

Possiamo vedere che abbiamo ottenuto l'interazione SMTP. È stata trovata una SSRF di secondo ordine! In modalità verbosa possiamo vedere il contenuto codificato in base64:

Possiamo ora prendere i dati codificati, decodificarli e vedere che siamo riusciti ad accedere con successo all'endpoint dei metadati dell’istanza:

Proteggere le tue API
Per mitigare queste vulnerabilità, ecco alcune best practice:
Implementare meccanismi di autenticazione e autorizzazione robusti.
Seguire il principio del minimo privilegio per limitare l'accesso.
Validare e sanificare tutti gli input per prevenire attacchi di iniezione.
Utilizzare il rate limiting e il monitoraggio per rilevare attività insolite.
Aggiornare e applicare patch regolarmente alle API per risolvere vulnerabilità conosciute.
Introdurre strumenti di scansione (come ULTRA RED) per rilevare automaticamente vulnerabilità conosciute e sconosciute.
Conclusione
Man mano che le API continuano ad espandersi, la loro sicurezza diventa fondamentale.
Comprendendo le vulnerabilità comuni delle API secondo la lista OWASP Top 10 e implementando misure di sicurezza robuste, le organizzazioni possono proteggere i loro beni digitali e garantire che le loro API rimangano sicure.
Per sapere di più fissi una call con il nostro team Qui
Comments