Un’API espone direttamente la logica di business, senza l’interfaccia che prima la nascondeva. Gli identificativi sono in piena vista, i campi che il client non mostra mai vengono comunque accettati dal server, e ogni endpoint è a una richiesta di distanza da chiunque abbia un token.
Partiamo dalla specifica, se esiste, e la ricostruiamo dal traffico se non esiste. Ogni endpoint viene chiamato con ogni ruolo, con gli identificativi di altri utenti e tenant, con campi che non dovrebbe accettare e in un ordine che il flusso di lavoro non prevede.
01Perimetro
Che cosa testiamo
Autorizzazione a livello di oggetto: accesso ai record di altri utenti e tenant
Autorizzazione a livello di funzione: operazioni amministrative e interne
Autorizzazione a livello di proprietà: mass assignment ed esposizione eccessiva di dati
Autenticazione: chiavi API, flussi OAuth 2.0, validazione dei JWT, ciclo di vita dei token
Consumo di risorse: rate limit, paginazione, operazioni batch, costo delle query
GraphQL: introspezione, profondità e complessità, batching, autorizzazione dei campi
gRPC e WebSocket: autorizzazione dei metodi, validazione dei messaggi, dirottamento del canale
Server-side request forgery e uso non sicuro di API di terzi
Inventario: endpoint shadow, deprecati e di debug, disallineamento tra le versioni
02Approccio
Come si svolge il lavoro
01
Inventario
Confrontiamo la specifica con il traffico reale e con i client mobili e web, ed elenchiamo gli endpoint che esistono ma non sono documentati.
02
Matrice di autorizzazione
Ogni operazione viene chiamata con le credenziali di ogni ruolo su oggetti di altri utenti e tenant. Il risultato è una matrice di ciò che è consentito rispetto a ciò che dovrebbe esserlo.
03
Abuso di input e schema
Inviamo campi, tipi e strutture che lo schema non prevede: proprietà aggiuntive, query annidate, batch sovradimensionati, content type in conflitto.
04
Abuso dei flussi di business
Le operazioni vengono ripetute, riordinate ed eseguite in parallelo per trovare race condition e flussi che possono essere automatizzati a danno dell’azienda.
Non abbiamo documentazione dell’API. È possibile testarla?
Sì. Ricostruiamo l’interfaccia dal traffico dei tuoi client e dal comportamento del server. La documentazione mancante è di per sé un rilievo, e l’inventario che costruiamo fa parte del report.
In che cosa si differenzia dal test di un’applicazione web?
L’obiettivo è l’interfaccia tra sistemi, non le pagine che una persona vede. Il lavoro si concentra sull’autorizzazione di ogni oggetto e operazione, sugli schemi e sull’abuso automatizzato: è da lì che nascono le violazioni delle API.
Testate le API interne tra microservizi?
Sì, dalla posizione di rete che definisci tu: da internet, dalla rete di un partner o dall’interno del cluster. Le API interne spesso si fidano dei chiamanti più di quanto dovrebbero.