💻 computer science

GraphQLer: Enhancing GraphQL Security with Context-Aware API Testing

GraphQLer è un framework di test di sicurezza automatizzato open-source che potenzia la sicurezza delle API GraphQL costruendo grafi di dipendenza tipizzati da schemi live per sintetizzare catene di vulnerabilità multi-step, superando così strumenti esistenti come ZAP ed EvoMaster nel rilevare difetti complessi e dipendenti dallo stato, quali IDOR, UAF e vulnerabilità di injection.

Autori originali: Omar Tsai, Jianing Li, Tsz Tung Cheung, Lejing Huang, Hao Zhu, Jianrui Xiao, Iman Sharafaldin, Mohammad A. Tayebi

Pubblicato 2026-08-05

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Omar Tsai, Jianing Li, Tsz Tung Cheung, Lejing Huang, Hao Zhu, Jianrui Xiao, Iman Sharafaldin, Mohammad A. Tayebi

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immaginate internet come una città gigante e frenetica dove diversi programmi informatici (le app) si scambiano costantemente informazioni. Per anni, queste conversazioni hanno seguito una mappa rigida e prevedibile: se volevi una foto, chiedevi la cartella "foto"; se volevi un messaggio, chiedevi la cartella "messaggio". Era come ordinare da un menu dove ogni piatto ha un nome e una posizione fissi. Ma recentemente, un nuovo modo di comunicare chiamato GraphQL è diventato popolare. Invece di un menu fisso, GraphQL è come un distributore automatico magico e mutaforma. Puoi chiedere esattamente ciò che vuoi, e lui cercherà di costruirtelo sul momento. Il problema è che, poiché questa macchina è così flessibile, a volte dimentica di controllare chi ha davanti a sé. Un distributore automatico normale potrebbe dare una soda solo a chi ha una moneta, ma questo modello magico potrebbe accidentalmente consegnare un diario privato o un conto bancario se lo chiedi nel modo giusto. È qui che entrano in gioco i ricercatori della sicurezza, cercando di capire come ingannare la macchina per rivelare i suoi segreti senza effettivamente abbattere la città.

Il documento che state per leggere presenta un nuovo detective digitale chiamato GraphQLer. Pensate alla maggior parte degli scanner di sicurezza come a turisti goffi che si avvicinano al distributore automatico, premono un pulsante a caso e vedono cosa succede. Se premono "Soda" e ottengono una soda, vanno avanti. Se premono "Acqua" e ottengono un errore, si arrendono. Non si rendono mai conto che per ottenere la "Scorta Segreta", prima devi premere "Compra Soda", poi "Ottieni Ricevuta" e poi premere "Scorta Segreta". I vecchi strumenti sono troppo stupidi per collegare i puntini; testano ogni pulsante isolatamente e perdono le sequenze complesse necessarie per rompere il sistema.

GraphQLer è diverso. È come un detective che studia prima le planimetrie della macchina (lo "schema") per capire come sono collegati i pulsanti. Costruisce una mappa mentale che mostra come il "Pulsante A" crei un nuovo articolo, il "Pulsante B" lo elimini e il "Pulsante C" possa ancora essere in grado di vederlo anche dopo che è stato rimosso. Con questa mappa, GraphQLer non si limita a premere pulsanti a caso; crea specifiche catene di azioni. Simula uno scenario in cui un utente acquista un articolo, poi cerca di rubarlo, o lo elimina e poi prova a leggerlo di nuovo.

I ricercatori hanno testato questo nuovo detective su 21 diverse API reali e finte ma realistiche (i sistemi informatici oggetto del test). Hanno scoperto che GraphQLer è un enorme miglioramento rispetto ai vecchi strumenti. Mentre i migliori strumenti esistenti riuscivano a raggiungere solo circa il 29% dei pulsanti della macchina, GraphQLer è riuscito a raggiungerli all'85,52%. Ancora più importante, quando si trattava di trovare i problemi di sicurezza più intricati, i vecchi strumenti non hanno trovato zero dei problemi complessi a più fasi. GraphQLer, invece, ha trovato tutti i cinque confermati bug "IDOR" (dove puoi vedere le cose di qualcun altro semplicemente cambiando un numero) e ha persino colto un bug "Use-After-Free" (dove puoi vedere un file dopo che è stato eliminato).

In un test nel mondo reale su un sistema finanziario (che gli autori chiamano "FinServ" per mantenere l'anonimato), GraphQLer ha trovato otto potenziali falle di sicurezza senza bisogno di password o documenti segreti. Ha persino trovato modi per far crashare il sistema e rivelare il suo codice interno, il che è un grande errore per la sicurezza. Il documento mostra anche che GraphQLer può riprodurre vulnerabilità note in una popolare piattaforma open-source chiamata Saleor, dimostrando che funziona su sistemi che sono già noti per essere difettosi.

Gli autori dicono con molta cautela che, sebbene il loro strumento sia eccellente nel trovare questo tipo specifico di bug a reazione a catena, non è una bacchetta magica che risolve tutto. Ha ancora difficoltà con alcuni scenari molto specifici e complessi in cui la macchina richiede più informazioni contemporaneamente per funzionare. Ma per la stragrande maggioranza delle moderne app che utilizzano questa flessibile tecnologia GraphQL, GraphQLer dimostra che non si può più testare i pulsanti uno alla volta. Bisogna capire la storia che la macchina sta raccontando, e solo allora si possono trovare i buchi nella trama.

Sintesi Tecnica: GraphQLer

Problematica

Le API GraphQL sono diventate dominanti nei sistemi di produzione grazie al loro design guidato dallo schema e dal singolo endpoint. Tuttavia, questa architettura introduce sfide di sicurezza uniche, assenti nelle API REST. A differenza di REST, dove i verbi HTTP e le strutture degli URL codificano l'intento, GraphQL espone tutte le operazioni attraverso un unico endpoint senza un controllo integrato dell'accesso.

Il documento identifica che vulnerabilità critiche del controllo dell'accesso — specificamente Insecure Direct Object Reference (IDOR), Use-After-Free (UAF) e injection dipendente dallo stato — sfuggono regolarmente ai test di sicurezza automatizzati. Gli scanner esistenti standard del settore (es. ZAP) e i fuzzer di ricerca (es. EvoMaster) testano le operazioni in isolamento. Essi non riescono a modellare la struttura di dipendenza stateful di GraphQL, dove una mutazione può dipendere silenziosamente da risorse create da operazioni precedenti. Di conseguenza, le vulnerabilità che richiedono sequenze multi-step (ad esempio, creare una risorsa come Utente A, poi accedervi come Utente B) sono invisibili agli strumenti che non sono in grado di comporre catene di operazioni.

Metodologia

Gli autori presentano GraphQLer, un framework di testing di sicurezza automatizzato open-source progettato per trattare le catene di vulnerabilità (sequenze ordinate di operazioni) come costrutti di prima classe. Il framework opera in due fasi primarie:

1. Fase di Compilazione

GraphQLer analizza lo schema live tramite introspezione per costruire un grafo di dipendenza tipizzato.

Annotazione delle Azioni: Inferisce la semantica delle mutazioni (CREATE, UPDATE, DELETE o UNKNOWN) analizzando nomi e descrizioni. I casi ambigui possono essere risolti tramite un opzionale risolutore basato su LLM.
Inferenza delle Dipendenze: Poiché GraphQL non espone esplicitamente le dipendenze di input in forma leggibile dalle macchine, GraphQLer inferisce gli archi accoppiando i campi di input di tipo ID agli tipi di oggetto utilizzando la derivazione di pattern di nomi e il punteggio della distanza di Levenshtein.
Costruzione del Grafo: Il sistema crea nodi per query, mutazioni e tipi di oggetto, collegandoli tramite archi diretti che rappresentano dipendenze hard (non nulle) e soft (nullabili).

2. Fase di Testing

La fase di testing attraversa il grafo di dipendenza utilizzando una strategia a tre passaggi (CREATE/Queries $\rightarrow$ UPDATE $\rightarrow$ DELETE) e materializza i payload.

Materializzazione dei Payload: Genera payload validi (minimamente e massimamente validi) e payload fuzzati (iniettando SQLi, XSS, OS command, ecc.). Mantiene un bucket di oggetti per memorizzare le risorse restituite (ID, stato) per il riutilizzo in operazioni successive.
Strategie di Catena di Vulnerabilità: GraphQLer impiega tre strategie specializzate per sintetizzare specifiche sequenze di attacco:
1. Strategia di Catena Topologica: Utilizza la condensazione dei Componenti Fortemente Connessi (SCC) per gestire grafi ciclici, garantendo un ordine di esecuzione valido per la raggiungibilità generale.
2. Strategia di Catena IDOR: Prende le catene regolari e le riproduce con le credenziali di un utente "primario" per il passaggio di CREATE e le credenziali di un utente "secondario" (non privilegiato) per i passaggi successivi. Una vulnerabilità viene segnalata se l'utente secondario accede a una risorsa che non dovrebbe accedere.
3. Strategia di Catena UAF: Sintetizza catene in cui una risorsa viene creata, eliminata e poi letta. Cerca quadrupli $(c, o, d, r)$ dove $c$ è CREATE, $d$ è DELETE e $r$ è READ. Se il passaggio di READ restituisce dati dopo il DELETE, viene rilevata una vulnerabilità UAF.

Il framework supporta anche le sottoscrizioni basate su WebSocket ed espone la sua pipeline come un server Model Context Protocol (MCP) per flussi di lavoro assistiti dall'IA.

Contributi Chiave

Catene di Vulnerabilità: L'introduzione di sequenze ordinate di operazioni GraphQL come costrutto primario di testing, specificamente progettato per rilevare vulnerabilità multi-step mancate dagli strumenti a singola operazione.
Tre Strategie Specializzate: Implementazione di attraversamento topologico SCC, replay IDOR cross-user e sintesi di archi di grafo UAF per coprire superfici di attacco critiche.
Strumento GraphQLer: Un'implementazione open-source che presenta un grafo di dipendenza, una suite di injection che copre nove categorie di vulnerabilità, un risolutore di dipendenze assistito da LLM e un motore di profili multi-auth.
Valutazione Estensiva: Valutazione su 21 API, inclusi API pubbliche, API di piattaforme di produzione, applicazioni con vulnerabilità note (Saleor, DVGA) e API create appositamente per il ground-truth.

Risultati

La valutazione dimostra che GraphQLer supera significativamente gli strumenti esistenti sia in termini di copertura che di rilevamento delle vulnerabilità:

Copertura delle Operazioni: Su 11 API pubbliche, GraphQLer ha raggiunto una PositiveCoverage media dell'85.52%, rispetto al 29.29% di EvoMaster e al 21.80% di ZAP.
Rilevamento Ground-Truth:
- IDOR: Ha rilevato tutti i 5 endpoint IDOR confermati su un'API creata appositamente.
- UAF: Ha rilevato comportamenti UAF su VVSM-API e incidentalmente su ID-API.
- Injection: Ha confermato SQLi, XSS e OS command injection su API create appositamente e ha validato indipendentemente XSS e SQLi sull'applicazione di terze parti DVGA.
- Confronto con Baseline: Tutti gli strumenti di base (ZAP, EvoMaster, Schemathesis, GraphQL-Cop) hanno rilevato zero vulnerabilità basate su catene (IDOR o UAF).
Applicazione nel Mondo Reale: Su un'API finanziaria di produzione (FinServ), GraphQLer ha identificato otto potenziali vulnerabilità, inclusi vettori di denial-of-service che espongono stack trace, senza documentazione o credenziali pregresse. Su un'istanza di Saleor vincolata alla CVE-2022-39275, ha riprodotto tutte le quattro mutazioni di broken-access-control citate nell'avviso di sicurezza.

Significato e Claim

Il documento sostiene che GraphQLer affronta un vuoto strutturale nel testing di sicurezza automatizzato: l'incapacità degli strumenti esistenti di modellare le dipendenze stateful e multi-step in GraphQL. Sintetizzando catene di vulnerabilità, GraphQLer espone difetti che sono invisibili ai fuzzer a singola operazione.

Gli autori posizionano GraphQLer non solo come uno scanner, ma come uno strumento per il triage industriale e la raccolta di prove, capace di operare in modalità completamente black-box per identificare vettori ad alto rischio nei sistemi di produzione. Il lavoro evidenzia che, mentre gli strumenti a singola operazione possono verificare la conformità dello schema, sono architettonicamente incapaci di rilevare vulnerabilità che dipendono dalla sequenza e dallo stato delle operazioni. Il rilascio di API ground-truth (IDOR-API, Injection-API, VVSM-API) è inteso a fornire i primi benchmark etichettati per il rilevamento di vulnerabilità GraphQL basate su catene.

Il documento rimane modesto riguardo ai limiti, ammettendo che certe precondizioni complesse (ad esempio, l'autenticazione multi-campo per l'injection) e i problemi di materializzazione degli scalari possono ancora portare a falsi negativi, e che la validazione esterna indipendente di IDOR/UAF su applicazioni di terze parti su larga scala rimane un lavoro futuro.