Test delle API con l'IA: OpenAPI e GraphQL

Le app moderne sono un front end sottile sopra un'API, e l'API è spesso dove stanno i bug veri. La buona notizia per chi testa è che le API tendono a descriversi da sole: le API REST spediscono le specifiche OpenAPI, e le API GraphQL rispondono alle query di introspection. Entrambe ti danno una mappa che il modello può leggere. Questo post segue il test dei bug web comuni e porta a costruire un hackbot.

#Le API si rompono in modo diverso

L'OWASP API Security Top 10 mette l'autorizzazione in cima. Le due da imparare per prime sono la broken object level authorization, dove raggiungi l'oggetto di un altro utente, e la broken function level authorization, dove chiami un'azione da admin come utente normale. Entrambe sono la versione API dei bug di controllo degli accessi del post precedente, ed entrambe sono comuni perché l'API ha molti endpoint e uno di loro di solito dimentica il controllo.

#Trova la specifica OpenAPI

Molte API pubblicano la propria specifica. Posizioni comuni sono /openapi.json, /swagger.json, /v1/openapi.json, o una pagina di documentazione che ne carica una. Scaricala e hai ogni path, metodo, parametro e schema in un solo file.

curl -s https://api.example.com/openapi.json -o openapi.json

Dai la specifica al modello e chiedigli di elencare gli endpoint, segnare quelli che leggono o scrivono oggetti di proprietà degli utenti e segnalare quelli i cui nomi suggeriscono un ruolo admin o interno. Quella passata di lettura trasforma un lungo documento OpenAPI in una lista ordinata di cosa testare per primo.

#Introspection GraphQL

Un'API GraphQL di solito risponde a una query di introspection che restituisce tutto il suo schema: ogni type, field, query e mutation. Quando l'introspection è attiva, ottieni l'intera superficie d'attacco in una sola request.

curl -s https://api.example.com/graphql -H 'Content-Type: application/json' \
  -d '{"query":"{ __schema { queryType { name } mutationType { name } types { name kind } } }"}'

Passa lo schema al modello e chiedigli di raggruppare le query e le mutation, individuare quelle che toccano i dati di altri utenti e nominare gli argomenti che ciascuna prende. La specifica GraphQL descrive l'introspection, e l'OWASP Web Security Testing Guide ha una sezione sul test di GraphQL.

#Lascia pianificare il modello, poi testa a mano

Da una delle due mappe, chiedi al modello un breve piano di test: per ogni endpoint che possiede oggetti, quali due account usare e quale id scambiare; per ogni operazione privilegiata, quale sessione a bassi privilegi usare per provarla. Il modello è bravo a trasformare uno schema in questa checklist. Non può dirti se il controllo manca davvero, quindi esegui ogni caso attraverso il tuo proxy con gli account che controlli e leggi il risultato. Una mutation che lascia a un utente normale cambiare il record di un altro utente è un BOLA pulito, provato con due sessioni.

#Verifica e tieni le evidenze

I finding sulle API sono facili da provare e facili da gonfiare. Provali con account che controlli, una variabile per volta, e salva la request e la response complete per ciascuno. Per un BOLA, l'evidenza sono due request: il tuo oggetto, poi l'oggetto dell'altro account restituito alla tua sessione. Per un BFLA, è la chiamata privilegiata che riesce da una sessione che non dovrebbe poterla fare. Tieni i dati interni che raggiungi al minimo necessario per mostrare l'impatto, e descrivi solo ciò che hai dimostrato.

#Una nota su automazione e rate

Le API rendono tentante scriptare centinaia di request. Controlla prima le regole del programma su automazione e rate, tieni il volume basso sul target live e fai l'iterazione pesante contro una copia locale. Un'API che martelli è un'API il cui proprietario se ne accorge per il motivo sbagliato.

#A seguire in questa serie

Ora hai eseguito tutto il loop a mano. I prossimi tre post costruiscono un piccolo agente che esegue per te i passi di recon e test, sotto la tua approvazione. Comincia da l'architettura dell'hackbot.