Come una fintech in serie B ha corretto 23 falle critiche delle API prima del round successivo

Progetto rappresentativo. Dettagli del cliente anonimizzati ed elementi specifici modificati sotto NDA.

Cambia un numero in una URL e leggi le transazioni bancarie di uno sconosciuto. È stata la prima cosa che abbiamo trovato, il secondo giorno, su una API di fintech che muove denaro reale. Il difetto è rimasto irrisolto per tutto l’anno in cui una scansione delle vulnerabilità “pulita” era rimasta nella loro cartella delle evidenze.

Il cliente era una fintech in serie B, una quarantina di ingegneri, a sei settimane dall’apertura di un round di serie C. Il suo investitore principale voleva una revisione di sicurezza da parte di terzi prima di firmare il term sheet. Il loro prodotto era quasi interamente una API: un’app mobile e una dashboard web per i partner che dialogavano con lo stesso insieme di endpoint REST. Hanno quindi chiesto un penetration test delle API, non una scansione di rete né un report da spuntare.

Quella distinzione è tutta la storia. I problemi che abbiamo trovato erano esattamente del tipo che gli strumenti automatici ignorano del tutto. Alla fine avevamo segnalato 23 problemi critici e alti, e la stragrande maggioranza erano falle di autorizzazione. La API si fidava di chi chiamava molto più di quanto avrebbe dovuto.

Punti chiave

• Le falle delle API più dannose nella fintech sono bug di autorizzazione (BOLA/IDOR e autorizzazione a livello di funzione mancante), non injection o errori di configurazione. Gli scanner ne mancano quasi tutti.
• In questo progetto rappresentativo abbiamo segnalato 23 problemi critici e alti in sei settimane, tra cui l’esposizione di dati tra account, un percorso di mass assignment verso un ruolo admin ed endpoint OTP senza rate limiting.
• Il penetration test delle API significa testare con più ruoli utente reali, confrontare a cosa può accedere ciascun token e abusare della logica di business. Non è lanciare un elenco di richieste contro un singolo endpoint.
• Correggere l’autorizzazione a livello di oggetto (questo utente è proprietario di questa risorsa?) ha chiuso la maggior parte dei problemi critici. Il nuovo test ha confermato che le correzioni tenevano.
• L’azienda ha superato la due diligence tecnica senza che alcun rilievo di sicurezza bloccasse il round.

Il contesto: una API che muoveva denaro e si fidava di tutti

Lo stack era familiare. Una API in Node ed Express dietro un gateway, PostgreSQL, token di accesso JWT, un client mobile e una dashboard per i partner. Circa 180 endpoint documentati, più una manciata che non erano affatto nella documentazione. Ce ne sono sempre. Gli utenti potevano detenere saldi, inviare bonifici, invitare colleghi e collegare conti bancari esterni.

La loro stessa lettura del prodotto era che fosse “piuttosto solido”. Avevano un WAF. Eseguivano uno scanner di dipendenze in CI. Un fornitore precedente aveva consegnato loro una scansione delle vulnerabilità dall’aspetto pulito l’anno prima.

Quella scansione è un buon esempio del perché una scansione non è un pentest. Confermava che la loro configurazione TLS e le versioni delle librerie andavano bene. Non diceva nulla sul fatto che l’utente A potesse leggere le transazioni dell’utente B, che si è rivelato essere l’unica cosa che contava.

Il nostro approccio: ruoli, token e a cosa ciascuno può accedere

L’abbiamo impostato come un test gray-box. Ci hanno dato la documentazione della API, una collection Postman e diversi account di test distribuiti su tutti i ruoli: due utenti standard in organizzazioni distinte, un admin di organizzazione, un analista in sola lettura e un account della dashboard partner. Disporre di più account per ruolo è l’input più importante in assoluto per un vero test di autorizzazione. Non si può dimostrare che un utente raggiunge dati che non dovrebbe senza i dati di un secondo utente da provare a raggiungere.

Il setup di lavoro non aveva nulla di glamour. Burp Suite come proxy per il traffico mobile e la dashboard, con la sessione di ogni account salvata in modo da poter rigiocare qualsiasi richiesta con qualsiasi identità. Un paio di estensioni di Burp per confrontare le risposte tra i ruoli. ffuf per la scoperta di endpoint e parametri. Poi molta modifica manuale delle richieste. La maggior parte dei rilievi reali è venuta dalla lettura attenta delle risposte, non dagli strumenti.

Il primo passaggio si limita a mappare la superficie: ogni endpoint, ogni parametro, ogni formato di ID e quale ruolo dovrebbe raggiungerlo. Il secondo passaggio è quello interessante. Prendiamo una richiesta che appartiene legittimamente all’utente A, la rigiochiamo con il token dell’utente B, poi con il token dell’analista, poi senza alcun token, e osserviamo cosa torna indietro.

Come appariva concretamente “testare la API” qui

Prendiamo l’endpoint delle transazioni. Accettava un ID di account numerico nel percorso:

GET /v2/accounts/48213/transactions HTTP/1.1
Host: api.example.com
Authorization: Bearer <user-A-token>

Cambia 48213 in 48214, mantieni il token dell’utente A, e la API restituiva l’intera cronologia delle transazioni di un altro cliente. Questo è il Broken Object Level Authorization, classificato come API1 nell’OWASP API Security Top 10, e lo stesso problema di fondo che si chiama IDOR (CWE-639). Gli ID erano interi sequenziali, quindi scorrere l’intera base clienti era banale. Primo rilievo critico depositato, il secondo giorno.

Non è stato un caso isolato. Lo stesso controllo di proprietà mancante è comparso sugli estratti conto, sull’endpoint che restituiva i dettagli mascherati di un conto bancario collegato e su un download di fattura in PDF che accettava un ID di documento e non faceva alcun controllo. Una sola classe di difetto, diversi endpoint. Il codice autenticava il token, ma non chiedeva mai se il proprietario del token possedesse davvero l’oggetto richiesto.

Cosa abbiamo trovato: i punti salienti

Oltre ai bug a livello di oggetto, vale la pena segnalare alcuni rilievi perché ricorrono di continuo sulle API di fintech.

Mass assignment verso un ruolo admin. L’endpoint per aggiornare il proprio profilo accettava un body JSON e lo legava direttamente al modello utente. Documentava name ed email. Accettava anche silenziosamente role. La richiesta qui sotto promuoveva un utente standard ad admin di organizzazione:

PATCH /v2/users/me HTTP/1.1
Authorization: Bearer <standard-user-token>
Content-Type: application/json

{"name":"Jordan","role":"admin"}

Questo è mass assignment (CWE-915), la falla che l’attuale OWASP API Security Top 10 fa rientrare nel Broken Object Property Level Authorization. In combinazione con la successiva diventa particolarmente pericolosa.

Autorizzazione a livello di funzione mancante. Gli endpoint riservati agli admin che elencavano tutti gli utenti dell’organizzazione e modificavano i permessi dei membri verificavano che fossi autenticato, ma non che fossi un admin. Un utente standard poteva chiamarli direttamente. Abbina questo al bug di mass assignment e un singolo account con privilegi bassi aveva una strada spianata verso il controllo totale di un’organizzazione.

Endpoint OTP e di reset della password senza rate limiting. L’endpoint di verifica del codice usa e getta accettava tentativi illimitati. Un codice a sei cifre senza blocco né throttling non è un secondo fattore. È un dosso. Abbiamo forzato un codice valido con la forza bruta in pochi minuti da un solo IP. Il flusso di reset della password aveva la stessa lacuna.

Un JWT di cui ci si fidava troppo. Il token di accesso portava il ruolo dell’utente e l’ID dell’organizzazione come claim, e almeno un servizio prendeva decisioni sulla base di quei claim senza riverificarli lato server. I token avevano una lunga durata e non c’era revoca lato server, quindi un token trapelato restava utile fin troppo a lungo.

Niente di tutto ciò ha richiesto strumenti esotici. Ha richiesto un secondo account e qualcuno disposto a chiedersi cosa succede se invio questa richiesta spacciandomi per la persona sbagliata.

Il risultato

Abbiamo consegnato i rilievi man mano, invece di scaricare tutto alla fine. È così che conduciamo ogni progetto a tempo determinato. I problemi di BOLA sono andati al loro team il secondo giorno, così gli ingegneri hanno potuto iniziare a correggere mentre continuavamo a testare. Ogni rilievo è stato consegnato con la richiesta esatta per riprodurlo, l’impatto in linguaggio chiaro e una correzione specifica.

Il loro team si è mosso in fretta. Le correzioni erano per lo più strutturali: un middleware di controllo della proprietà che verificava che l’utente autenticato possedesse davvero l’oggetto indicato nel percorso, veri controlli di ruolo su ogni rotta privilegiata, una allow-list dei campi scrivibili invece di legare l’intero body, oltre a rate limiting e blocco sugli endpoint di autenticazione. Durate dei token più brevi e una lista di revoca hanno risolto il problema del JWT.

Abbiamo eseguito un nuovo test completo contro le correzioni. Tutti i 23 rilievi critici e alti erano chiusi e verificati, e il nuovo middleware di proprietà aveva anche intercettato due problemi di gravità inferiore che avevamo segnalato. Quando la due diligence tecnica dell’investitore è avvenuta qualche settimana dopo, nulla di legato alla sicurezza ha bloccato il round. Era tutto qui il punto: trovarlo prima che qualcuno di ostile, o il revisore di un acquirente, lo trovi al posto tuo.

Come aiuta CyberXplore

Questo è il cuore di ciò che fa il nostro servizio di penetration test delle API: test manuale e consapevole dei ruoli degli endpoint che fanno davvero funzionare il tuo business, mappato sull’OWASP API Security Top 10, con passaggi di riproduzione su cui uno sviluppatore può agire e un nuovo test per confermare che le correzioni tengono. Se ti stai avvicinando a un round di finanziamento, a un’integrazione con un partner o a una scadenza di conformità e il tuo prodotto è una API, è esattamente allora che ripaga. Richiedi un preventivo e raccontaci del tuo stack e delle tue tempistiche.

FAQ

Perché uno scanner di vulnerabilità non riesce a trovare queste falle delle API?

Gli scanner sono bravi con i problemi noti: librerie obsolete, TLS debole, header mancanti, alcuni pattern di injection. Le falle di autorizzazione come BOLA dipendono dal contesto di business. Uno scanner non ha idea che l’account 48214 appartenga a un cliente diverso, quindi una risposta 200 gli sembra a posto. Trovarle richiede una persona che confronti a cosa possono accedere diversi utenti reali, ed è questo il cuore del penetration test delle API.

Quanto dura un penetration test delle API?

Dipende dal numero di endpoint, dal numero di ruoli e da quanta logica di business è coinvolta. Un test delle API mirato su una fintech di medie dimensioni dura in genere da una a tre settimane di test attivi più un nuovo test. Il progetto descritto in questo articolo è stato di circa due settimane di test all’interno di una finestra di sei settimane che comprendeva la correzione e il nuovo test.

Che cos’è il BOLA e perché è il principale rischio delle API?

Il BOLA (Broken Object Level Authorization) si verifica quando una API controlla che tu abbia effettuato l’accesso ma non che l’oggetto specifico che hai richiesto ti appartenga. Occupa il primo posto nell’OWASP API Security Top 10 perché è comune, banale da sfruttare cambiando un ID in una richiesta e spesso espone i dati di tutti gli utenti in una volta sola. È lo stesso problema di fondo dell’IDOR (CWE-639).

Serve l’accesso alla produzione o al codice sorgente?

Nessuno dei due è strettamente necessario, ma entrambi aiutano. La maggior parte dei nostri progetti è gray-box: lavoriamo su un ambiente di staging o simile alla produzione con più account di test che coprono tutti i ruoli e con accesso alla documentazione della API. Il codice sorgente può accelerare l’analisi delle cause profonde, ma i rilievi critici in questo caso sono venuti da test di richieste in gray-box, non dalla revisione del codice.

Cosa riceviamo alla fine?

Un report che parte dal rischio, elenca ogni rilievo con la sua gravità, i passaggi esatti di riproduzione e una correzione concreta, oltre a un nuovo test che conferma cosa è stato effettivamente chiuso. Consegniamo i critici man mano che li troviamo, così il tuo team può iniziare a rimediare prima che il progetto finisca, e siamo a disposizione per discutere le correzioni con i tuoi ingegneri.

Siamo in fase pre-round. Vale la pena fare un pentest proprio adesso?

Sì, ed è spesso il momento migliore. Gli investitori conducono sempre più spesso una due diligence tecnica, e se il revisore di un acquirente scopre una falla di autorizzazione critica nella fase del term sheet, è una conversazione molto peggiore che correggerla con discrezione in anticipo. Un report di nuovo test pulito e verificato è un segnale forte che il team prende sul serio la sicurezza.